User-centered design

User-centered design (UCD) or user-driven development (UDD) is a framework of processes (not restricted to interfaces or technologies) in which usability goals, user characteristics, environment, tasks and workflow of a product, service or process are given extensive attention at each stage of the design process. User-centered design can be characterized as a multi-stage problem-solving process that not only requires designers to analyze and envision the way users are likely to consume a product, but also to validate their assumptions with regard to the user behavior in real world tests. These tests are conducted with/without actual users during each stage of the process from requirements, pre-production models and post production, completing a circle of proof back to and ensuring that "development proceeds with the user as the center of focus."[1][2] Such testing[3] is necessary as it is often very difficult for the designers of a product to understand intuitively what a first-time user of their design experiences, and what each user's learning curve may look like. User-centered design is common in the design industry and when used is considered to lead to increased product usefulness and usability.[4]

See also: Human-centered design

The chief difference from other product design philosophies is that user-centered design tries to optimize the product around how users can, want, or need to use the product so that users are not forced to change their behavior and expectations to accommodate the product. The users thus stand in the center of two concentric circles. The inner circle includes the context of the product, objectives of developing it and the environment it would run in. The outer circle involves more granular details of task detail, task organization, and task flow.[2]

History

The term "user-centered design" was coined in Donald A. Norman's research laboratory at the University of California, San Diego. The concept became widely popular as a result of the publication of his book User-Centered System Design: New Perspectives on Human-Computer Interaction in 1986.[5] The concept gained further attention and acceptance in his seminal book The Design of Everyday Things (originally called The Psychology of Everyday Things). In this book, Norman describes the psychology behind what he deems 'good' and 'bad' design through examples. He exalts the importance of design in our everyday lives, and the consequences of errors caused by bad designs.

The two books include principles for building well-designed products. His recommendations are based on the needs of the user, leaving aside what he considers secondary issues like aesthetics. The main highlights of these are:

  1. Simplifying the structure of the tasks such that the possible actions at any moment are intuitive.
  2. Make things visible, including the conceptual model of the system, actions, results of actions and feedback.
  3. Getting the mappings right between intended results and required actions.
  4. Embracing and exploiting the constraints of systems

In a later book, Emotional Design,[6]:p.5 onwards Norman returns to some of his earlier ideas to elaborate what he had come to find as overly reductive.

Models and approaches

For example, the user-centered design process can help software designers to fulfill the goal of a product engineered for their users. User requirements are considered right from the beginning and included into the whole product cycle. These requirements are noted and refined through investigative methods including: ethnographic study, contextual inquiry, prototype testing, usability testing and other methods. Generative methods may also be used including: card sorting, affinity diagramming and participatory design sessions. In addition, user requirements can be inferred by careful analysis of usable products similar to the product being designed.

  • Cooperative design: involving designers and users on an equal footing. This is the Scandinavian tradition of design of IT artifacts and it has been evolving since 1970.[7] This is also called Co-design.
  • Participatory design (PD), a North American term for the same concept, inspired by Cooperative Design, focusing on the participation of users. Since 1990, there has been a bi-annual Participatory Design Conference.[8]
  • Contextual design, "customer-centered design" in the actual context, including some ideas from Participatory design[9]

Here are principles that will ensure a design is user centered:[10]

  1. The design is based upon an explicit understanding of users, tasks and environments.
  2. Users are involved throughout design and development.
  3. The design is driven and refined by user-centered evaluation.
  4. The process is iterative.
  5. The design addresses the whole user experience.
  6. The design team includes multidisciplinary skills and perspectives.

A new framework was proposed as an extension to the conventional UX and UCD models for further research since a class of user might exist that is neither clearly a secondary or tertiary user, nor a stakeholder, but rather a co-dependent user. There may be a case to examine a special class of user experience that may be summarized as a dependent class. This design approach is nominally suggested in a case study as a Dependency-based User Experience (D-UX) approach.[11]

