Meeting with users is essential for creating great products

Even though - as a UX professional - I must stress the importance of meeting users, I have to admit that the title of this article is not exactly accurate and just meeting users is not really the point. Having revealed this, I should probably explain what really matters and give some indication regarding how to do it.

The purpose of meeting users

Challenge #1: We who develop a technical system are not like the users.

This has two key reasons: (1) The more we are involved in the development, the more elaborate is our mental model about the system and how the system is meant to be used. (2) Even if we are users, we are just some of them. There are usually many more users with quite different needs and mental models.

Conclusion #1: the more we rely on our own evaluation of the product we are creating, the more likely the product is going to suck

Things are even more interesting. What users really need changes constantly. And it is most vexing for some of us - for others it is a fantastic opportunity - that we who create technical systems drive change. Introducing new possibilities changes what people are doing, how they are doing it, what they trying to achieve and thus what they expect from the technology we provide.

Challenge #2: a new product changes what people need from a product.

The better we can anticipate the change, the better our products will meet the future needs. And to anticipate a change we have just one option: we must create the solution, either as a mock or even as a product, and let users use it as realistically as possible. From this, we can learn what the future could hold. By the way, people can get quite creative and do stuff nobody ever thought of doing with our products. If we can harness this creative power, our products will rock the market. The key is to be one step ahead of the users. While they adapt to the new technology, you observe them, create new ideas and start the next cycle.

Conclusion: the purpose of meeting users is to learn what tomorrow will be.

How to meet with users

Get inspired by life

Usually, meeting with users starts with life as of today. Go and observe people, talk with them about what they are doing, why, what they love and what they hate. You can also become an apprentice and do it yourself, instructed by a master. Identify their tasks, their values and beliefs, what they try to achieve and what hinders them. The goal: Gain understanding of users and their context, identify and test possible stories.

Things to be aware of:

It's a learning process. So, steer your progress with open questions, analyse each session immediately and rework your open questions for the next session.
Participants will give you numerous solutions. Listen and learn what they really wanted to achieve, see the problem and get creative to find an even better solution.
You need a wide range of opinions so pick a wide variety of participants.
The essence of the problem lies in the daily hassles. Thus, you should experience real work, dreams and everyday life. Avoid talking about generalisations.
Capture the details as direct quotes, and collect pictures, materials and forms that people are using. This material will later allow you to quickly create prototypes that can handle real life problems.
You need to consolidate what you learn from several participants: a big wall and sticky notes do the trick.
Be sensitive to commonalities and differences between the different persons you talked to and work them out. There is no average user.

As a result of such activities, you can expect to have much deeper knowledge about users, their life, their work and their dreams, as well as loads of ideas about how to achieve a dream or two.

Evolve the product story

A product story answers the very fundamental questions of the product. Alas, just filling out a lean canvas and an idea sheet is not good enough. We must probe the users and get some more substantial evidence. Is the problem relevant? Does the solution fit? Is it the best possible solution? There are a range of method frameworks like design thinking, design sprint, user experience sketching, contextual design, lean startup and more to help you. Whatever the name, they all basically describe building a team that iteratively creates and evaluates solutions with users.

A few methods to use here for meeting users:

UX sketches, physical mock-ups and paper prototypes
Narratives, storyboards
MvPs and test implementations.
Hallway testing, UX walkthroughs
Wizard of Oz testing
UX questionnaires, metrics and benchmarks
Empathy maps, response cards

There are also techniques to co-create solutions together with selected users, making the feedback loop even faster. In a typical co-creation session, the team chooses one aspect of the solution, creates simple building blocks and lets a group of users work with them. This needs an example: To equip a police car, designers created cardboard models of the equipment to go into the car. They then took an old police car, their cardboard models and asked a couple of officers to place the equipment so it would be best. By doing this, they learned a lot about placement options, constraints, real world issues and elements of police life.

Things to be aware of:

Business analysts, market researchers, UX professionals all talk to the users and collect information but with a different focus. They reach different conclusions and there will be trouble if these do not align well.
Get really creative with how you create prototypes and test them. Prototypes should make it possible to experience the future life with the product and they should be quick and cheap to build.
Try many solutions, your first idea will not always be the right one.
Evaluate the solution in comparison to relevant problems. Avoid letting users explore a prototype on their own or by using artificial tasks. Invest in creating realistic tasks and scenarios. Ideally, users should bring their own work and try to perform it with your prototype.

