Are you a member? Register or Login

Design for People, Not Interfaces

Interaction Design has been practised long before the digital revolution, but under different guises and representing many other facets of today’s design language. Once you understand the underlying principles, you will probably realise that everything that has ever been designed effectively, has had some interaction design techniques applied.

Today, we’re going to be delving into this concept a little further, considering how we can use the basics of interaction design to ensure that we’re creating designs that work for people — not just interfaces.

The Ultimate Designer Toolkit: 2 Million+ Assets

Envato Elements gives you unlimited access to 2 million+ pro design resources, themes, templates, photos, graphics and more. Everything you'll ever need in your design resource toolkit.

Explore Digital Assets

The Origin of Interaction Design

Interaction design is a term that Bill Moggridge (founder of IDEO) first coined, but was developed further into a methodology by Alan Cooper in the 80’s. It was based on one simple question that was believed to be lacking from the approach to building software and systems at the time.

“How Do Users Interact With This?”

Today ‘this’ is digital systems or devices – not just websites – but the question can be asked of almost anything that has an interface. Any time someone comes into contact with something (be it a product, device, or digital experience such as a website or app) the goal of the interaction designer is to make sure there are perceived affordances (the quality of an object that suggests how it might be used) and to provide feedback that reinforces correct usage.

The Interaction Design Methodology

Interaction design was explained by Cooper in the following way;

Describe how things behave and then, as necessary, describe the most effective form to communicate those behaviours.

Cooper based the methodology on three areas that lead to producing better products and – by extension – better experiences for users.

1. The creation of personas

Personas are representative biographies of typical users and should include their goals, backgrounds (usually including competencies) as well as any familiar mental models. You should include a quote that can sum them up quickly. A number of personas may be needed depending on how many different user types there are but it should be a minimum of two. This is to help prevent designing just for yourself.

2. The description of scenarios

Key tasks for each persona should be defined to indicate what their needs are in order to compete their goals. In order for you to validate a design; it should to be able to accommodate all of the tasks defined.

3. The creation of storyboards

Whether they are sketches, basic block wireframes or a textual description; storyboards offer a quick way to explore the needs of the persona and how best to tackle their key tasks while at the same time trying to understand any limitations (usually based on their competency).

Following the Process Yourself

Below is an example of some questions that could be asked in order to create personas, scenarios and storyboards.

Who Will Be Using the Interface?

  • Are they old, young, disabled, male, female?
  • What’s their name? Give them an appropriate name and use Google images to find a profile picture (actually Googling the name you’ve chosen can be fun too).
  • What experience do they have? Write a short bio as if it were a mini resume (no more than a few lines) detailing their background and work history. Keep it relevant.
  • To get started you can download an example persona or click the image below.


What Tasks Do They Need to Complete?

  • An example might be ‘filling in customers’ addresses’ or ‘report new enquiries to a manager’, but could equally be something like ‘letting in the cat’.
  • Be clear and concise and don’t make the task description too long. The longer a task is, the more niche and specific the design needs to be to accommodate it. Focusing too heavily on one particular user type may be to the detriment of other users.
  • You may find some tasks can be broken down into multiple smaller ones. This is a good thing as it allows you to design modular, reusable patterns that can be applied across the product to the benefit of all users.

How Do They Complete a Task?

  • Sketch out how a user would complete a task. There are often many ways, so iteration is often necessary. A good technique to quickly establish different approaches is the ‘6-up’ method. Set a timer for 5 minutes and quickly sketch 6 different approaches to a single task. If multiple people are involved you can quickly identify ideas to explore in more detail.
  • Alternatively you can write out a numbered list of each step involved.
  • Remember to make a list or storyboard for each persona that you have defined or show that the task can be completed by multiple personas in the same way.
  • Storyboards can also combine tasks in an attempt to simplify the user flow of the persona.
  • To get started you can download a storyboard template or click the image below.


In reality the process is often preceded by a research phase where you would speak to existing users (if there are any) or users from the target audience and create personas based on them. Basing personas on real people makes them more reliable and can be referenced with more credibility. Without speaking to users, your personas are going to be based on your own knowledge of key tasks and, in all likelihood, you will not be aware of all of them.

Be aware not to ask people what they want to see in your product as generally they are unaware of what they need and only focus on what they think they want. Also people tend to behave differently when under observation. Instead, focus on the negatives of an existing product or competitor to your own product. It is far easier to critique something than it is to complement it.

To quote Plutarch;

To find fault is easy; to do better may be difficult.

Be Aware of Expectations

Knowing that Interaction Design can be applied to anything; think about a light switch for a moment. It is a physical object that has 2 states; on and off. The design is an example of form following function (breaking and completing a circuit). Looking at the sheer number of light switches you can see the evolution to the current accepted design.

Light switches have a very high affordance; people can see from the angle of the switch that there are 2 states. People are aware of the task and aware of the possible outcomes which leads to a high degree of predictability and user confidence. The result reinforces the correct usage (flipping the switch) by turning on the lights. Very clear and unmistakable feedback.

There are still flaws however. There is no visible link from a switch on the wall to the lights in the ceiling. The result is that first time users (without instruction or observation of others) may have a sharp learning curve. Consider when you are likely to need a light switch; when it’s dark. If you don’t know where the light switch is, it becomes difficult to complete the task.

While light switches are still far from perfect; for the most part they have reached a level of consistency and predictability that enhances people’s lives.

How Can We Improve the Light Switch?

Here are some key tasks associated with a light switch.

  1. Locate the light switch when the lights are on
  2. Locate the light switch when the lights are off
  3. Toggle the state of the light switch

The tasks can actually be distilled into fewer if you ignore the current interface. The light switch itself. If you remove the solution you can think about what the key tasks really are.

  1. Turn the lights on when it is dark
  2. Turn the lights off when they’re no longer needed.

Rather than the second task being ‘turn the lights off when it’s light’, the task is more focused on a generic state. This allows the solution to include some kind of intelligent energy saving.

Now think about the different types of user for which the switch would need to cater. It’s not actually everyone as you may first think. Blind people and small children tend not to use light switches but may still have key tasks. When would a blind person need to turn the lights on? When would a child? The tasks remain the same but the personas force you to look at them from different perspectives.

Conclusion & Further Reading

It is difficult to remember not to redesign the interface of an existing solution. Take a step back and look at the keys tasks you have created. Are they about using an existing solution? Or are they accurately describing what a user needs to do.

A task would not be ‘Use the date picker’, that is a an existing solution. The task would be ‘Add a date to a quote form’. Think of a better solution, don’t just design a different interface for the existing one.

You need light to see the switch but you need the switch to turn on the light.

Here are some great places to continue reading a little more about this topic: