UX Decoded

Think and Implement User-Centered Research Methodologies, and Expert-Led UX Best Practices

Dushyant Kanungo

• Publisher: BPB Publications
• Year: 2022
• eBook ISBN: 9789355512215
• Topic: Design
• Subtopic: UI/UX Design

Industry-proven methods for determining user needs and designing successful products

Key Features
? Practical approaches for identifying user pain spots, behavior, goals, and overcoming biases.
? Includes detailed examples, graphs, and drawings to explain various user research strategies.
? Industry-accepted approach to product thinking and user-centric design.

Description
This book aims to provide UX professionals with the information, tools, and techniques they need to apply a user-centric approach to product design. It will show you how to learn about your customers' wants and create products that they will enjoy.The book takes the reader on a journey that begins with learning to understand user behavior, needs, goals, and pain areas and then develops solutions to those needs. Next, it delves into a thorough examination of several user research methods that aid in discovering user wants and issues areas and mapping strategies used to portray user research results.The book details a five-stage design process and teaches how to apply problem-first design, design validation methodologies, and numerous user experience benchmarking tools. You also learn to compute UX ROI to properly convey to your business and users why specific UX is excellent for both. This book helps UX professionals utilize the concepts and tools covered in this book to adopt an outside-in approach to design. They first explore and discover user problems and then develop a viable solution.

What you will learn
? Learn to follow a five-step design workflow using the right tools and techniques.
? Use design validation and UX benchmarking to test and enhance your designs.
? Utilize qualitative or quantitative research approaches to conduct user research.
? Visualize user research data using several mapping approaches.
? Improve cross-functional team communication, collaboration, and user advocacy.

Who this book is for
This book is intended for UX designers, product designers, visual designers, UX researchers, and content strategists who seek to improve their UX research and design techniques.

Table of Contents
1. Introduction: You're not the user
2. Watching how people behave
3. Fixing issues: the why and how
4. Hearing what users say
5. Calculating the many and much
6. Synthesis: the power of the affinity diagram
7. Summarizing your research into maps for better communication
8. Prioritizing the use-cases
9. Designing value by fixing the problem first
10. The design workflow: how perfect doesn't always equal pretty
11. Validate your design with usability testing
12. Six aspects of good design
13. Collaborating with multi-disciplinary teams
14. Continuous delivery
15. Final considerations

CHAPTER 1

Introduction – You’re Not the User

Introduction

One of usability’s most hard-earned lessons is that ‘you are not the user.’; concludes, Jakob Nielsen, one of the founding fathers in the domain of studying modern user experience design, in his 2006 article titled ‘Growing a Business Website: Fix the Basics First’.

While the summary of the article states that “Clear content, simple navigation, and answers to customer questions have the biggest impact on business value “, everyone who has written or read a brief from a client, manager, or product owner would instantly identify with these words.

Still, the need to establish a connection between ‘clear content and simple navigation’ while being told that ‘you are not the user’ never quite goes the distance in practice or gets the due it deserves.

It’s tempting for product teams to make assumptions about who they’re building for. This chapter explores the importance of starting with the user and working backward. Developers, designers, and stakeholders have too much insider knowledge and must step out of their studio to get a grasp of their users’ realities.

Biases restrict startups from succeeding and products from going to market. Embracing the detail from the user research allows companies to earn the right to build products for their customers.

Structure

We will cover the following topics in this chapter:

• The ivory tower: OECD study results
• Different biases, and how to avoid them
• Assumptions
• Get out of the building concept
• Defining user experience
• Start with the user and work backward

Objectives

The biggest pitfall of any user experience design exercise remains the fact that often a manager, a client or even a UX practitioner themselves begins to believe that they know everything there is to know about the end users. This assumption has led to numerous failures and caused millions of dollars to go down the drain. The objective of this chapter is to encourage practitioners to take a deep breath and think at least once – what if I am wrong?

