The path to an intuitive UI
Just as houses are built for their inhabitants, the development of a frontend should also include its future users. In everyday project life, however, decisions are usually based on business or technological considerations. In order to avoid dissatisfied customers and the development of superfluous frontend elements, we will show a way to focus on the users in the following. How about doing our developers a favour as well?
The realisation that something is not running smoothly in the frontend is initially independent of your own role in the project: regardless of whether you are a project manager, product manager, developer, designer, department head or the management who notice this. You can and should become active in any case. The problems of the users are often overlooked in the company and there are usually no established processes for recognising and solving them.
The more software defines our everyday work, the more important it becomes that it does not frustrate us in the process. Ideally, software responds to our mental model: it maps reality in a way that we intuitively understand. That way, we can work with it to achieve our real goal. Isn't that a beautiful picture? The front end and the user, hand in hand, pulling in the same direction? But how does the user become the heard voice in your company? We want to make the product, and especially the part with which the user interacts directly, more targeted and intuitive in five steps. The way there is demanding.
We will encounter technical, procedural and social challenges. But it is worth taking the path: in the end, we can develop more quickly and flexibly and achieve more in the process. Let's go!
Step 1: Undercover investigation
Before we involve our team and our superiors in the process, we will first investigate our own suspicions that something is not running smoothly in our frontend. To do this, we need facts that show how user-oriented our frontend already is and where there is a need for action. Let's first try to answer the following questions from the checklist below and observe them over a period of 4-6 weeks.
- How often is a design decided in a meeting or by a committee?
- How often do initial statements and assumptions later turn out to be wrong?
- Are the end customers looking forward to new features in the frontend or are they afraid that everything has been made worse again?
- Is data on user behaviour regularly collected and evaluated?
- Is there a flow of information from customer service to the product manager?
- Are there individual decision-makers in the company who set the direction independently of accumulated knowledge?
- How much time is lost because we rebuild a feature for the umpteenth time?
- Do designers or developers often lose motivation and even quit?
An excellent way to take this step is to spend a day or two in customer service and confront the problems encountered there - unfiltered. Go with the field service to the end customer, observe inconsistencies and inquire about ideas for improvement. Ask actively! A look at the statistics or analytics data can also help to identify weak points. If you have collected less than 10 new improvement suggestions in one day, you can consider yourself lucky. But it is more likely that you will find pages and pages of problems and ideas. You can also find more techniques for this step in [Bow10]. And it's best to take them directly to the next step.
Step 2: Build an alliance
When the first results are available and it has become clearer to you how big the problem is and where one could start, the second step is to find allies and carry out experiments together that underpin the insights gained in the first step with further facts and evaluate possible solutions. This way we can get an overview of how big our UX Debt is and what possibilities there are. UX debt is comparable to technical debt, but while technical debt often has delayed and long-term consequences, the negative consequences of UX debt are immediate and directly noticeable for all users. But how can we find allies in the struggle for a good user experience?
Support can come from many positions. Are there developers who seek customer contact? Or product managers who often take up the cudgels for the end user? Who in the team often thinks about the users, but perhaps has not yet been able to bring this to fruition? These people are natural allies to gather further knowledge and develop approaches to solutions. Now you may be wondering how best to convince these potential allies. Take them along to what you have experienced yourself! Meet together with service colleagues. Observe end users together. Share your videos and recordings from step 1. Convince with the real problems and emotions of real users, because nothing has more argumentative power. Once you have your team together, collect more problems.
Your allies should independently - just like you did before - go out and tap into different channels to get feedback from real users. Also, think about what metrics you can use to measure impact. Common metrics are the number of requests made to the service team each day, the time it takes to train new users, and the number of users who get to a certain point. The latter is often put in relation to the number of users who have started a process, which allows us to calculate the rate of successful completion of a process. Using these metrics, we can later weigh different alternatives against each other and thus make data-driven decisions. Together with the problems your allies have found, your list has probably now become so long that you don't even know where to start. Therefore, we now weight the problems according to frequency and impact in order to determine the need for solutions. You will find a template for this in Fig. 2. To illustrate the next steps, let us use an example from mechanical engineering: imagine a production machine that carries out a machining process on a workpiece made of raw material. The front end for the control is visible on a touch screen that is located by the machine.
It shows by way of example which persons (P1 to P10) had which problems and what the consequences were. The degree of impairment results from the assessment of the consequences for the user. If the user cannot reach the destination due to the problem, this is a severe impairment (10 points). However, if he or she can get around the problem by taking a small diversions, the problem is classified as marginal (1 point). In order to have a clear basis for later discussions, we can now classify the problems in an impact chart - see Fig. 2-.
The further to the right a problem is, the more it affects the user. The higher up it is, the more frequent it is. The most urgent problems are therefore to be found at the top right. Now you have a fairly concrete picture of what is going wrong and where improvements are most needed. Time to share these findings with your organisation in step 3!
Step 3: Coming
Out The collected facts are now processed together and used strategically to convince other colleagues. In order to be successful, concrete suggestions for solving the problems and generally improving the development process must be brought along so that the team is not confronted with a problem without a solution. So it is important to find out with as little effort as possible how the most important problems could be solved. Time for prototyping! Even with a small group and little time, it is possible to prototype and test meaningful and useful solution ideas. How? On paper! Imagine that each screen is an A4 page (see Fig. 4). The user "clicks" or "taps" on a sketched "button", then the next screen "loads" (you yourself replace the paper) and it continues. For more tips on creating paper prototypes, see [Sny03]. Clearly, this is different from a screen, but according to researchers at usability.gov [Bai05], a test subject does well with the mental transfer from screen to paper - making test results on paper prototypes valid. In our experience, two people can build a prototype for a feature within two hours, and the evaluation takes another hour or so.
For complex features, you need to weigh up what the focus is for the prototype. Above a certain complexity, it is easier and faster to prototype the feature and test it in the existing interface. Use prototyping to try out solutions for the two most important problems. Iterate a few times and check if your solution is better understood. After two iterations you will already have results to show. You have now not only developed a better user interface with little effort, you have also tested a new development process. And it's fun too! Compare your results with the development process before. Most likely you were faster and needed less developer capacity. These are certainly arguments that can be used to convince decision-makers higher up in the company hierarchy. A brief calculation of the potential savings can also help in the argumentation. Let's assume that improved error messages would save the customer service 10 enquiries of 12 minutes each per day. That doesn't sound like much at first, but extrapolated over a calendar year, it adds up to 60 working days. A sum that clearly justifies the investment in meaningful error messages and possible solutions. Now prepare a presentation on what you have learned. Keep in mind that managers usually think from a business perspective, not a user perspective. The following advantages of a good UX process can serve as a template:
- Increased number of new customers who decide to buy after a trial period.
- Better customer retention (and possibly additional sales) through new, well-integrated and tested features.
- Increased value of the product so that the price can be increased if necessary.
- Reduced development costs. Certainly the strongest argument, because massive savings are possible here if it is examined exactly what should be developed and how, before a lot of time has been invested.
- Reduced UX Debt and therefore less rework and corrections, resulting in a more sustainable, long-lasting product.
Basically, there are two different approaches to working through UX debt iteratively: 1) you use internal capacities and adapt the development process or 2) you hire consultants who already have experience with this in order to avoid capacity bottlenecks in the short term. Depending on the situation in your company, you should propose the appropriate variant. We would be happy to advise you on this and evaluate possible solutions in an initial discussion.
Step 4: Introduce & optimise process In the previous steps, we tried two things: on the one hand, knowledge-creating methods such as observations and analysing customer service requests, and on the other hand, an iterative solution approach with rapid prototyping. We now want to combine these two and integrate them into our normal development process. This requires special consideration for social skills and team structure. The end result is a process that works and is established for the respective team, with iterations and their evaluation at its core.
A common mistake in frontend development is to ask for the end user's opinion only sporadically, when it happens to work out, or even only once in a big heave-ho. We often see the approach of doing an extensive study at the beginning of a project, in which existing products are examined and the end customer is intensively questioned. Findings from this study are helpful, but never sufficient for a successful frontend development process. If assumptions and answers found are documented in writing, for example in personas or a catalogue of assumptions, the development team can later base all new decisions on them and constantly develop the catalogue further. However, if the result of the initial study is only poured into guidelines, such as a design guide, without written documentation, this information will be lost and the team will be stuck with the facts available at the time of the survey.
Experience with user-centred development shows that a continuous improvement process is the best way forward - see also [Got16]. Regardless of whether you work agilely, cross-functionally, in one or in many teams on a product, keep the following points in mind:
- As described in step 3, we always start a so-called design sprint before the actual development, in which we create and test prototypes.
- No decision is made without data. Use your previously defined metrics to help you.
- Every important decision is evaluated with a prototype.
- Each team has at least one UX designer and one front-end developer.
- Good communication and regular coordination between UX designers and frontend developers. Developers should be able to see and try out the prototypes regularly, for example.
With these mechanisms and a continuous feedback process from the project team, it will be possible to identify requirements for the frontend and its architecture at an early stage and to sustainably improve the development process. But how do we optimise the technical side of the frontend and its architecture with regard to user-oriented development?
Step 5: Technical implementation
Since we cannot know all the requirements and the ideal team composition from the outset, we need a flexible architecture. In recent years, a component-based architecture has emerged as particularly good for this. Here, all elements of an application are regarded as individual components that can then be put together like in a construction kit. This also technically facilitates the close coordination between UX designers and developers. Even back-end developers without front-end expertise can contribute their ideas and test hypotheses - without having to be familiar with styling. They can simply reuse the existing components.
This is an advantage that makes it easier for us to inspire developers for the process. For the production machine in our example, it can make sense to completely separate the front ends for normal operators and those for the in-house service technicians. Service technicians often need much more access to extended functions and diagnostic options, whereas normal operators may need to be advised to call a service technician after all.
A separation into two frontend applications simplifies the development processes for both, because not all requirements have to be reconciled. Links at certain points (e.g. if there is an error and the service technician now comes to the machine) are of course still possible and make sense. So that the UX designers can ensure that a uniform appearance is maintained - regardless of how many technically independent frontends there are - and so that every developer can see which components already exist, it is advisable to use a "living" style guide instead of the usual design guide in Pfd format. This should contain examples of each component and explain how it functions and is used. This also makes it easier to create new, context-independent components.
In addition, the style guide can contain generally applicable UX principles in checklist form to ensure a consistent user experience across different applications:
Are all texts easy to read and understand?
- Feedback & Status:
Does the frontend unambiguously show what is happening in every state?
- Mental model:
Are the same designations (e.g. "production job") used throughout and do they always look the same?
What is expected from the users in which error case and how is this communicated to them? Have all cases of error been considered?
Are all contrasts clear enough? Can operators with certain limitations (e.g. red/green deficiency) fully understand the frontend?
Does the operator have to wait anywhere longer than necessary?
On the basis of such a front-end architecture, we are able to react quickly and flexibly to new findings - entirely in the interest of our users.
Effects & Perspectives
The goal of putting the user in focus has many implications that are not limited to the quality of the front end:
- Higher developer satisfaction and staff retention, as decision-making processes are simple and direct, there is less discussion and little code is useless afterwards and has to be thrown away.
- More relaxed management, as there is less guessing and hoping that you are doing the right thing, and more knowing because you have already checked.
- Findings from user research can now also be incorporated into important architectural decisions, so that costly rework can be avoided.
At the end of our five steps, we have a project team that independently gains new insights, solves emerging problems and always keeps the user in mind. This team can serve as a role model for other teams in the company, because what works sets a precedent!
Nevertheless, this is only the first step, because the framework conditions of a product are constantly changing. Teams grow, the market shifts or the company changes. But if we keep applying what we have learned here and question ourselves anew, we can adapt to every change and see and use it as an opportunity.
- [Bai05] Validity of paper prototypes on https://www.usability.gov/getinvolved/blog/2005/06/paper-prototypes-and-software-prototypes.html
- [Bow10] Book: Undercover User Experience by Cennydd Bowles & James Box published by New Riders.
- [Got16] Book: Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf & Josh Seiden published by O'Reilly Verlag
- [Sny03] Book: Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder, published by Morgan Kaufmann.
- [StyleG] To create living style guides: https://patternlab.io & Example from the authors: https://interfacewerk.github.io/iwerk-angular-ui