User-Centered Design

From apppm
Revision as of 17:55, 28 February 2018 by Arslance (Talk | contribs)

Jump to: navigation, search

Contents

Abstract

As technology and services advance and become more deeply integrated in the daily live of their customers and therefore human lives, the different development processes and projects need to ensure that the offered solutions become more intuitive and user-friendly in order to secure customer satisfaction and stable sales. While taking a closer look on classical development models e.g. Waterfall model, it is clear that during the different project stages the focus of the project managers are only project related and mostly not viewed from an end customer perspective, which can cause usage and understanding problems[1].

The User-Centered Design Approach takes these problems into consideration. The goal is to design understandable and enjoyable solutions for the end customers, while either taking their personal opinions into account or lead the project from an end customer optimized view. Therefore the different processes must be lead towards a user's needs, abilities and expectations in order to guarantee a maximized customer focus. The UCD process consists of five steps, of which the last 4 are following a interative logic. Furthermore, the UCD is defined in the DIN EN ISO 9241-210 "Human-centred design for interactive systems " standard[2].

Characteristics & Principles

The UCD concept was first mentioned by Donald Norman in his publication "User-Centered System Design: New Perspectives on Human-Computer Interaction" in 1986 and further discussed in his book "The Design of Everyday Things". Norman shows the importance of a users need in a product and the mistakes caused by unappropriate designs, which aren't user focused and don't take these into account. Therefore he gives recommendations based on the users needs and wishes.

In order to reach a high level of usability the following principles must be followed as defined by Gould and Lewis in 1985.

  • Iterative proceeding
  • Early focus on user and task requirements
  • empirical review of the designs by users

User-Centered Design Process

Having a closer look at classic development models shows that the focus of development does not respect the needs of the end users. As technologies advance and become more deeply integrated into human lifes, products or services must become more intuitive and user-friendly. Therefore, the goal is to design easy-to-learn and easy-to-use interactive products that provide the user with an optimal interface and an enjoyable user experience. For this, the development process must be geared towards the users and their needs, abilities and expectations must be taken into account. These criteria are fulfilled by the User Centered Design approach. Through the usage of the UCD developments of a wide range of products and services are conceivable. Principles of the approach are an iterative proceeding, an early focus on user and organizational requirements and the empirical verification of users' designs. The UCD process is presented in the standard DIN EN ISO 9241-210: 2011 " Human-centred design for interactive systems." Since the development of a human-friendly product is in the foreground, the term "human-centered design" is used. The procedure with five distinct phases essentially characterizes the process, whose phases are shown in Figure 1.

Own figure based on DIN EN ISO 9241-210 " Human-centred design for interactive systems"

The user-centered design (UCD) design process for interactive systems according to ISO consists of five steps, of which the steps two through five are iterative. Since UCD can also be used to manage projects besides the development of interactive systems, the five phases according to ISO can be used by project managers of every kind. The following is a detailed description of the procedure.

Step 1: Identify need for human-centered design

UCD activities should play a central role as a guiding principle in all areas of project or product development. An involvement of all project members is important in order to avoid conflicts and to achieve an integration into all previous processes. A first meeting of all persons involved in the development represents the start of the UCD process. During this meeting general questions about the use of the product or the service should be answered.

Step 2: Understand and specify the context of use

The understanding and definition of the context of use is a central point in the UCD. Collecting information about the future users, their wishes and needs must be essential. In order to get to know the potential users, the use of an audience analysis is conceivable. This should result in a concrete distinction between different target groups from the mass of all users. Attributes help in the division into different groups. These may be demographic characteristics, such as age or gender, socioeconomic as well as education and occupation and psychological characteristics and attitudes and values. The data can be used as a first source for creating personas. The execution of a task analysis is conceivable as the next step. Here, the tasks that are important for the achievement of the objectives are broken down into small sub-steps and the sequence of orders and their execution conditions are analyzed. In this case, the result may represent, for example, in a hierarchy of goals up to the smallest steps required to solve the request. For example, Figure 2 shows a task analysis for installing an app on a smartphone. Last but not least, the analysis of the work or application environment may be an option. Many systems are exposed to very different environmental conditions, e.g. large temperature differences. In the environmental analysis, it is important to record all significant environmental influences, thus a system can be designed that works flawlessly under all expected environmental influences.

Step 3: Specify the user and organizational requirements

The determination of the usage requirements and thus the development of requirements for the use of the product or the service refer to the requirements of the users including the usage context defined in the previous step. In terms of content, these refer to the requirements of the users and thus exceed the descriptions of purely functional aspects. Realistic use cases help to integrate the personas into lifelike user experiences, whereby the involvement of personas in them realistically describes how to perform a specific task and what motivates the user to perform a task.

