Creating People-Aware IoT Applications by Combining Design Thinking and User-Centered Design Methods Milène Fauquex†, Sidhant Goyal‡, Florian Evequoz†, Yann Bocchi† †
Institute of Information Systems University of Applied Sciences Western Switzerland, HES-SO Valais-Wallis Sierre, Switzerland {yann.bocchi, florian.evequoz, milene.fauquex}@hevs.ch ‡ Department of Design Indian Institute of Technology Guwahati, India
[email protected]
Abstract—
The new services and applications introduced into the IoT market were until now dependent on technological interventions rather than demand. IoT is currently at a turning point where the hardware and technology are mature and the focus can be put on creating good user experiences [2]. In this article we present a methodology that can be used to develop and design people-aware IoT applications and illustrate it with the help of a use-case. After a state of the art about existing User Experience (UX) methodologies, we present our approach and the research project within which it was developed. Lastly we discuss the methodology and provide insight about the future works and perspectives. II. STATE OF THE ART
Index Terms—Internet of Things, User-Centered Design, Context-Aware Environment, Design Thinking, User Experience.
I. INTRODUCTION The Internet of Things consists of a growing network of everyday objects, from industrial machines to consumer goods, which are inter-connected, can share information and complete tasks while the user is busy with other activities, like work, sleep or exercise [1]. These sensors have the potential to harness content and automatically build context around information and interactions in various Smart Environments. A rich user experience or time and labor-saving automation are common outcomes to be expected from IoT applications. With the increasing amount of users using mobile devices, wearables and the internet, the access to all kind of Big data about the users such as health, personal and social data through social networks or mobile applications has become much easier, and this data has the potential to make the experience in various Smart Environments more contextual, effective and more user friendly.
It is hard to find methodologies on how to properly include the end-user needs into the IoT application creation process. One big source, nevertheless, is Claire Rowland’s book “Designing Connected Products” [3]. The book describes what makes a good product by stating that a good product solves a real problems people have and how it is important to understand the users for this product. The chapter explains in particular that the user is part of the audience your product is intended for and that this audience includes many roles such as the purchaser or the technician. The user will not necessarily be the one that decides to buy the product. The author advises to also take into account the purpose of the product and the full ecosystem and its contextual factors. Some tactics such as asking the user, watching him in his environment and making him participate are introduced. Another point to take into account when designing for IoT is the learning curve. Dorothy Shamonsky from ICS suggests in her article [4] to design with a little or no learning curve for the users. According to the article, many connected devices are not built with interfaces that have existing UX standards. It is recommended to replicate the most commonly used and understandable UX patterns, such as the touch.
From his side, Ted McCarthy, an experience design researcher from ThoughtWorks, warns about IoT forgetting the humans interacting with technology [5]. His article puts forward the fact that IoT involves more data and warns about a better public knowledge about security and privacy with these data. He also says that the availability of the data will reduce the “design-build-test” and helps to better understand the users. However, according to McCarthy: “No matter the quantities of data we obtain, traditional qualitative methods will continue to prevail, as no amount of quantitative data and machine learning can ever truly substitute for qualitative research.”. Qualitative methods allow designers to ask deeper questions where data provide answers to already-known ones. As everyone agrees to say that a big effort has to be made on designing good user experience, providing products rather than tools and that IoT needs to hit the mass market, it is hard to find methodologies that consider the whole process of IoT application creation. Rowland’s book covers a big part of this process by listing several techniques and challenges into detail. Our work includes some of these recommendations, considers the IoT challenges and provides a turnkey methodology that is reusable, applicable to various contexts and easy to set up like we will illustrate with a use-case we developed. Therefore our work is a contribution towards providing a complete and comprehensive methodology to design ‘people-aware’ usercentered IoT applications.
seven phases. Here, the design thinking level is about the idea generation and contains two steps: Discovery and Capturing. We first get to know the users and determine a context in order to generate some product vision. In this first phase we do not bother about any technological matters. We set up these two first phases because we believe it is important to start the development process as broad as possible in order to capture the whole context and all the elements composing it. It is particularly important when developing an IoT product since, as said before, the product will not be an isolated device but a part of a whole ecosystem. Our funnel approach at this level allows considering the entire target environment and identifying a product vision that fits in. Once the product vision is defined, it will go through a more classical UX-based cycle that is illustrated in the bottom part of Figure 1. This cycle contains five steps such as research, design, prototype, evaluate and refine and progresses in an iterative way.
III. PAWEN METHODOLOGY This approach has been developed as a part of a research project called PAwEn (for People-Aware Environment) of the Institute of Information System of the HES-SO Valais in Switzerland, conducted in an interdisciplinary team consisting of engineers, service designers and user-experience designers. The goals of this project are among others to identify the potential of integration of UX and Service Design approaches in IoT applications as well as use these tools for ideas and applications generation in smart and connected environments. The process is a top-down approach where the application’s propositions are coming from the user’s perspective and where the added value is at the junction with technology-driven applications. A. The methodology at a glance The challenge was to adapt every step of the methodology in an Internet of Things perspective. As mentioned above, the design principles are not the same as for a standard 1-to-1 or 1to-n application where the user has a physical device in front of him that acts as a concrete interface. Even current IoT products e.g. smart sensors come with a classical interface such as a web or mobile app. However with our scope of application, the interaction is totally different because we have many IoT devices which not only communicate with one or many users but also between them. Moreover, as a smart environment has to be as natural as possible to use for the people and thus not be intrusive, new forms of interactions must be developed. In the perspective of the scope described above, the PAwEn methodology (Figure 1) has been established combining two levels: design thinking and user-centered design, divided in
Figure 1 : The PAwEn Methodology
In the next chapters, we will go through each part of the methodology and illustrate it with a use-case we developed within the research project. B. Discovery The « Discovery » step is the one in which we become acquainted with the users and the context of the future product we want to develop. This step consists mainly in setting up some
loose boundaries inside which we want to identify what problems people encounter. The two main inputs of this step are the following: 1. Area of life: The context in which your potential users evolve (e.g. professional context: an office, a yard; domestic context: a building hall, a private house, etc.) 2. Potential users: The people you find in the preset context Starting with defining a context and potential users helps to keep in mind that the final IoT application will be part of a whole environment and will not be an isolated device operating on its own. Once the inputs are defined, several techniques are applied to gather information from the users. 1) The survey In our research project, we defined a professional context, an office building, as the area of life with all the people working in the building as potential users. We then set up a survey containing one single question: “Help us to improve your environment and quality of life in the building.” The survey was held online and on a white board in the main entrance for a period of 4 hours. The question asked was open on purpose to gather as many different types of answers as possible and made no mention of IoT to avoid the users surveyed to be biased by any idea of existing smart systems. It is important to formulate the question in a proper way while keeping in mind the goal of the final product to get the appropriate answers. In our case we want to develop a product that resolves problems but we did not use the word “problem” in our question because we wanted people to focus on improvement rather than unsolvable issues. The survey was held for a short period of time to generate the most obvious and spontaneous answers. Together, both the online and physical surveys led to the identification of about 60 problems that we wrote down on sticky notes on a white board after removing duplicates. 2) Brainstorming A dozen people among the users surveyed were chosen to participate in a brainstorming session. During this session, the answers on the sticky notes were refined and sorted. Outof-scope answers were removed and the remaining ones were sorted into four categories: accessibility (e.g. issues about visitors finding their way inside the building), facilities (light, temperature, or ventilation issues), mobility (public transport or parking issues) and office-related (clock in/out issues, flexible work spaces, better booking of meeting rooms). The defined categories of problems become a suitable input for the next step of the methodology. C. Capturing During the « Capturing » phase, we translate the initial problems identified into a product idea or vision. As this step is still in the idea-generation part of the process, the goal here is not to clearly define the end product but to specify a vision or an idea of this end product that will be refined in the next steps of the methodology. 1
TP stands for Technopôle, the office building in which the participants work.
There are many tools and techniques that allow us to define a product vision: the product vision statement [6] (for, who, the, that, unlike, our product), the product vision box [7], the agile vision board, etc. For our use-case we adapt the technique called the “product vision box” borrowed from the agile project methodology. The technique consists in creating an actual physical box to picture your product where each side of the box summarizes the features of the product. In the initial exercise a team of potential users is divided in sub-groups that are each asked to create a product box. At the end of the workshop a single box is created in agreement of all the teams together. In our workshop we picked the participants among potential users and practitioners in the project. Since the goal was to produce several IoT applications, each team was asked to pick one category among those identified in the Discovery phase and to develop a product vision box that fits in this category. Another instruction was to make a product including IoT but the participants were asked to think about IoT as a “magical toolbox”. At this stage we decided to include the IoT notion but more to open perspectives and not as a limiting condition. The categories picked were: facilities, mobility and office-related. The exercise led to the creation of three product vision boxes (Figure 2): 1. “Fix My TP1”: a concierge in your pocket. A system that allows the residents of the building to report any facility issue directly to the right person. 2. “The M-Room”: The mood-room – an idea of a smart meeting room adapting to the mood of their participants. 3. “Mobility Portal”: A web portal that provides information about mobility-related issues for the office building (parking, bicycle, bus, etc.) This exercise asks the participants to be explicit enough about the benefits and features offered by the application for them to be described on a single box. Therefore, the output of this capturing phase is a product box depicting an application vision or idea. D. Research The work to be done on the “Research” phase is based on the output of the last phase: the product vision box. Following the methodology, we are now entering a new iterative cycle in which the product idea will be refined. The first step consists on doing some literature review about the subject to understand the field but also to provide references on what is possible to do on a technological point of view. It also allows us to guide the next step of this phase: the user research. In our use-case, we chose the “M-Room” box, depicting a smart meeting room as it was the easiest for us to implement in the premises available for the project. There are various existing methods that can be used to perform user research. Whether you choose qualitative, quantitative, or a mix of both methods, each has its strengths and weaknesses that you can find in the literature [8] [9]. At this stage in our research, we chose qualitative methods. We performed various semi-structured interviews [10] within
stakeholders working inside the office building to identify their needs, goals and experiences during meetings. Based on the interviews, the following insights were generated: 1. The concentration level of the user generally follows a Poisson distribution [11] i.e. initially it increases and then decreases exponentially due to a lot of factors: - People have to multi-task while they are in meetings (write notes, search on the web, or hear the speaker) - The environment, such as the light and temperature of the room, can have an impact on the concentration level. 2. Users do not have much contextual information regarding the subject being talked about which affects their concentration/engagement level in the meetings. Sometimes the speaker uses very company-specific acronyms and terms that a novice user or a person who did not attend the previous meeting has no idea about. 3. Users sometimes have the feeling that meetings are a waste of time because the goals are not clearly defined, the outcomes are not clear and they have difficulty tracking the progress of the meeting. 4. Some users feel frustrated about the decision-making process in a meeting, they find it difficult and too long (with too much discussion) to reach a consensus. 5. People are often reluctant to take notes in meetings. Based on the qualitative data from the interviews, we created 3 personas and an affinity diagram. A persona is a fictional character that represents the needs of a group of users. It helps keep the user in mind during the product development process by personifying the data collected [12]. The affinity analysis helps in finding the common problems experienced by the personas and identifying patterns by mapping the issues in a hierarchical diagram [13]. In parallel of the user research we also performed a context research. As mentioned in the state of the art and in the first paragraph of this chapter, the context has to be considered as a part of the application as much as the users. We started by listing all the elements in a smart meeting room that can be affected or controlled by an IoT system. When thinking of a meeting room, it usually includes a table, chairs, a projector and lights. These are all elements on which actions can be performed. But you have also the door, the temperature, or the walls. Various brainstorming sessions helped us identify these elements and the types of actions can be performed with them (e.g. displaying something on the wall, adjusting the light, count the number of people sitting). Having a good picture of the context in which your application will be deployed will help in the designing phase. It also allows identifying what input data are available and what kind of output you can provide to the users and by which support.
Figure 2 : (left) Product vision boxes, an outcome of the capturing phase; (right) Storyboard sketches in the design phase
E. Design This phase ensures that the design of the system meets all the user’s requirements and needs obtained from the research phase. It is generally done by a designer relying on the outcomes of the previous phases. On the basis of the problems identified by the affinity analysis, we ideated various scenarios, which described the broader context in which different personas behave and interact within the existing system. We turned towards exploring Tangible User Interfaces in the context of a meeting scenario. Tangible user interfaces come under the umbrella of Reality-based interactions, a concept proposed by Jacob [14], which basically leverages user’s existing knowledge and skills of interaction with the real nondigital world. Such interfaces have the potential to ease the manipulation of different information and decision-making in a more collaborative manner rather than using graphical user interfaces. We aimed to use tangible user interfaces so that the users can manipulate the large set of information in the meetings in a more natural and collaborative manner. For our use case, we conceptualized the idea of a cubical tangible block which can be used to manipulate the information and activities in the meetings. The three opposing sides of the cube consist of elements such as SmartInfo, Agenda and Decision. The affordance of the cubical token such as sliding or rotating can be mapped to relevant activities and actions. We used scenario illustrations to understand the overall context-ofuse of our system (Figure 2). The description of the user journey in various scenarios is written below: Roger, one of the users, has just recently joined Technopôle, and did not attend the initial meetings on an ongoing project. Roger is sitting inside the meeting room and the presenter is giving a presentation which involves data from previous presentations. The presenter uses an expression, which Roger is unfamiliar with. He is reluctant to disturb anyone to ask or search on the web about it during the meeting. Using the tangible token, he can view that content easily while in the meeting without disturbing anyone. The system automatically maps the relevant information on the table to the side of the cubical tangible token corresponding to SmartInfo. Another scenario is where the users feel frustrated as they see that the goals of the meeting are not defined. In such a case, the Agenda side of the tangible token is useful to see tag clouds related to the project or the progress of the meeting.
F. Prototype Prototyping allows designers to test scenarios from the previous step against usability issues and helps visualize the idea of the product. There are two levels of prototyping [15]: lowfidelity and high-fidelity, where the difference is set in the level of detail of each level. In user interface design, with the lowfidelity prototypes, the interaction with the user is often simulated. It usually doesn’t involve any actual technology, therefore it is quicker and cheaper to implement and are affordable to non-technical members of the team. On the other hand, high-fidelity prototypes have a high level of detail and allows partial to full interaction with the system functionalities. However it is expensive and time-consuming [16]. At the time of writing this article, the prototyping phase of our use case is not fully completed. Yet, we decided to build the first version of our prototype with actual hardware devices since it will also allow us to test their reliability and also because we already had some devices and an environment available to build a prototype. In case you don’t have any materials, a simulated prototype is recommended at first. We think having an idea of the devices you want to use can also help in building adequate interaction. Finally, we would like to raise that simulating a whole experience of an IoT application including the environment and all its elements can be a huge task. Moreover, when resources allow, high-fidelity prototypes that include logging capabilities could be developed in this phase. They could be used in the next phase for gathering quantitative data about the usage of the prototype that would complement qualitative data obtained from post-test interviews with users. G. Evaluate When designing for a classical screen-based interface, there are several heuristics (or usability principles) that are often used to evaluate the problems associated with the design of the interface such as Nielsen’s heuristics [17]. Some of them can also be applied to an IoT-based system and we believe that several new heuristics specific to IoT will arise with the spread of the field. We aim to identify such evaluation indicators by the end of this research project. Another way to evaluate a prototype is the use of usability testing methods. There are various methods [18] that can be used, such as the “thinking aloud”, where the tester is asked to talk aloud his thoughts while using the system. The process of a usability test is basically the same for every method. You first pick representative users to test your system, then you select a typical and well described scenario that the user will be performing in the test, and finally you report the results. Moreover, if high-fidelity prototypes were developed in the previous phase, quantitative usage data logged by the systems may be analyzed in this phase as a useful complement to the data obtained from qualitative testing methods. Since there are various guidelines and methods described in the literature [19] about usability testing and we are only at the stage of prototyping in our use-case, we will not explain this step in further detail.
H. Refine At the end of the evaluating phase, test results are reported. It is in this “Refine” phase that the results of these tests are handled and transformed into new adjustments for the next cycle of the product in the iterative loop of the methodology. It is important to clearly define the objectives and readjust them accordingly to the user tests and evaluation phase results. From an IoT perspective, it would be wise in this phase that you consider technical aspects and feasibility of your product idea. Finally, be clear on the refinements you want to implement for the next cycle. It is always better to run through the whole cycle until the “Evaluate” phase than making changes along the way due to unclear objectives or assumptions. Iterative cycles can also be shortened and occur more often, depending on the number of changes you decide to make. IV. FUTURE WORK The next steps of our project consist in realizing a first prototype including various ideated scenarios of a smart meeting room. In the next iteration, we aim to include data mining approaches to the prototype to enhance the user experience by analyzing the human behavior in a meeting room and also to gather contextual quantitative data that will allow the system to identify some patterns. The goal of this approach is to make the system autonomous and less intrusive for the user. We are also establishing a test protocol based on heuristics evaluation and usability testing to evaluate the prototype. We will gather qualitative data from users’ post-use interviews and observations at a first stage that we will then cross with quantitative data provided by the system. This protocol will also help us identify which heuristics or indicators are the most accurate in the case of an IoT application. Finally, we will focus on how to efficiently measure the users’ satisfaction while using the product. For the refining phase we strive to identify and implement various tools to turn test results into product requirements. We are considering adapting some techniques from agile methodologies to achieve this goal. Finally, we would like to apply the methodology to various contexts and areas of life in order to cover a wider spectrum of opportunities. V. CONCLUSION This article introduced a turnkey design methodology for IoT applications that aims at facilitating the design of ‘people-aware’ applications, putting the needs of the users before the technology. A combination of proven and state-of-the-art methods in design thinking and user experience design, our methodology comprises IoT-specific elements in each of its seven steps. The methodology was applied in the context of the PaWen research project to devise concrete IoT applications. It led to the identification of several ideas to address concrete user problems in their working environment. The scenario of a smart meeting room, with its associated challenges, was selected from the first phases of the methodology. Applications that tackle the identified challenges were then designed following the steps of the methodology. Future works include the prototyping,
evaluating and refining of the designed applications, for validating the whole approach. Moreover, the methodology as a whole is flexible and can be easily tailored. For example, its first steps (discovery-capturing) can be used as a starting point for researchers to help them identify promising trends based on users’ needs and context, or can be run just once since the target market in your business is already defined. The iterative development cycle from the last steps can help practitioners ensure IoT applications they develop are aligned with real users’ capabilities and usage context. As highlighted by Rowland in the state of the art, the ecosystem as well as the users must be kept in mind when designing for IoT. Our methodology starts by this point and sets up both potential users and a context from the beginning of the process and considers them together all along. ACKNOWLEDGMENT The authors would like to thank the HES-SO and the Institute of Information Systems funding and supporting the People Aware Adaptive Environment (PAWEN) internal project with the grant agreement n° 42461. REFERENCES [1] H. Sundmaeker, P. Guillemin, P. Friess and S. Woelfflé, Vision and Challenges for Realising the Internet of Things, Brussels: CERP-IoT – Cluster of European Research Projects on the Internet of Things , 2010. [2] M. Beltrame, «The User Experience of the Internet of things» in Frontend Conference , Zürich, 2013. [3] C. Rowland, E. Goodman, M. Charlier, A. Light and A. Lui, Designing Connected Products, O'Reilly Media, 2015. [4] D. Shamonsky, «Internet of Things: Designing a User Experience for No Learning Curve» 29 June 2015. [Online]. Available: http://www.ics.com/blog/internet-things-designinguser-experience-no-learning-curve. [Access September 2015]. [5] T. McCarthy, «UX in the era of IoT» 8 April 2015. [Online]. Available: https://www.thoughtworks.com/insights/blog/ux-inthe-era-of-iot. [Access September 2015]. [6] G. A. Moore, Crossing the Chasm, Harper Business Essentials, 1991.
[7] J. Highsmith, Agile Project Management : Creating Innovative Products, Pearson Education/Addison-Wesley, 2004. [8] J. A. Maxwell, Qualitative Research Design: An Interactive Approach 3rd Edition, SAGE Publications, 2012. [9] J. Brannen, «Mixing methods: Then entry of qualitative and quantitative approaches into the research process.» International Journal of Social Research Methodology, vol. 8, n° 13, pp. 173-184, 2005. [10] R. Longhurst, «Semi-structured Interviews and Focus Groups» in Key Methods in Geography 2nd Edition, SAGE Publications, 2010, pp. 103-115. [11] A.-L. Barabasi, «The origin of bursts and heavy tails in human dynamics» Nature, n° 1435, pp. 207-2011, 2015. [12] J. J. Garrett, «The Strategy Plane : Creating Personas» in The Elements of User Experience : User-Centered Design for the Web and Beyond, 2nd Edition, New Riders1249 Eighth, 2011, pp. 49-50. [13] A. Saini, B. Nanchen and F. Evéquoz, «Putting the Customer Back in the Center of SOA with Service Design and UserCentered Design» in Service-Oriented and Cloud Computing, Springer Berlin Heidelberg, 2013, pp. 94-103. [14] R. J. Jacob, A. Girouard, L. M. Hirshfield, M. S. Horn, O. Shaer, E. T. Solovey and J. Zigelbaum, «Reality-based interaction: a framework for post-WIMP interfaces.» in Proceedings of the SIGCHI conference on Human factors in computing systems., ACM, 2008, pp. 201-210. [15] M. Walker, L. Takayama and J. A. Landay, «High-fidelity or low-fidelity, paper or computer? Choosing attributes when testing web prototypes» in Proceedings of the Human Factors and Ergonomics Society 46th Annual Meeting, Baltimore, 2002. [16] F. N. Egger, «Lo-Fi vs. Hi-Fi Prototyping: how real does the real thing have to be?» in OZCHI2000, Sydney, 2000. [17] J. Nielsen, «10 usability heuristics for user interface design» Fremont: Nielsen Norman Group, 1995. [18] Nielsen Norman Group, «How to Conduct Usability Studies». [19] K. Hornbaek, «Current practice in measuring usability: Challenges to usability studies and research» International journal of human-computer studies, vol. 64, n° 12, pp. 79-102, 2006.