We will look at some hard data sources and findings of deep studies before looking at standard (or vanilla) practices to finding the best UX there is for your product or service.

The ivory tower – OECD study results

An ivory tower is a symbolic place—or an atmosphere—where people are happily cut off from the rest of the world in favor of their pursuits, usually mental and esoteric ones.

In the modern-day scenario, it means living in one’s bubble, oblivious to (or refusing to acknowledge) other paths of life and challenges that people face in their lives.

Once we learn to perform a new task, we assume that it should not be difficult for others since we command the new skill at ease. It may have taken us a lot of time and effort, but once we get a hang of it, the sense of ease for the task overshadows the complexities we faced while learning. Riding a bicycle, swimming, driving a car, typing without having to look at the keyboard, playing any musical instrument, juggling three eggs while jumping on a trampoline - if you can do any of this, can you remember the time when you couldn’t? Can everyone do these things? Is there anything on this list that is not feasible to achieve?

Similarly, when we are dwelling on new digital eco-systems, debating about skeuomorphism’s demise, trying out new Git repositories, exploring a new plugin for Sketch, or discussing the latest features and design language upgrades from iOS – remember that not everyone makes a head or tail of what you are talking about.

The skills study

Organization for Economic Cooperation and Development (OECD), published a report in 2016 titled Skills Matter: Further results from the survey of adult skills.

The research focused on data from 2011 to 2015 from the 33 industrialized nations about how technology skills vary among a broad population. The research was aimed at people who are between 16 to 65 years of age. The survey targeted at least 5,000 people in each country to quantify their findings, which meant a total of 2,15,942 participants.

The age range here is a significant factor, as they did the research to measure the digital skills of the workforce, excluding people above 66 years of age. Since it has been pointed may times over countless studies that the elderly come with specific sets of usability needs and have significantly lower skills when it comes to digital interactions, exclusion of this sample demographic means that the general population has even lower skills than presented in the findings of this report.

The tests were conducted on similar toolsets to serve an equal number of complexities to users. Each participant was asked to perform 14 computer-based tasks on simulated software in a controlled testing environment in the user’s preferred language of communication.

The participants were asked to perform tasks with various levels of difficulties. The easiest task had clear instructions to follow, ‘reply to all three people in the mail thread’ - explicit, direct, single step and with a single constraint of three people.

The complex task was to schedule and book a meeting room based on the information gathered from referencing multiple emails in a scheduling application. For many of us who have become accustomed to checking mutually shared calendars and booking meeting rooms with options for virtual participation from people in multiple time zones, this may feel like an everyday chore.

Instructions for this supposedly difficult task were implicit. There was a degree of switching and referencing between data sources that was required. The cognitive load and emotional pressure of not making a mistake while trying to perform a task that may be simpler without the use of a computer may be too much for some users.

The results

In broader strokes, the report concludes that across the 33 rich countries where the study was conducted, only 5% of the population has high computer-related abilities, and only one in three people can complete medium-complexity tasks.

The participants were divided into four levels of proficiency based on their abilities to complete tasks of various difficulties:

• Level <1
  • 14% of the adult population
  • Tasks in this category were singular, explicit, and direct action based
  • The participants in this category were able to perform simple tasks such as deleting an email message in an app
• Level 1
  • 29% of the adult population
  • Tasks in this category may require a few steps and minimal or optional operators
  • The email reply to all the people in the existing thread is an example of level 1 complexity
• Level 2
  • 26% of the adult population
  • Tasks at this level can be generic or specific technology operations that may be explicit and may involve multiple steps and operators
  • An example task would be to find a financial report sent to you by a client at the end of the last quarter
• Level 3
  • 5% of the adult population
  • This is where the most skilled participants were categorized
  • The tasks typically require the use of both generic and more specific technology applications where the task may include multiple steps and operators
  • The scheduling task from the example above falls under this category, or an example can be determining how many people have sent emails for overlapping holidays for Thanksgiving

