Design has to work, just like code

German version on the blog of generic.de

Quite often I find myself needing to clarify that?#design?is not an opinion, not art, but that design has to work. And that you can see if your design works. As a lot of the people I talk to are familiar with programming, I finally found the right format to bring the point across. Comparing design with code does the trick here.

This has helped people with understanding?#ux, so I thought I'd write it down and share it with you guys. I'm interested in your thoughts on the topic, please share.

Design has to Work

Design has to work, just like code. When you write code, you test it. You have the computer run your code, and it will tell you where you did something wrong. First step is to compile your code. The compiler will tell you the mistakes you did. If your code compiles, you run your unit tests. They will tell you more mistakes. If your unit tests work, your integration tests and scenario tests run, and so on. You got a big toolbox to find bugs. You fix the bugs and run it again. And iterate again. Finally, your code works. Most tests can be automated, so that you have quick iterations and can concentrate on fixing the bugs.

Design has to work, just like code. You design with concrete tasks in mind, tasks that a concrete type of user has. Design works if the user can complete those tasks with it. But there's no compiler or automated tests you can run. Showing your design and asking for an opinion will result in exactly that: an opinion. But you want facts to rely on. So, how do you find out if your design works?

Like for code, there's a toolbox of methods for validating designs, such as the usability test. The processor executing your design is a user, a human being. Not any user, but someone whose work involves the tasks your design was created for: if it's about engineering rockets, you need a rocket engineer. You give the user concrete tasks and observe. Watch the user solve the task, and you will see where your design fails, and where it works. Keep the user thinking aloud. Poking with questions, you learn where the user expected something different. How your design was interpreted. What part is hard to understand, and why. The test result is not some opinion, but facts. You get a list of design bugs you need to fix. This technique is called usability test. Now you improve the design and test it again. And iterate again. Finally, your design works.

If you don't test your designs, it's like you write code, but never run it before you ship it. And how often would that go well?

Context matters

When testing a piece of code, you need to consider its context. For some code the CPU is enough. The next piece might require the full runtime environment. If your code reacts on data that comes from some remote API, you might want to do an integration test, as latency and data quality might matter. The same applies when testing design: some design bugs are obvious to the trained eye and can be found in a review. For some you need at least someone else to try it out. Other bits of design can only be validated with the right end user. And some parts you can only reliably test in the full working environment of that user. There, your findings could be:

• The user is wearing gloves and cannot use your touch interface
• You created sounds that no user will hear in the loud environment of a factory
• Your subtly styled messages get drowned in a flood of visual stimuli
• Semantic color coding differs between your design and existing systems
• Printouts from other systems use different terminology than your design
• The user has your app open in a dozen browser tabs at once and it’s difficult to choose the right one

In each case, the design works in isolated conditions, but not in real life. You need to fix the design, because for the end user it is broken. Of course, most of these issues can be prevented by doing upfront user research before designing the system, like an on-site visit. But you want to make sure that no big design bug slipped your attention before the system goes life.

Code has to work, and design has to work. While code can be perfect, design is mostly a compromise – because it is processed by humans. You need your end users to see if your design works.

The Differences

Two differences between code and design are important. The logic in code is absolute. All hardware processors are standardized, and your code will run basically the same way on every computer. But people are all different, even their jobs are not standardized. No matter how good your design reasoning, the interpretation is always subjective. If your code works in 9 of 10 cases, it's really bad code. But if your design works in 9 of 10 cases, it's great design. Coders need to cover all the edge cases. Designers need to cover the huge common ground. There's always someone who won't get it. But if it works for most users, the design is good enough.

Another difference is that the context of code stays the same, while users develop skills and learn. Of course, there are new versions for a .NET runtime environment, or API changes, but you can integrate those in your automated tests. Human learning makes testing designs difficult. Not every piece of software needs to be totally intuitive. Especially when producing digital tools for professionals, you need to include a learning curve. Users will learn how to use your designs, but only if your design is explorable. This learning process cannot be not substituted by reading lengthy documentation. Your design doesn’t work if you need to explain it to the end user. You want to give your users a head start on that curve, and make learning as smooth as possible. This requires some effort but is way cheaper than badly designed tools for your end users.