The Path to an Intuitive UI
Just as houses are built for their inhabitants, your future users should also be involved in the development of a frontend. In everyday project work, however, decisions are usually based on business-related or technological considerations. In order to avoid unsatisfied customers and the development of superfluous front-end elements, we show a way to focus on the users in the following. How about doing our developers a favor as well?
The awareness that something is not running smoothly in the frontend ares is initially independent of your own role in the project: whether you are a project manager, product manager, developer, designer, head of department or the management who notices. You should take action in any case! After all, user problems are often overlooked in the company and there are usually no established processes in place to identify and resolve them. The more software defines our daily work routine, the more important it is that it does not frustrate us. Ideally, software responds to our mental model: it maps reality in a way that we understand intuitively. We can work with that to achieve our actual goal. Isn't that a beautiful picture? The frontend and the user, hand in hand, pulling in the same direction? But how can the user get heard in your company?
We want to make the product, and especially the part the user interacts with directly, more targeted and intuitive to use in five steps. The path to this goal is challenging. We will encounter technical, procedural and social challenges. But it's worth taking the path: in the end, we can develop fast and flexible and achieve more. Let's get started!
Step 1: Undercover investigation
Before we involve our team and our seniors in the process, we will first investigate ourselves why our frontend is not running smoothly. For that, we need hard facts that show how user-oriented our frontend already is and where we need to take 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 decision made in a meeting or by a committee?
How often do initial statements and assumptions later turn out to be wrong?
Are end customers looking forward to new features of the user interface or are they afraid that everything will be turned upside down?
Is user data collected and evaluated regularly?
Is there an information flow from customer service to product management?
Are there individual decision-makers in the company who set the direction independently of the knowledge they have gathered?
How much time is lost because you are rebuilding a feature for the umpteenth time?
Do designers or developers often lose motivation and even quit?
An excellent opportunity for this step is to spend a couple of days in customer service and confront yourself with the problems that arise there - unfiltered. Meet the end customer with the sales team, observe inconsistencies and ask for improvement ideas. 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 of problems and ideas. More techniques for this step can be found in [Bow10]. And it's best to take these directly to the next step.
Step 2: Building an alliance
Once the first results are available and you have a clearer picture of your problem is and where to start, the second step is to find allies and conduct experiments together to back up the knowledge gained in the first step with further facts and evaluate possible solutions. Then we can gain an overview of how big our UX debt is and what options are available. UX debt is comparable to technical deb. But while technical debt often has delayed 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 are looking for customer contact? Or product managers who often take up the cause of the users? Who in the team often thinks about the users, but perhaps cannot put this into practice? These people are natural allies for gathering further knowledge and developing solutions.
Now you may ask yourself how to convince these potential allies. Make them experience what you have alredy experienced! Meet with the service colleagues. Observe end users together. Share your videos and recordings from step 1. Your best argument is the problem and emotion of real users.Once you have your team, collect more problems. Your allies should search independently - just like you did before - and tap different channels to get feedback from real users. Also, think about what metrics you can use to measure impact. Common metrics include 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 reach a certain point within the interface. The latter is often put into relation to the number of users who have started a process, which calculates the successful completion of a process. Using these measures, we can later weigh up different alternatives and make data-driven decisions.
With the problems your allies have found, your list has probably become so long that you don't even know where to start. Therefore, we now measure the problems by frequency and disorder to determine the urgency for solutions. To illustrate the next steps, we will use an example from mechanical engineering: Imagine a production machine that performs a machining process on a raw material workpiece. The front end for the control is visible on a touch screen, which is placed next to the machine.
Fig 1: Usability problems and their urgency
It shows which person (P1 to P10) had which problems and the consequences they leaded to. The degree of disorder results from assessing the consequences for the user. If the user cannot reach the goal because of the problem, this is a serious disorder (10 points). However, if he or she can circumvent the problem by taking a small detour, 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.
Fig 2 Impact-Chart to illustrate the need for solutions
The more a problem appears on the right side of the chart, the more it affects the user. The more the problem appears further up, the more frequent it occurs. 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 organization in step 3!
Step 3: Coming Out
The collected facts shoud now be processed and used strategically to convince other colleagues. In order to be successful you should give concrete suggestions for solving the problems and in general improving the development process. The team should not be confronted with a problem without a solution.
It is therefore important to find out how the most important problems could be solved with as little effort as possible. Time for prototyping! Even with a small group and little time it is possible to develop and test useful solution ideas. How? On paper! Imagine each screen was a DIN A4 page (see fig. 4). The user "clicks" or "taps" on a sketched "button", then the next screen "loads" (you yourself change the paper) and it continues. For more tips on creating paper prototypes see [Sny03]. Sure, it's different from a screen, but according to the researchers of usability.gov [Bai05] a test person succeeds in the mental transfer from screen to paper very well - so that user test results on paper prototypes are valid! In our experience, two people can build the prototype for a feature within two hours, the evaluation takes another hour.
Fig. 3: We test a prototype with a real user to find further improvement possibilities.
For complex features you have to decide on the focus of the prototype. Reaching a certain complexity, it is easier and faster to implement the feature prototypically and test it in the existing user interface. Use prototyping to try out solutions for the two most important problems. Iterate a few times and check if your solution is understood better. After two iterations you will have results that you can show off.
Not only have you now developed a better user interface with little effort, you have also tested a new development process. And probably it is also fun! Compare your result with the development process before. Most likely you were faster and needed less development capacity. These are certainly arguments that can convince decision makers higher up in the company hierarchy.
A brief offset of the new savings opportunities can help with the argumentation. Let's assume that improved error messages would save the customer service department 10 queries of 12 minutes each per day. That doesn't sound like a lot, but projected on a calendar year, this would result in 60 working days of saved time. A sum that clearly justifies the investment in usability problems and possible solutions. Now prepare the things you have learned in a presentation. 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:
Reduced development costs. Certainly the strongest argument, because massive savings can be made here if one carefully examines what should be developed and how, before a lot of time is invested.
Increased number of new customers who decide to buy after a trial period.
Better customer retention (and possibly additional revenue) through new, well integrated and tested features.
Increased value of the product, so that the price can be increased if necessary.
Reduced UX debt and therefore less rework and corrections, resulting in a more sustainable, longer lasting product.
There are in fact two different approaches to work through UX debt iteratively: 1) use internal capacities and adapt the development process or 2) hire consultants who already have experience in this area to avoid capacity bottlenecks in the short term. Depending on the situation in your company, you should suggest the appropriate solution. We can advise you on this and evaluate possible solutions in a first meeting.
Step 4: Introduce & optimize process
In the previous steps, we tried two things: on the one hand, knowledge-based methods such as observations and the analysis of customer service requests, and on the other hand, an iterative approach with rapid prototyping. We now want to combine these two and integrate them into our everyday development process. This requires special attention to social competence and team structure. The 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 only occasionally invest to know the end customer's opinion, or even only once during one large initiative. Often we see the new approach at the beginning of a project, in which existing products are examined and the end customer is interviewed intensively. Findings from this study are quite helpful, but never sufficient for a successful frontend development process. If one documents assumptions and found answers in writing, for example in personas or an assumption board, the development team can later base all new decisions on it and continuously develop the board. If, however, the results of the initial study are put straight (without written documentation) into guidelines, such as a style guide, this information is lost and the team sticks to the facts available at the time of the survey.
Experience with user-oriented development shows that a continuous improvement process is the best way to go - see also [Got16]. No matter if you are working on a product in an agile, cross-functional, in one or in many teams, please consider the following points:
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 a data basis. Use your previously defined measurement parameters.
Every important decision is evaluated with a prototype.
Each team has at least one UX Designer and one Frontend developer.
Good communication and regular coordination between UX designers and frontend developers is crucial. For example, developers should be able to see and try out the prototypes regularly.
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 improve the development process sustainably. But how do we now also optimize the technical development process?
Step 5: Technical implementation
Since we cannot know all requirements and the ideal team composition from the outset, we need a flexible architecture. In recent years, a component-based architecture has proven to be particularly suitable for this purpose. In this case, all elements of an application are considered as individual components, which can then be put together as in a construction kit. This makes it easier for UX designers and developers to work together closely. Even backend developers without frontend expertise can contribute their ideas and test hypotheses - without having to be familiar with the styling. They can simply reuse the existing components. This is an advantage that makes it easier to get developers excited about the process.
For the production machine in our example, it may make sense to separate the frontends for normal operators and those for in-house service technicians completely. Service technicians often need much more access to advanced functions and diagnostic capabilities, whereas normal operators may need to be advised to call a service technician after all. A separation into two front-end applications simplifies the development processes for both, because it is not necessary to reconcile all requirements. 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 useful. To ensure that the UX designers are able to maintain a consistent look and feel - regardless of how many technically independent frontends there are - and that every developer can see which components are already available, it is recommended to use a "living" style guide instead of the usual style guide in Pfd format. This should contain each component as an example and explain its function and use. This also makes it easier to create new, context-independent components.
Fig. 5: Example of a living style guide
In addition, the style guide can contain generally applicable UX principles in checklist form to ensure a consistent user experience across different applications:
Readability: Are all texts formulated in a legible and understandable way?
Feedback & Status: Does the frontend clearly show what is happening in each state?
Mental model: Are the same terms used throughout (e.g. "production job") and do they always look the same?
Robustness: What is expected of users in the event of an error and how is this communicated to them? Have all error cases been considered?
Accessibility: Are all contrasts clear enough? Are operators with certain limitations (e.g. red/green weakness) able to understand the front end without restrictions?
Performance: Does the operator have to wait any longer than necessary somewhere? On the basis of such a front-end architecture, we are able to react quickly and flexibly to new findings - in the interest of our users.
Effects & Perspectives
The goal of focusing on the user has many implications that are not limited to the quality of the frontend:
Higher developer satisfaction and employee retention, because the 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, because there is less guessing and hoping that you are doing the right thing, but knowing it because you have already checked it.
Also, important architecture decisions can now be based on findings from user research, avoiding costly rework.
So at the end of our five steps, there is 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 is what counts in the end! Nevertheless, this is only the first step, because the basic conditions of a product are constantly changing. Teams grow, the market shifts or the company changes. But if we apply what we have learned here again and again and question ourselves anew, we can adapt to every change and see it as an opportunity.
[Bai05] Validity of paper prototypes on https://www.usability.gov/getinvolved/blog/2005/06/paper-prototypes-and-software-prototypes.html (11.01.2019) [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 [Sny03] Book: Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces by Carolyn Snyder published by Morgan Kaufmann [StyleG] For creating lively style guides: https://patternlab.io & example oft he authors: https://interfacewerk.github.io/iwerk-angular-ui/