The use of D-UX and D-UCD models has enabled the identification of the needs and preferences of co-dependent users, and this model supplements the conventional UX or UCD model. These ‘special’ situations in which the success of a product design depends not only on qualitative engagement with a target user or user persona (the UX model), or with a particular human user at the centre (the UCD model), but is co-dependent on the equal engagement of a critical co-dependent user. Thus, there is a need for further research in future to test the notion of a co-dependent class of users within the general UX model for special product contexts.

User-Centered Design Process

The goal of the User-Centered design is to make products which have very high usability. This includes how convenient the product is in terms of its usage, manageability, effectiveness and how well the product is mapped to the user requirements. Below are the general phases of User-Centered Design process:[12][13]

  1. Specify context of use: Identify who the primary users of the product, why they will use the product, what are their requirements and under what environment they will use it.
  2. Specify Requirements: Once the context is specified, it is the time to identify the granular requirements of the product. This is an important process which can further facilitate the designers to create storyboards, and set important goals to make the product successful.
  3. Create Design solutions and development: Based on product goals and requirements, start an iterative process of product design and development.
  4. Evaluate Product: Product designers do usability testing to get users' feedback of the product. Product evaluation is a crucial step in product development which gives critical feedback of the product.[14]

In the next steps, the above procedure is repeated to further finish the product. These phases are general approaches and factors like design goals, team and their timeline, and environment in which the product is developed, determine the appropriate phases for a project and their order. You can either follow a waterfall model, agile model or any other software engineering practice.

Purpose

UCD asks questions about users and their tasks and goals, then uses the findings to make decisions about development and design. UCD of a web site, for instance, seeks to answer the following questions:

  • Who are the users of the document?
  • What are the users' tasks and goals?
  • What are the users' experience levels with the document, and documents like it?
  • What functions do the users need from the document?
  • What information might the users need, and in what form do they need it?
  • How do users think the document should work?
  • What are the extreme environments?
  • Is the user multitasking?
  • Does the interface utilize different input modes, such as touch, speech, gestures or orientation?

Elements

As examples of UCD viewpoints, the essential elements of UCD of a website are considerations of visibility, accessibility, legibility and language.

Visibility

Visibility helps the user construct a mental model of the document. Models help the user predict the effect(s) of their actions while using the document. Important elements (such as those that aid navigation) should be emphatic. Users should be able to tell from a glance what they can and cannot do with the document.

Accessibility

Users should be able to find information quickly and easily throughout the document, regardless of its length. Users should be offered various ways to find information (such as navigational elements, search functions, table of contents, clearly labeled sections, page numbers, color-coding, etc.). Navigational elements should be consistent with the genre of the document. ‘Chunking' is a useful strategy that involves breaking information into small pieces that can be organized into some type meaningful order or hierarchy. The ability to skim the document allows users to find their piece of information by scanning rather than reading. Bold and italic words are often used.

Legibility

Text should be easy to read: Through analysis of the rhetorical situation, the designer should be able to determine a useful font style. Ornamental fonts and text in all capital letters are hard to read, but italics and bolding can be helpful when used correctly. Large or small body text is also hard to read. (Screen size of 10-12 pixel sans serif and 12-16 pixel serif is recommended.) High figure-ground contrast between text and background increases legibility. Dark text against a light background is most legible.

Language

Depending on the rhetorical situation, certain types of languages are needed. Short sentences are helpful, as are well-written texts used in explanations and similar bulk-text situations. Unless the situation calls for it, jargon or technical terms should not be used. Many writers will choose to use the active voice, verbs (instead of noun strings or nominals), and a simple sentence structure.

Rhetorical situation

A user-centered design is focused around the rhetorical situation. The rhetorical situation shapes the design of an information medium. There are three elements to consider in a rhetorical situation: Audience, Purpose, and Context.

Audience

The audience is the people who will be using the document. The designer must consider their age, geographical location, ethnicity, gender, education, etc.

Purpose

The purpose is what the document targets or what problem the document is trying to address.