And yes, you are correct when calculating that the total number of participants in each of these categories only gets to 74%.

Now hear this, over a quarter of the participants, which is a mountainous 26%, did not perform any task as they cannot use a computer at all.

This is your level 0.

The following figure explains the graphical representation of the OECD skills study results.

Figure 1.1: The stacked bar graph represents the country-wise distribution of people’s proficiency level in using computers

Now, imagine that you have designed a screen where a user can book a meeting by cross-referencing participants; invite multiple stakeholders in multiple time zones; and it would be easy to perform this task.

Think again.

Your computer skills are in the top 5% to 8% of the entire population of 33 of the richest countries in the world. Thinking from another point of view, about 95% in the US cannot use computers as efficiently as you can.

Where does it lead us?

You can do a lot on computers, but everyone cannot.

Deciding on behalf of the users is simply preventing them from using your design.

If your designed solution cannot be used by people who are categorized in level 1 of the proficiency matrix, you are serving only one-third of the population. Here are a few things to remember when designing for people at level 1:

• Ensure that little or no navigation is needed to access information
• Only a few steps and minimal operators are required
• Keep the criteria explicit
• Limited need to switch between information sources
• Provide shortcuts, transformations, and helpers
• Keep the information uniform

You are not the user.

Different biases, and how to avoid them

Acknowledging the fact that translation of a requirement coming from a specific industry is a task in itself. The clients would sometime have a vague idea about how the application will help them grow their business or the industry it is going to support without a clue about what the actual flow or interaction of the said solution will be. It becomes the duty of the practitioner to educate and guide the clients about how their users will navigate from point A to point B.

Sometimes, this consolidation of user journeys with the client-end stakeholders, based on the client requirements for the solution, takes multiple interactions and iterations and is often misjudged as user research.

Consolidating the requirement with the client and getting them onboarded with the ABCs of how a software works (i.e., why they have to support a recover password feature, why they cannot charge the user without their consent, or why an admin should not be able to see the passwords from the backend) is not the same as understanding the end-user from a specific domain who is targeted for the solution in question.

Contrary to the scenario mentioned above, clients sometimes come for UX consultation with all the knowledge available to them from their solution domain and UX design from endless nights spent over online publications.

You are presented with PDFs full of paper sketches, sample design styles, and exotic interaction design concepts they wish to incorporate somewhere in the application. The request here is to deliver a product so cool that it will be the next big thing and become an overnight success, catapulting them on the ways of Mark, Jeff, or Bill (See, no last name necessary).

In this case, it feels tempting for the design teams to churn out the best of the style guides and design systems to sway the next Steve. And why not?

This time, you finally got the opportunity to work with a client who understands what A11Y means or what NNG stands for or who has meticulously prepared the subscription plans for all the user types going to use their application or (let’s be honest) already has the wireframes.

In both the above-mentioned scenarios, ignoring the end users remains the common factor.

In the process of educating the client, the UX practitioner unwi...

Table of contents

• Cover Page
• Title Page
• Copyright Page
• Dedication Page
• About the Author
• About the Reviewers
• Acknowledgement
• Preface
• Errata
• Table of Contents
• 1. Introduction – You’re Not the User
• 2. Watching How People Behave
• 3. Fixing Issues – The Why and The How
• 4. Hearing What Users Say
• 5. Calculating the Many and the Much
• 6. Power of Affinity Diagrams
• 7. Summarizing Research into Maps
• 8. Prioritizing Use Cases
• 9. Product Thinking: Designing Value by Fixing the Problem First
• 10. The Design Workflow: How Perfect Doesn’t Always Equal Pretty
• 11. Validate Your Design With Usability Test
• 12. Six Aspects of Good User-Centered Design
• 13. Collaborating With Multi-Disciplinary Teams
• 14. Benchmarking and Continuous Deployment
• 15. Final Considerations
• References
• Index