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 when meeting users and give some indication on how to do it. This article covers two stars to road essentials: the UCD cycle and the UX levels.

Lets start at the beginning and lets review a first big challenge creators of great products are facing:

Challenge #1: “We are not like the users”

The more people are involved in developing a product the more they understand what the system does and how it is meant to be used. Somebody with no or little involvement has a completely different view on the product and will want to do things nobody ever thought of and uses the product in a way the creators did not anticipate. Even where the creators of a product actually are users they are just some of the users.

Here’s an example: Imagine yourself as the creator of an adventure game. You created a witty plot with hilarious characters and most imaginative riddles. Do you think that your evaluation about what you like about the game will be the same as the one from the gamers? How well can you judge the difficulty of the riddles?

There are a couple of consequences to be aware of if you are involved in creating products:

1. The needs you identify by yourself do not really represent the needs of the whole user base.
2. The features and functions you envision by yourself are not necessarily the ones users will want.
3. The priorities you give by yourself are not per se the priorities users will have.
4. How you organize the user interface and design the details by yourself does not match the users’ expectations and tasks.

Or to but it bluntly:

The more we rely on our evaluation of the product we are creating, the more likely the product is going to suck.

What we really need is feedback from people who have not been involved in the development. The more these people are like our future users and the more these people actually do what our users will do in the future, the better we can see what works and what not and what really matters. See also kill or cure – experience the future.

Challenge #2: Products change what users need

Things can become quite interesting once a product is really used. It is most vexing for some of us (for others it is a fantastic opportunity) that launching a new product offers new possibilities that change what people are doing, how they are doing it, what they trying to achieve and thus what they expect from the technology we provide. So the conundrum to solve is:

In order to create great products, we have to anticipate what users will do once they adopted the new technology.

Product and need is an egg and chicken problem (“what is first: need or product?”) and the answer is evolution. So it’s probably a good approach to quickly launch a simple product first, learn from what users love and hate and do and cannot do and then adapt the product quickly to these changing expectations.

By the way, users can get quite creative and do stuff nobody ever thought of doing with products. If we can harness this creative power our products will have an impact on the market.

The deal: meet users to anticipate the future

What I really should have said at the beginning is something like the following:

“The only way to envision the future is to have lived in it yesterday.” – many thanks to Bill Buxton for these wise words.

So while there are big insights to gain from meeting with users when creating products, it’s not the meeting with users that counts but how well we are able to get a glimpse of a possible futures and learn from it.

A bit of UCD background

Here is good place to introduce two models from User-centred Design (UCD). The first model is the UCD cycle from the ISO 9241 standard, or at least the essence from the ISO model.

• Understand users and the context of use and get a gut feeling about what matters to your customers and users and what constraints they are living in.
• Create solutions that you think could be something your customers are eager to buy and users are going to love.
• Evaluate the solutions against the reality.
• Learn from this evaluation about what really matters.

The second model is about the layers of a solution:

• Story: the solution in a nutshell – for whom you provide what value, how this is going to become a worthwhile opportunity, the strategy of installing the product on the market along with a tangible mock-up or demonstration of the product (see also about powerful stories).
• Concept: the key decisions that need to be made, e.g. about choice of technology, internal structure and structure of the user interface, and much more.
• Details: all the tiny bits and pieces that need to fit together neatly so users have a real great experience.

Meeting with users is integral part of the user-centric design. Applying the UCD cycle helps that the new product fits into the tomorrow’s world. While the basic operation principle of the UCD cycle (understand – create – evaluate – learn) remains the same, the level changes while an new innovation matures.

Stars – meet users in daily life

While working on an utterly normal daily routine task, some synapses in somebody’s brain connect and that person has a first glimpse of the story and acts upon it. The better the understanding of users, the more likely people have insights relevant for users.

An organisation thus needs (1) to meet with users (e.g. through social networks, by participating in peoples lives, or in user groups, conventions, trade fairs, conferences, trainings, site visits and more) and (2) consolidate and disseminate the gained insights. It seems that especially the second activity is most challenging for organisations.

Once an insight happened and a person starts acting on it, the UCD cycles start. The objective is to identify promising stories. The UCD cylce is applied to gain better understanding of users, context and possible solutions. There are many great tools that help: e.g. experience maps, user journey, storyboards, a narrative, or a video prototype just to name a few.

Having many short cycles is much more important than having sound quantitative data. Just go to a place where you can easily get hold of potential users and involve them informally into discussion about their life, your ideas and collect their reactions.

Clouds – explore stories

While doing such UCD cycles, the insight turns more and more into a valid story, a team may form around the story to make it reality, sponsors start providing resources to clear important questions. The insight is becoming a story on cloud level.

Meeting with users here has the goal to shape the story. It’s time to experience the future and to learn from this experiences. Sketch the world tomorrow, let potential users experience this world and learn from it. Usually, you focus each cycle based on an espially important question or hypothesis. There are many great tools around to help you here: wizard of oz testing, user research, lo-fi prototyping, mock-ups etc.

Towards trees – scope the story

The more you talk to users and the more promising the story, the more early adopters will ask when the product is ready. The UCD cycle again changes the focus. The team wants to nail the key concepts and the scope of the first releases of the product so the early adopters can use it.

Meeting users has now the objective to get feedback about the concept: shape, materials, aesthetic expression, information architecture, navigation, basic layout and more. Tools are e.g. lo-fi prototyping, mock-ups, emotional response cards, and design studies.

Towards road – work out the details

From tree to road the characteristics of the team work changes again. Now teams focus on developing the product using their established development processes. The UCD cylce runs within these processes. Meeting users focusses on the concept and especially on making the details work. Tools are still lo-fi prototyping, mock-ups, response cards but also hi-fi prototyping, MvP, pilot runs, walkthroughs, usability testing and optimization.

On the road – manage three levels

As soon as the first product release is on the market and users really start using it, meeting with users serves three purposes. In fact, the team has to juggle three parallel UCD cycles:

1. Optimizing the released features (road)
2. Getting new features ready to release (clouds to road)
3. Having insights for the next story (stars)

New tools are availble once a product is up and running: for example life A/B-testing, UX questionnaires, UX KPI measurement, benchmarking and trend anaylsis. Combined with qualitative work like user research, lo-fi prototyping and similar those numbers give great insights on where to focus optimization and how to enhance the product.

Even though it is quite easy to get overwhelmed by the wealth of work needed for the first and the second UCD cylce, it is important to also have room to join with users, experience the change the released product induced and get inspired for new stories. While your competition is working hard on copying your product you want to be working hard on creating the next great product!

Maybe a summary

Meeting users enables us to challenge our understanding and to gain a glimpse of what the future may hold. UCD cycles are great tools to achieve this: By exposing sketches, mock-ups, prototypes, even products to users a team can get a glimpse of a possible future.

The objective of the UCD cycle changes from stars to road: first it’s identifying stories, then shaping a more attractive story, then scoping the story and working out and optimzing the details.

With the changing objectives the UCD cycle also changes the character:

• Quick informal cylces to identify stories on star level.
• Targeted cycles to check hypothesis and to answer critical question dominate the UCD cycles to reach cloud level
• Feedback loops to check conceptual work and priorities to get to tree level.
• Feedback loops to fine-tune the fit between product and users to get to road level.

And once a product is launched, an organisation needs to juggle meeting with users on any of the levels so they can prepare the next big story while still enhancing and fine-tuning the current story. This is where times really get interesting for product creators.