Context

The context is the circumstances surrounding the situation. The context often answers the question: What situation has prompted the need for this document? Context also includes any social or cultural issues that may surround the situation.

Analysis tools

There are a number of tools that are used in the analysis of user-centered design, mainly: personas, scenarios, and essential use cases.

Persona

During the UCD process, a Persona representing the user may be created. A persona is a user archetype used to help guide decisions about product features, navigation, interactions, and even visual design. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life.[15]

For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design. There are also what's called a secondary persona, where the character is not the main target of the design, but their needs should be met and problems solved if possible. They exist to help account for further possible problems and difficulties that may occur even though the primary persona is satisfied with their solution. There is also an anti-persona, which is the character that the design is specifically not made for.

Personas are useful in the sense that they create a common shared understanding of the user group for which the design process is built around. Also, they help to prioritize the design considerations by providing a context of what the user needs and what functions are simply nice to add and have. They can also provide a human face and existence to a diversified and scattered user group, and can also create some empathy and add emotions when referring to the users. However, since personas are a generalized perception of the primary stakeholder group from collected data, the characteristics may be too broad and typical, or too much of an "average Joe". Sometimes, personas can have stereotypical properties also, which may hurt the entire design process. Overall, personas can be a useful tool to be used by designers to make informed design decisions around, opposed to referring to a set of data or a wide range of individuals.

Scenario

A scenario created in the UCD process is a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story. The story should be specific of the events happening that relate to the problems of the primary stakeholder group, and normally the main research questions the design process is built upon. These may turn out to be a simple story about the daily life of an individual, but small details from the events should imply details about the users, and may include emotional or physical characteristics. There can be the "best-case scenario", where everything works out best for the main character, the "worst-case scenario", where the main character experiences everything going wrong around him or her, and an "average-case scenario", which is the typical life of the individual, where nothing really special or really depressing occurs, and the day just moves on.

Scenarios create a social context in which the personas exist, and also create an actual physical world, instead of imagining a character with internal characteristics from gathered data and nothing else; there is more action involved in the persona's existence. A scenario is also more easily understood by people, since it is in the form of a story, and is easier to follow. Yet, like the personas, these scenarios are assumptions made by the researcher and designer, and is also created from a set of organized data. Some even say such scenarios are unrealistic to real life occurrences. Also, it is difficult to explain and inform low level tasks that occur, like the thought process of the persona before acting.

Use case

In short, a use case describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world. It is represented as a series of simple steps for the character to achieve his or her goal, in the form of a cause-and effect scheme. Use cases are normally written in the form of a chart with two columns: first column labelled actor, second column labelled world, and the actions performed by each side written in order in the respective columns. The following is an example of a use case for performing a song on a guitar in front of an audience.

Actor World
choose music to play
pick up guitar
display sheet music
perform each note on sheet music using guitar
convey note to audience using sound
audience provides feedback to performer
assess performance and adjust as needed based on audience feedback.
complete song with required adjustments
audience applause

The interaction between actor and the world is an act that can be seen in everyday life, and we take them as granted and don't think too much about the small detail that needs to happen in order for an act like performing a piece of music to exist. It is similar to the fact that when speaking our mother tongue, we don't think too much about grammar and how to phrase words; they just come out since we are so used to saying them. The actions between an actor and the world, notably, the primary stakeholder (user) and the world in this case, should be thought about in detail, and hence use cases are created to understand how these tiny interactions occur.

An essential use case is a special kind of use case, also called an "abstract use case." Essential use cases describe the essence of the problem, and deals with the nature of the problem itself. While writing use cases, no assumptions about unrelated details should be made. In additions, the goals of the subject should be separated from the process and implementation to reach that particular goal. Below is an example of an essential use case with the same goal as the former example.

Actor World
choose sheet music to perform
gathers necessary resources
provides access to resources
performs piece sequentially
convey and interprets performance
provides feedback
completes performance

