# User-Centred Design

In the mid 1980s, while on sabbatical at the Applied Psychology Unit at Cambridge University, Don Norman found himself puzzled by the light switches he encountered. Why light switches? As the story goes, the switches moved in the opposite direction to what he expected ("up" denoting "on" by North American convention, while at Cambridge they worked in the opposite direction ). This led him to consider the "perceived affordance" between user and item being used; the visual "hints" that suggest how something should be used. In other words, “how we [manage] in a world of tens of thousands of objects.”

These ponderings eventually led to the publication of his book, The Design of Everyday Things in 1988 [Norman 1988, 2013]. In this book, Norman presents case studies of objects we interact with everyday, from door handles to computers and phones. He shows what good and bad design look like across a wide spectrum of devices, inviting us to think about all the daily "user experiences" we take for granted. He wasn't thinking about software explicitly, but his insights apply equally well to that domain.

For Norman, the two most important characteristics of good design are discoverability -- the ability of a user to determine the purpose of an object -- and understanding -- figuring out how it works and how to use it. From Norman's perspective, good design should make these characteristics obvious and intuitive.

Norman illustrates what he considers the fundamental principles of interaction:

• Affordances: cues that allow a person to figure out what an object does without any instructions. e.g. a door with a "pull" handle (formally called "perceived affordance", which positions then as properties of the perceiver, as much as the object itself).
• Signifiers: visible signs or sounds that communicate meaning. They indicate what is happening, or what can be done. e.g. a door that says "push" on it.
• Mapping: the relationship between two sets of things that conveys associated meaning. e.g. grouping controls and putting them next to the thing that you want to manipulate.
• Feedback: the result of an action, communicated to a user. e.g. a button changing color when depressed; a walk indicator that lights up when the walk button is activated.
• Conceptual models: simplifed explanations of how something works; related to mental models that people automatically form when working with an object to help them explain and predict its behaviour.

"Good design" is about reducing the friction between the user's intention and the outcome of interacting with an object. In order for something to be useful, it needs to serve a clear purpose for some user, and it also should be intuitive to use (in other words, designed using these principles).

So how do we know when we have things "right"? We talk to users! We iterate on our designs, collect feedback and made revisions until we get the best design that we can. Norman's insights kick-started a shift towards design-first, and directly led to the emergence of UCD and modern UX.

User-Centered Design (UCD) is a design process that focuses on addressing the needs of users first, to ensure that we're building a high-quality solution and solving the correct problem for our users. UCD uses a mixture of investigative tools (e.g. interviewing) and generative methods (e.g. brainstorming) to design systems based on user needs, and collect feedback through the process.

# UCD Principles

What are the underlying principles of UCD?

1. Understand and address the core problems. Ensuring that we solve the core, root issues, not just the problem as presented.
2. Be people-centred. We are designing software for people. A well-engineered solution that nobody uses is a failure.
3. Use an Activity-Centred Approach. Design must focus upon the entire activity under consideration, not just isolated components. Most complications result from the interdependencies of multiple parts.
4. Use Rapid Iterations of Prototyping and Testing. Continually test and refine our solution, and get feedback to ensure that it truly meets the needs of users.

# UCD Process

How do we apply these principles? We use a user-centred process like this:

1. Consider your users — perform user testing, and create personas and user scenarios in order to learn more about the ways your users interact with their current mobile products. This will help you gain a higher-level picture of your target users.
2. Prioritize content — your user research will give you a deeper understanding of user expectations. Put this to good use, and focus your attention on designing features and behaviour that users want the most, as well as what your business expects.
3. Review and refine — create wireframes and prototypes of your mobile designs to help your team visualize each screen and its content. Add interaction to make them more lifelike as you move up the prototyping fidelity spectrum.

UCD is frequently mistaken for UX (User Experience). They are related but not identical. User-Centred Design is the process of considering users through planning design and development of a product. It’s a set of steps and methods that we can use to ensure that we are designing for users. User Experience (UX) is the conceptualization of a user’s full experience with a product. It’s concerned with the user's perceptions of the entire solution.

# Understanding Users

The first step to building a solution for someone is to understand who they are, what challenges and constraints they face. You want to be able to clearly state:

• "Who are my users?"
• "What are they trying to accomplish?"
• "How do they relate to the problem that I'm trying to solve?"