Step 4: Produce design solutions

Following the elaboration of the context of use and the user requirements, first solutions of the future product will be developed during this step. These are realized in different prototypes for visualization but also for evaluation. At the beginning, cost-effective and low-effort prototypes are presented to the customer, such as paper prototypes or simple forms on a screen. Customer wishes can be implemented quickly and easily. As development progresses, the prototypes become more and more similar to the final product. Functionalities and structure of the product approach the final version and thus implement findings from previous versions.

Step 5: Evaluate designs against requirements

In order to optimally integrate the wishes and needs of the customers into the process, prototypes should be tested and evaluated by them early on. Evaluation in development is one of the key points of the UCD process. At the outset, it is conceivable to carry out an expert evaluation, whereby a trained expert, who as yet has had as little involvement as possible in the previous development steps, evaluates the system from the point of view of a persona and documents problems that occur in the design solutions. A controlled testing with people from the targeted user group represent the standard of development, Once the design solution meets all user requirements, the process is completed and the product or service is fully developed.


Analysis Tools

There are a lot of tools which can be used during a UCD project to optimize the outcomes and goals. All of them try to help the project team to slip into the role of an user and understand its needs and wishes regarding a product. In the following three important Tools are described, while still a lot of tools as scenarios, use cases etc. could be mentioned.

Personas

After a closer look at the UCD method, it is obvious that it is suitable for organizing a customer-oriented development. In the worst case of a development, companies rely on their own experiences when developing new products or services. Thus, these products and services for already known users would be developed, which one imagines in their own target group. Alternatively, one selects target groups from a variety of data, which come from the fact-based data in the format "age", "income" or "marital status". A grouping that is understandable for all employees is often difficult, as they are also difficult to apply in projects and difficult to communicate in a team. In addition, different images of the respective target group and their needs and wishes arise. Persona development is an interesting option to analyze and exploit these needs of the end user or target group during the course of the UCD.

The so-called personas represent archetypically users of products or services that address a specific target group and their needs, interests and interests reflect wishes. These are based on analysis, testing and observations, or are developed from existing information to influence decisions for a particular process or long-term decisions from the customer's perspective. In addition, they help companies to understand, describe and identify functionalities of their target groups and to optimize processes and products of the company in a customer-oriented manner. The founder of the Persona method was Allen Cooper in the early 1980s. Long loading times and confusing user interfaces disrupted his everyday life decisively.

Through the use of fictional characters, which reflected the needs of future users, it was possible for him to "translate" into the user. Cooper developed with this method some programs in which he developed personas for each user group. For the time being, he gave Personas only a name and a goal, which the user wanted to achieve with the use of the program. In 1998 he published the book "The inmates are running the asylum", in which he presented his persona method to the world public. At the present time, the Persona method is not only used in software development, but also in other disciplines such as computer science or marketing and sales.

The descriptions of the properties of personas are usually very similar in contemporary literature, but sometimes differ in the details. Goodwin's description, however, captures many similarities and will be explained in more detail below. Figure 2 shows a persona from Kim Goodwin's book "Designing for the Digital Age.

Exemplary presentation of a persona after K. Goodwin (Source: Goodwin, 2009.)

One of the most important elements of a persona is the naming. Each persona should have a realistic first and last name, as this increases the authenticity of the persona and thus increases its value at the same time. Using an authentic photo increases this value again. Names of people known by the team should not be used as they can otherwise create strong associations. The persona should, if possible, include a description of their abilities, as well as information about technical know-how or the training background is helpful in planning the future use of a product or service. The description of feelings, attitudes and expectations helps to translate even deeper into the persona. The question of which activities provide joy and which are particularly tedious is experienced by the development team. In order to further increase the relation to reality, the use of demographic characteristics from field research is recommended. The persona's behavior in certain questions, general frustrations and problems of the represented user group and descriptions of the usage environment complete the desired properties. In particular, the usage environment can be of great importance, as it can be important to understand the context of product usage. Finally, it should be mentioned whether the persona interacts with other personas, products, and services, and how they involve the tasks of the persona. In addition, relationships and interactions with other personas can be linked and recorded, if they influence the usage behavior.


Customer Journey Mapping