Use cases are useful because they help identify useful levels of design work. They allow the designers to see the actual low level processes that are involved for a certain problem, which makes the problem easier to handle, since certain minor steps and details the user makes are exposed. The designers' job should take into consideration of these small problems in order to arrive at a final solution that works. Another way to say this is that use cases breaks a complicated task into smaller bits, where these bits are useful units. Each bit completes a small task, which then builds up to the final bigger task. Like writing code on a computer, it is easier to write the basic smaller parts and make them work first, and then put them together to finish the larger more complicated code, instead to tackling the entire code from the very beginning.

The first solution is less risky because if something goes wrong with the code, it is easier to look for the problem in the smaller bits, since the segment with the problem will be the one that does not work, while in the latter solution, the programmer may have to look through the entire code to search for a single error, which proves time-consuming. The same reasoning goes for writing use cases in UCD. Lastly, use cases convey useful and important tasks where the designer can see which one are of higher importance than others. Some drawbacks of writing use cases include the fact that each action, by the actor or the world, consist of little detail, and is simply a small action. This may possibly lead to further imagination and different interpretation of action from different designers.

Also, during the process, it is really easy to oversimplify a task, since a small task from a larger task may consist of even smaller tasks. Picking up a guitar may involve thinking of which guitar to pick up, which pick to use, and think about where the guitar is located first. These tasks may then be divided into smaller tasks, such as first thinking of what colour of guitar fits the place to perform the piece, and other related details. Tasks may be split further down into even tinier tasks, and it is up to the designer to determine what is a suitable place to stop splitting up the tasks. Tasks may not only be oversimplified, they may also be omitted in whole, thus the designer should be aware of all the detail and all the key steps that are involved in an event or action when writing use cases.

gollark: If I change one line in my Rust code I can make it generate extremely incomprehensible type errors fairly easily.
gollark: Generally it would just randomly not compile with some incomprehensible type error.
gollark: That is quite something. Rust wouldn't have this issue, of course.
gollark: It's not unnecessary, just mostly unnecessary.
gollark: Given that there are no floats or negative numbers, I feel as if anything above the second derivative is unnecessary.

See also

References
  1. "Cover – Just Ask: Integrating Accessibility Throughout Design". uiaccess.com.
  2. "Notes on User Centered Design Process (UCD)". www.w3.org.
  3. Rubin, Jeffrey; Chisnell, Dana (10 March 2011). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests. John Wiley & Sons. ISBN 978-1-118-08040-5.
  4. Vredenburg, Karel; Mao, Ji-Ye; Smith, Paul; Carey, Tom (2002). "A Survey of User-Centered Design Practice" (PDF).
  5. Norman, D. A. (1986). User-Centered System Design: New Perspectives on Human-Computer Interaction.
  6. "Don Norman (2003) Emotional Design, Prolog-- Three Teapots" (PDF). jnd.org.
  7. Greenbaum&Kyng (eds): Design At Work – Cooperative design of Computer Systems, Lawrence Erlbaum 1991
  8. Schuler&Namioka: Participatory Design, Lawrence Erlbaum 1993 and chapter 11 in Helander's Handbook of HCI, Elsevier 1997
  9. Beyer&Holtzblatt, Contextual Design, Kaufmann 1998
  10. "User-Centered Design Basics". www.usability.gov.
  11. Giusti Gestri, Lisa (2019). "Safety vests for jockeys: a case study of primary and dependent-secondary users affecting the evolution of vest design in the Australian horse-racing industry" (PDF). Cite journal requires |journal= (help)
  12. "Notes on User Centered Design Process (UCD)". www.w3.org. Retrieved 30 March 2017.
  13. "User-Centered Design Basics". www.usability.gov. Retrieved 30 March 2017.
  14. Moen, Ron. "A Review of the IDEO Process". www.rwjf.org. Retrieved 30 March 2017.
  15. "Perfecting your ourufrankline | Cooper Journal". www.cooper.com. Retrieved 2016-01-06.

Further reading

Video
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.