(UX) design must work
Code testing vs. design testing: a comparison
UX design must work — just like code
Design must work — just like code. When you write source code, you test it. To do this, you first run the code through a compiler. The compiler translates the program code you have developed into machine code - code that can be read and executed by a computer. The parts that the compiler cannot interpret are reported as errors and need to be corrected. Once the code has been compiled - that is, translated completely and without errors - the next step is to carry out what are known as unit tests. This involves automatically testing individual components of the source code. In this context, automated means that the tests themselves are small programs that find errors without user interaction. Software developers therefore have a wide range of tools at their disposal for finding errors. Once found, they can be fixed and the code tested again. This is repeated until the code works.
"Design has to work - just like code. When you design processes and interfaces, you have specific tasks in mind. Tasks that a particular type of user (called a persona) needs to complete. The design works when that persona can easily complete the task with the solution. But unlike code, there is no compiler or automated tests you can run to test the design. Often the design is just shown to the appropriate user and they can give their opinion. However, this is just that: an opinion. Like the programmer, the designer needs objective facts, not subjective opinions, to test and optimise the design. So the question is: how do you find out if the design really works?
How can you test UX design?
As with source code, there is a versatile toolbox for validating UX design drafts to achieve (almost) objective results. One of the best methods is usability testing. The "processor" that "executes" the design is the user - and therefore a human being. But not just any user, but exactly the one whose work and tasks the designer had in mind when creating the design: For example, if it is a tool for building a rocket, you need a rocket designer as a test subject. In usability testing, you give this specific user specific tasks and observe how he solves them using the design you have developed. In the end, it is an active 'look over the shoulder' that allows the designer to identify where the UX design is failing and where it is working. The word active is important here because it is not just about being a silent observer. Instead, the designer needs to make the user think out loud by asking questions: Where was something else expected, and what? How will the design be interpreted? Which part is difficult to understand and why? It is not the simple opinion of the user that counts, but the answers to the specific questions the designer asks during the execution.
How well or poorly a computer reads and processes source code depends not only on the actual code, but also on the overall context - such as the runtime, the CPU, or the operating system. And you have to ask yourself the same question about the context in order to validate the design. Just as important as how the user interacts with the design is the environment in which the design is used. Can the user work in a concentrated way, or will they be distracted? What is the workstation like? What is the main device used? In order to answer these questions, usability tests are carried out on site, i.e. not in a laboratory, but in the user's real working environment. How much context is needed for a test depends on what exactly is being tested.
As with source code testing, usability testing is not a one-off task. Once the design has been optimised, it needs to be tested again - and optimised again, and tested again. This iterative process is repeated until there are no more bugs - i.e. the design works.
“There is no user experience without users”
Code is absolute, design is a compromise
There is a fundamental difference between code and design: The logic in code is absolute. In principle, all hardware processors are standardised and have the same design. This means that the code is interpreted in the same way by every computer. Human users, however, are all different. Even their jobs are not standardised - a rocket designer at NASA works differently to one at ESA. This means that no matter how good the design considerations are, the interpretation is always individual. And as long as people are involved, it will always be individual. As a comparison: If a code works 9 times out of 10, it's really bad code. But if the design works 9 times out of 10, it's great. Programmers ideally have to cover every conceivable borderline case, designers the huge middle ground of 80-90%. But there will always be someone who doesn't quite get it. But as long as the majority of users can work well with the solution, the design works. Code can be perfect.
Design is usually a compromise - because design is used by people. And at the end of the day, the only way to know if the design works in the real world is to work with the users.