The Toolbox's second tool is Customer Journey Mapping, or CJM in short. A customer who buys a service or a product of a company usually has several so-called contacts with areas and employees of a company that influence his or her perception. To increase customer satisfaction and build long-term customer relationships at the same time, this approach seeks to make a customer's "journey" as comfortable and hassle-free as possible. CJM enables a project team to recognize, track and describe various customer experiences that arise when using the product and thus describe the central aspects that form the basis for customer satisfaction. By deriving measures from the acquired knowledge conclusions can be drawn on the composition of the own portfolio and these can be adjusted to the customer. In this case, the customer's journey can be described by the use of one or more Personas, which are particularly useful because they not only represent a whole audience. Additionally Personas allow the emotional attachment of the project team to an users wishes and needs, what makes the implementation easier than purely fictional characters.

The first step of a CJM development is the definition and focus on the customer group. Here, the Personas are used and represent the most important customer group. In the second step, it is important to identify and document the various points of contact of the selected personas with the company. Here is to think of all points of contact, which may come into question. This also includes all points of contact before the purchase, but also all during the purchase and afterwards occurring. In order to avoid a confusing and thus unusable CJ map, the third step is to focus on the so-called Moments of Truth. The Moments of Truth method describes the most important or insignificant contacts to the company from the customer's point of view with a simple point scale of one to five. The most important contacts for the customer are rated one, whereas the less important contacts are rated five. Consequently, in order to prioritize the points of contact, a focus is placed on the points with a rating of one to three. Subsequently, in the fourth step, an overview of the departments and persons with whom the customer comes into contact during the course of the CJM is provided. In addition, the documentation of possible internal problems, which could influence the customer satisfaction, is suitable. In the fifth step, CJM, the evaluation of the individual points of contact along the customer journey is to be assessed from the customer's point of view. On an scale of one to ten, an objective assessment will be made, which may be based on analyzes and figures. If none of these are available, surveys of employees involved in the touchpoints or customer surveys are also useful. The number ten describes exceeded expectations, whereas the number 1 represents the opposite of these. The central step of the method is the graphical representation of the customer journey. This step can be implemented in different variations, but most solutions have a similar structure. The Y-axis of the graph shows customer satisfaction, whereas the X-axis describes the duration of the trip. An example presentation might look like Figure 3.

Own figure of a Customer Journey Map after Zeidler, 2010.

With the creation of the CJ Map the process is almost finished. It is now necessary to gain the knowledge gained and to develop concrete suggestions for improvement and to optimize processes. Changes can be made internally, e.g. by extending the authority of employees, or externally, e.g. through the optimization of advertising content. After a pre-defined period, the effectiveness of the strategies should be evaluated and their effectiveness reviewed. This can happen on the one hand by comparison with the values before a conversion, but also by internal employee surveys.


Jobs-to-be-done

The idea of the job-to-be-done approach goes back to Ted Levitt's statement that customers do not want to buy a drill, but a hole in the wall. Christensen, who developed the method to detect customer expectations, says that customers "hired" a product to do a job. This is to show that a customer acquires the benefit of a product and not the product itself, but also the situational context of a use plays a crucial role. Therefore, this method is particularly useful in the context of the UCD and the use of personas to observe customer actions and understand their goals. A simple example is the optimization attempt of a fast-food manufacturer, who wanted to optimize his milkshake offer with the Jobs-to-be-done method, as classic analyzes could not succeed. Customer behavior was analyzed with the question "For which job are my products hired?" As a result of this research, the company found that the majority of Milkshake shoppers consisted of two groups, the first being the product as a pastime for a longer journey to work, and parents who bought the product as a dessert for their children. Based on this knowledge, the product range could be optimized according to the needs and wishes of both groups. On the one hand the offering of thicker straws and the thinning of the shake to achieve a faster consumption of the children to reach on the other hand, the offer of milkshake varieties with small pieces to the pastime of the first group. Another advantage of jobs is their solution neutrality, whereas the tools used for their realization are subject to technological change. Figure 4 shows an illustrative selection of jobs-to-be-done and their solutions over time.


Advantages and Limitations

Advantages of User Centered Design

  • Increased sales through respecting user wishes and needs
  • As users are part of a development process they feel as a part of the project team
  • Less adjustments after a product is released
  • Less user complaints about confusing usability
  • Support savings as users are more likely to understand a product

Disadvantages of User Centered Design

  • High development costs
  • Time consuming development as user interacting takes a lot of time
  • Difficult transition from user data into design
  • Uncertain expectations to the real world use of products by a user
  • No guarantee that a user sample will fit into the real world

Annotated Bibliography

References

  1. https://www.research.ibm.com/compsci/spotlight/hci/p300-gould.pdf
  2. https://www.beuth.de/en/standard/din-en-iso-9241-210/135399380
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox