UX design: the process with a user always at the centre of attention
We have previously written about user-oriented design and its impact on the conversion of websites or applications. We took a closer look at industrial standards concerning usability and convenience of IT systems. But how does such UX design work in practice?
Our UX design team uses a standard, four-step design process. This division is practical in that it not only allows us to design software but also allows us to deal with the optimization of existing products. These stages do not run linearly, but in iterative cycles, transferring with each other new discoveries and solutions.
If it is necessary to optimize an existing product, after initial work we start with an analysis. It enables us to understand the user and the context in which the product will be used. We try to answer the questions – who will use it? What do you want to achieve with it? How does the user behave online?
Our experience shows that the owner of a website or application is rarely able to answer these questions well. These answers cannot be found in Google, nor is it the case that our experts will provide them during the analysis. Yes, the main errors are easy to spot, but the problem is that this is not strict knowledge. There are no heuristics ready to say that it is good and it is bad. The assessment depends on the context, and only real users of the product can provide the context.
That is why we focus on methods based on the active involvement of typical end users. First of all, software tools for registration of user interactions perform well here. People in the UX lab behave differently than in real usage scenarios, e.g. with a smartphone in the bedroom or before a PC on a desk at work.
Using A/B tests and behavioral recording mechanisms such as Yandex.Metrica, we allow users to operate in their natural environment and passively generate the data we need. A few weeks of such tests are enough to draw important conclusions.
So we have the first data about users, we know something about what they need, what they expect. The next step is to create a user persona out of this knowledge. What is a persona? The definition from Wikipedia is simple: Personas are fictitious characters created to represent different types of users who can use a brand, application or website in a similar way. It will soon turn out that there will be at least a few of them. It is for them that we will optimize our product.
One thing must be stressed here. The personas we are talking about in UX design is not the same as personas for marketing. Here we focus on capturing users’ goals and behavioral patterns, not on creating some colorful stories for management. Our personas are always based on real people and analysis of their activity data.
And what if we are dealing with a completely new project? Here, too, we start with the analysis, although it is necessarily much more modest, perhaps we have only the simplest prototypes, user stories. It doesn’t hurt, we’ll come back to full analysis. After this simplified analysis, we will start with the first…
We already have some personas (or at least their sketches), we have the first remarks of the users. Let’s start playing. Not only designers can participate in it, but it is also worth inviting a project manager, programmers, business analysts, and QA people. In this way, we give everyone a chance to get to know the product better, and in the future, we will avoid various unnecessary questions from uninitiated team members.
The whole team should now be presented with the data obtained at the analysis stage. The task of the designers will be to describe the discovered requirements of our users as well as the operational requirements set by the capabilities and technical limitations. In this way, a canvas is created on which we will design – the specifications within which we will move.
When optimizing an existing product, we usually already have a specification. The fact that we have it does not mean that it is a good specification. Sometimes its basic assumptions are wrong. If we see a big discrepancy between the data from the analysis stage and what is described in the requirements, it is time to talk about it seriously with the customer. Maybe he is trying to do something completely different than he should?
Now the team can get started with the most interesting thing, which is UX design. We ask everyone to define user objectives based on our specifications. We write these goals on separate slips of paper and stick them to the board, divided into fields for each personas.
In this way, a scenario map of each user’s story is created. It includes the successive steps necessary to achieve the goal, combined with ideas on how the website or application can help to do it. For example, on yellow cards, we describe the steps that bring us closer to the goal. On the pink cards, we describe what the software has to do in this direction.
It sounds simple as if you have one persona and one task, but when there are many personas with multiple goals, the board turns into a chaotic mosaic. And that’s not all – if the product is complicated, for example, we deal with an online store, we still have to determine how users will move from one goal to another, create an entire information architecture. Thanks to it we should be able to avoid a situation in which the user gets lost and does not know what to do next.
After that, there is pure UX design. We don’t try to make some exact interface mock-ups, it’s just sketches, made first on a sheet of paper, then in Sketch software. The point is not to waste time on precise drawings, but rather to experiment with different projects, different ideas that would meet a specific information architecture.
The models prepared in this way are exported to the Zeplin groupware tool. Team members then have the opportunity to comment on what they think about the solution, suggest other possibilities. Zeplin also simplifies the work of designers and programmers, providing excellent tools for creating an editorial manual and exporting graphics resources.
This is a stage in which we have many versions, many options, many opinions, it is easy to get lost in it. If we feel lost, we go back to the board and read again about the personas that have been defined. After all, we design for the user, not for ourselves.
When this creative chaos can be tamed, the designer builds accurate interactive mock-ups based on the collected information. We like to use the InVision tool for this purpose. In many cases, it allows you to provide something that can be transferred to the next stage.
In a human-centered UX design, the developed solution is tested against the requirements of the end user during the assessment. However, this cannot be done on colleagues. As experts, they are not a representative target group at all. Again, we should strive to observe the reactions of real users. This time it is possible to try out surveys, interviews and usability tests.
If this is not possible, we try to develop A/B test concepts that take into account the real behavior of users. We determine suitable key performance indicators (KPIs) and observe how individual versions of prepared optimizations work in practice. The more we divide the optimized solution into elements, the more precisely we will be able to determine what is good and what does not work.
Once the expected level of KPI growth has been reached, the final solution can be prepared from the verified segments. Then it can be sent to the final assessment. Sometimes, however, it happens that the sum of these best options does not give the best whole. No problem, after all, it is supposed to be an iterative process. Coming back to the table, the conclusions collected during the evaluation will allow improving the project.
Usually, there are three to five such returns to the board. However, the effect is worth it. After all, we get a solution that meets the requirements, a solution that converts much better.
Next time we will tell you how to create a focus group and get information from it that will allow a better conversion.
Also published on Medium.