Why Understanding Users Matters

When people first begin designing software, they often focus on the software itself. What features should it have? What should the interface look like? How should the database be organized? These are important questions – but they are not the first questions.

Before deciding what to build, we need to understand who we are building it for. Software exists to help people accomplish something. If we do not understand those people, even well-written code and attractive interfaces may fail to solve the real problem.

Good software begins with understanding users.

Every Requirement Represents A Person

Requirements often look technical. For example: The system must allow users to reset their password. Even though this requirement is written from the perspective of the system, behind that simple sentence is a person. Perhaps someone has forgotten their password while trying to register for an appointment. Perhaps they are anxious because they need information quickly. Perhaps they have limited computer experience.

The requirement is not really about passwords. It is about helping someone recover access when they need it.

Whenever you write a requirement, ask yourself: Who benefits from this? Who needs the functionality described by the requirement to happen?

Keep focus on the user. In fact, you should write your requirement from their perspective. Instead of “The system must allow users to reset their password”, write “Users must be able to reset their password.”

Who Are The Users?

One of the first things software designers learn is that there is rarely just one user. Even a simple system may serve many different people. For example, a food bank management system might include:

• clients requesting food,
• volunteers preparing orders,
• staff coordinating deliveries,
• managers generating reports,
• administrators maintaining records.

Each group has different goals, different experiences, and different needs. Designing software means understanding all of them.

Users Are Not All The Same

Even people performing the same task may interact with software very differently. Consider an appointment booking system. Some users might:

• use it every day,
• have years of computer experience,
• prefer keyboard shortcuts.

Others might:

• use it only once a year,
• rely on a smartphone,
• have accessibility needs,
• speak English as an additional language.

Designing for only one type of user often leaves others behind. Inclusive software considers the diversity of its users.

Goals, Tasks, And Frustrations

Users rarely care about software. They care about accomplishing something.

For example, people rarely wake up thinking, “Today I hope I can use a fantastic database.” Instead, they think: “I need to book an appointment” or “I need to find my prescription” or “I need to submit my assignment.” Software is simply the tool that helps them achieve those goals.

As software designers, we should focus on understanding:

Goals

What is the user trying to accomplish?

Tasks

What steps must they complete?

Frustrations

What currently makes those tasks difficult? Often, the frustrations reveal the greatest opportunities for improvement.

Empathy In Software Design

Empathy means trying to understand another person’s experience. It does not mean agreeing with every opinion or accepting every request without question. Instead, empathy encourages us to ask:

• What challenges is this person experiencing?
• Why is this task difficult?
• What pressures are they facing?
• What assumptions am I making?

Empathy helps us design software that fits naturally into people’s lives rather than forcing people to adapt to poorly designed software.

Avoiding Assumptions

One of the biggest mistakes new software designers make is assuming they already understand the problem. Perhaps we think: “Everyone would obviously want this feature” or “That process seems simple.” The danger is that our own experiences may be very different from those of our users.

Good software designers remain curious.

Instead of assuming, they ask. Instead of guessing, they observe. Instead of defending their ideas, they test them. Remember: Assumptions are not evidence.

Whenever possible, verify your understanding with the people who will actually use the system.

Understanding Users Changes Design

Imagine designing a website for a food bank. Without understanding users, you might create:

• dozens of menu and grocery options for the clients of the food bank,
• detailed reports,
• advanced filtering tools.

After talking with volunteers, however, you discover that most simply want to:

• view today’s deliveries,
• update an order,
• print labels.

The design becomes much simpler. Understanding users often removes unnecessary complexity.

Good design is not about adding features. It is about solving the right problem.

Activity: Consider The Users

Choose an application you use regularly.

Examples might include:

• a banking app,
• a fitness tracker,
• your university learning management system,
• a grocery delivery app.

Answer the following questions:

1. Who are the different users of this system?
2. What is each group trying to accomplish?
3. What frustrations might they experience?
4. Which users appear to have been prioritized?
5. Which users may have been overlooked?

Discuss your answers with a partner.

A Final Thought

It is easy to become excited about technology. But users rarely care which technologies were used to build a system. They care about whether the software helps them accomplish something important.

Throughout this textbook, you will learn many methods for planning, organizing, designing, and evaluating software. All of those methods begin with one simple idea: Understand the people before you design the technology.