This is a key objective that must be addressed up-front. In some situations, you may be told what users to target, and your early efforts might be focused on interviewing those people and to refine your understanding (e.g. imagine you're told to create a new system for airline booking agents; you would probably start by interviewing everyone that relates to that role, who in turn may help you identify other potential users). In other situations, your users may not be obvious: you may need to interview people to determine your potential user base.

Interviews

The best way to understand a set of users is to talk to them! You may need to interview people just to figure out how they relate to your product idea. Start by interviewing potential users, and then look at your results—you can always narrow down to a subset of users later.

Interview guidelines

• Interview 5–6 users [Nielsen 2000]
• Ask open-ended questions to understand what they do, how they work.
• Continue asking questions to identify issues or challenges that they might have.
• Use followup questions to make sure that you understand their goals and motivations.

The outcome from interviews should be detailed interview notes.

Good interview questions:

• Describe a problem that you have.
• How would you accomplish X?
• What do you like about this system? What do you dislike?
• How would you expect (some feature) to work?"

Another useful technique for gathering information is to survey users. Surveys are relatively inexpensive, and it is fairly easy to collect information from a large group of users quickly. However, response rates for surveys tend to be low, and you are limited to fairly simple questions (plus, unlike interviews, you cannot ask follow-up questions!).

From your interview notes, it can be helpful to characterize your target users and the tasks that they want to perform. This involves the generation of Personas and User Stories.

Building Personas

A persona is an archetypal description of a user of your application or product. They are often based on "real people" but are generalized descriptions that represent a category of people that share similar characteristics. We use personas a stand-ins when discussing product goals and features.

Each role or "type" of user that you identified should generate a unique persona. You typically have two or three personas for even a small solution.

To build a persona, you interview one or more users representing that role in an organization. You then write a fictional portrait of a user, which represents the consensus among your users in that role as accurately as possible.

There are some basic elements that your user persona should include:

• Personal info: Present personal information first, including name, job title, company, job description, family status, and more. Include any details that can help your team understand the persona better.
• Demographic info: Other demographic information, such as age, gender, income, education, location, and other background information can help you create a more authentic character.
• Image: Images speak louder than words. A vivid image, sketch, or cartoon can help your team picture your users clearly, and help you establish a consistent understanding of the target users. Use a photo that reminds you of this user.
• Goals: You should also make it clear what your audience wants to get or to do with your product. List all possible goals and motivations that you've found from your user research.

Here's some examples:

You can find our templates in the GitLab public repository repository, but we generally recommend Figma for creating diagrams! It has templates for all diagram types, including Affinity Diagrams, Personas and even UML diagrams.

# Analyzing Interview Data

User Stories

From your user interviews, you should have identified some basic tasks that you will need to address. Often, these will come in the form of stories or narratives from your users, which you've recorded. Your job in this step is to extract these common stories or tasks from your interview notes.

User-Stories are a description of activities that are performed with a system to perform a particular task. A user story is often simple text, and is intentionally describing the problem at a high level:

"As the HR manager, I want to create a screening quiz so that I can understand whether I want to send possible recruits to the functional manager."

"As a user, I can indicate folders not to back up so that my backup drive isn't filled up with things I don't need."

User stories are useful because they help identify users and their high-level goals, and they serve as an excellent starting point for discussions.

User Story Maps

Once you've collected a number of user stories, you might arrange them into User-Story Maps to show their larger relationships. They can also be plain-text, but often include diagrams, sketches and other visual elements that help describe a user's interaction with the system.

Story maps are intended to spark collaboration and conversation among Agile team members, while providing them with the bigger picture of how the digital product flows and fits together. -- Nielsen Norman Group

User Stories Maps often include three levels:

1. Activities represent the high-level tasks that users aim to complete in the digital product. e.g. deposit a cheque.
2. Steps sit directly underneath activities and also display in sequential order. They represent the specific subtasks that users will go through in the product to complete the activity above. e.g. enter pin, select deposit from the menu, and so on.
3. Details are the third level of the story map and describe the lowest-granularity interactions that the team anticipates users will experience to complete the step above. e.g. enter pin by pressing the numbers in order, and ok when complete.

The user stories that you have captured can also be thought of as features of your software. You can (and should) record these in as much detail as you have; it's a good time to create issues in GitLab to document them.

You probably don't want to rush to implement these requirements until you have iterated over them and expanded them a little more. We want to consider a number of different perspectives: technical (can we build this), architectural (what is the impact on the system if we build this) and UX (how well will this work for the user)? Let's consider user feedback first.

Affinity Diagrams

The outcome of your interviews will likely be a lot of qualitative data—opinions, suggestions and ideas that the user expressed. The challenge is extracting ideas, themes from this narrative that you can use in your design.

We use thematic analysis to do this, and the mechanism that we will use is the creation of an affinity diagram.

To create an affinity diagram:

1. Record all notes or observations on individual cards or sticky notes
2. Look for patterns in notes or observations that are related and group them
3. Create a group for each pattern or theme
4. Give each theme or group a name
5. Create a statement of what you learned about each group (provide your analysis or key insight)

You should end up with clusters of related ideas, all around a common theme. You can them examine these to expose critical ideas or themes from the user's ideas. (You can even do this across multiple users and look for themes which occur more frequently!).

Figma has templates for all diagram types, including Personas, Affinity Diagrams, and even UML diagrams.

# Prototyping

From our user stories, we can start to think about user interaction and the user interface. E.g., In our hypothetical note-taking application, we might have identified a user story around multi-user support. That suggests that we need a way to create accounts, store credentials safely, login using those credentials. Once logged in, users probably need a way to change accounts. These are all activities (from our user story map) that require individual screens and an understanding of how the user navigates through these screens to accomplish an activity.

Designing this complex interaction can be challenging. You will want a way to design the user interaction, review it with your team, and get user feedback before implementing it. You don't want to build, discard and rebuild your application as part of your process—that's too costly and time intensive. Instead, we build a prototype-a low-effort implementation that we can use to solicit feedback.

Think of a prototype as a mockup of part of a system. It is NOT an "early version" of release software, but an early demonstration of functionality intended to elicit feedback from users.

Compared to the full implementation, a prototype requires significantly less time to build. This makes it much easier to discard or modify as you work through design iterations. Prototyping lets us get to a final version much faster!

We often characterize prototypes based on their complexity:

• A low-fidelity prototype is deliberately simple, low-tech, and represents a minimal investment of time and effort. They are shown to users to elicit early feedback on layout, navigation, and other high-level features. Low-fidelity prototypes can be sketches on paper, or non-interactive wireframe diagrams.
• A high-fidelity prototype represents a more significant effort and is intended to be close to the final product. They are suitable for demonstrating complex functionality with a high degree of interaction. Commercial products exist for this purpose, e.g., Figma, Miro or Sketch that allow you to "mock up" a user-interface in much less time that it would take to build the final product. These tools provide collaboration features, so that a designer can build up prototypes quickly, demo them to elicit feedback and even make changes on-the-fly.

This diagram shows the progression from low to high fidelity. It's not required to build at different dimensions like this! You want to build at the lowest level that you can for maximum benefit.

User interfaces are interactive! To capture this, our prototypes should include:

• Mockups of all your screens, at a level of detail that shows important information and suggests interaction.
• The relationship between these screens. How do you navigate between them? How are they related?
• Enough clues (affordances) to suggest how functionality is activated. The user should be able to tell how to perform major tasks.

# Intro to Figma

Figma is a collaborative design tool that allows designers to build a range of interactive prototypes. We'll use it to build UI prototypes, and then we can show these to potential users and stakeholders (including our team members) for feedback before we implement features.

Figma is primarily an interactive website (although it also has client applications you can install). Figma has free and paid plans. As a student, you can sign up for a Figma for Education plan for free, which provides paid functionality. Highly recommended while you are still in school!

A design in Figma is meant to encompass all interactions for a product. It consists of:

• a frame, representing a single UI window (e.g. Android Pixel C screen, or 14" MacBook Pro Desktop).
• UI elements, represented by customizable shapes.

Figma presents itself like a vector drawing application, letting you "build" a user interface much like you would in any drawing application. However, unlike drawing applications, it also supports adding interaction e.g. clicking buttons.

You can build your UI screen by

1. Adding a frame,
2. Adding primitive shapes (rectangles, circles) to represent UI elements. Use the property sheet on the right-hand side to align, change properties, and so on.

This is slow; you can also import and use Component Libraries that the Figma community has made available. In a browser, navigate to the Figma Community page. From this page, you can search and import libraries directly into your Figma account.

A library is just a set of predefined components. Using a library instead of designing your own has some advantages:

• You can save a lot of time!
• The components in a library will have a similar look-and-feel.
• You can use libraries to mimic the appearance of standard platforms e.g., iOS.

For example, here's a sheet from the Mobile Wireframe library, which includes iOS, Android components.

You can create a new diagram, and copy-paste these components into your screens. Minimally, your initial prototypes should include labelled wireframe diagrams for every screen (displaying the structure of your application and each of the screens).

To do anything more complicated, it's recommended that you review the Figma Documentation or watch some introductory videos.

# Iterating on designs

You should plan on taking your design back to your team, and to your users for feedback.

• Start with low-fidelity prototypes to capture high-level feedback (e.g. "Does this screen make sense to the user? Do they know what they should do?")
• Once you have addressed high-level feedback, consider adding interactive elements e.g. buttons that navigate through the screens so that you can capture feedback on the interaction, and the larger workflows.
• Save high-fidelity prototypes for complex features or complex interactions.