While doing this, you can expect the story to get clearer and more refined. You also learn a lot about the users, their lives, their work and their dreams, and get numerous ideas relating to the product concept.

Nail the concept

Once you really start developing the product, you will want to define a few fundamental cornerstones of the solution: information architecture, key elements of the visual design, error handling approaches and more. And you will want to test this with users.

Methods that help with meeting with users include

Scenarios, visual scenarios
Wireframes, lofi prototyping
User/usability walkthroughs, hallway testing
UX questionnaires and benchmarks
Empathy maps, response cards
Participatory design workshops, card sorting

Things to be aware of:

You cannot create a product concept without going into details. Take a few interesting key examples (key path scenarios) that require design and create the concept based on these.
Visual design is just like a nice sugar icing on a cake. It sells but a bad cake stays a bad cake. Thus, don't do pixel perfect. Use hand-drawn sketches and wireframes to elaborate the concept. You get a better cake faster.
Try the hallway to get quick initial feedback. Just put your draft sketches on the wall, grab anyone available and let them give you feedback.
The first solution is usually not the best solution. Try different approaches and involve others.
Again, realistic tasks or tasks that people bring with them are what you want to evaluate.

From these activities, you can expect to identify the architecture of the user interface. You will also learn a lot about users, about your story and you will discover numerous requirements and details of the product.

Work out the details and fine-tune your solution

Whenever you need to implement a user story, you will also need to work out the details regarding exactly what to do and how this piece fits into the overall product that has been developed so far. Welcome user input again here. Some methods that help when meeting users:

Hifi prototyping, lofi prototyping
Hallway testing, user/usability walkthrough
Usability testing & usability lab
Business walkthroughs, pilot installations
Life A/B testing
UX questionnaires and benchmarks
Empathy maps, response cards

Things to be aware of:

When working out the details of a user story, start with the real needs and try to identify the simple solution. Avoid implementing wireframes that a UX professional created alone in his cubicle or requirements a BA wrote after listening to a stakeholder. Work as a team: what does the user want to achieve in this story and what is the best way of achieving this, and what should you therefore build.
Fine-tuning the product as a result of a story will also require changes being made to things that are already done and ready.
Let users use the system once a user story has been implemented. Provide a test system so you can measure parameters and obtain feedback.
Setup a simple usability lab if you need to optimise specific aspects. Users can work undisturbed here and video recordings allow you to analyse the details of the interaction.
Not every function has the same importance or difficulty. Test and optimise only what really needs to be optimised.
Don't let users be the first to test. Take a real life story and play it through yourself.

Who should meet with users?

Very simple answer: the team. Not the BA, not the RE, not the PO, not the UX person. You cannot delegate the responsibility for "Great Product" to one person. If the team does not have a sound common understanding of what is really important for users, those with little understanding will introduce small glitches and big blunders. Practical solutions need some compromises and UX skills are excellent assets in a team. But even if UX persons have the most exposure to users, do not let them have the sole contact. Always include other members of the team.

Options on how to get to users

Getting to users can be quite difficult. Here are a few ideas (including how not to meet users and still call it user-centric):

Simulate users, i.e. do it yourself and put on a user's shoes. Ok, not really users but at least you try to look through users' glasses.
Replace users with anybody over the hallway. Still not real users but at least people who are not experts on the system and will point out issues to which you have become blind.
Replace users with people who know the users: Trainers, retailers, support, service engineers and similar. Even though they are not users, they may have good insights about users.
Hold informal meetings and use your network to reach users. An easy way of getting access to users for a short session. A network is obviously needed.
Hitch-hike on field trips somebody else is doing (e.g. a service engineer, sales people)
Go to a place where you are likely to find users and get people to talk to you.
Go up the hierarchy to request users for a session.
Request users as members of your team for 30% to 50% of their time. Make sure that these users are still doing their normal job so they don't unlearn being users. Preferably experienced and expert users rather than novices.
Establish a user pool that you can use for sessions. Be aware that these users are usually locals and do not represent the whole world.
Use recruiting companies to organise "users" from their pool. Needs a precise profile describing what you require.
Open up your development to the general public and let users join the discussion.
Install your development team right next to your users, so you can just walk over and talk to them. There is no better way.

Need a final word?

Here it is, adapted from Google: Focus the team on meeting with users and everything else follows.

By Markus Flückiger