10 design principles — for developers
Gist: I’ll try to explain Jakob Nielsen’s 10 design heuristics. I use examples that you, as a developer, could relate to — so that the products you ship and the code behind them would be more usable.
Why Should I Care?
Developers are designers too, they just use a different medium.
As such, you know that how you design the system is as much a part of what you ship, as the end product itself.
Focusing on making the underlying design more usable will help determine, amongst other things:
- How easy it is to on board new developers.
- How easy is the system to maintain and how flexible it is to change.
- How productive you are, as the developer working on the system.
While working with developers, I found out that these concepts already exist among programmers — they’re just not as articulated as they are for designers. Much is to be done, but the foundation is already set. Isn’t that good news?
*I haven’t gone into actual code in any of my examples as I feel people can be a bit too touchy about the right way to write any piece of software.
**Like designers, programmers enjoy applying their creativity to solve complex problems. I would rather have you think of the following list as guidelines to designing systems rather than a set of strict rules saying “This is the best way to do X.”
Design Heuristics. Heu-what?
Heuristics is simply learning through your experience. It’s a method for finding the usability problems in a user interface so that they can be attended to as part of an iterative design process.
When we get 3–5 usability experts to use our product and judge its compliance with basic usability principles a.k.a “The 10 Design Heuristics”, that’s heuristics simplified.
Let’s begin, shall we.
1. Visibility of system status
Ever uploaded an image to a website? Perhaps an avatar for a social network?
This principle expresses the notion that a system should always keep you informed about its current state. Above example just tells you what’s the status of the upload. Seeing its progress makes a user comfortable, don’t you think?
2. Match between system and the real world
When writing documentation or naming a component, always try to use familiar terms. Understand who is this aimed for, and try to use words, phrases and concepts familiar to him.
3. User control and freedom
A system should allow you the freedom to explore its contents, but do so in a responsible manner, such that lets you recover from mistakes should you make one.
Support undo and redo.
4. Consistency and standards
Apple and Microsoft both have different opinions as to the order of the “Ok” and “Cancel” buttons. Which is better?
Well, neither, or both… It doesn’t matter. What does matter is that you make sure to keep all interactions with the system predictable for your user.
You achieve this by not making users wonder whether different words, situations, or actions mean the same thing in different contexts.
5. Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
“When we started up in our plant… …we had people in QA who used to try to find defects in our products, and we moved them all out onto the production line to figure out how to make stuff without defects in the first place… You will be amazed at how much faster you go when you make stuff and defects are caught when they occur instead of being found later.”
-Mary Poppendieck
6. Recognition rather than recall
Showing users things they can recognize improves usability over needing to recall items from scratch. It’s the extra context that helps.
The CLI (Command Line Interface) is the perfect example of one that disregards this principle entirely and by doing so, it elegantly demonstrates it. (what it lacks here, it makes up for in “Flexibility and efficiency”, up next).
7. Flexibility and efficiency of use
Provide an underlying, hidden layer on top of your system to help support experienced users cut through the noise and become more efficient.
The CLI is an example of how powerful such a “hidden” interface can be (which we may even choose to extend).
8. Simplicity
Originally listed as “Aesthetic and minimalist design”. This principle is all about improving the signal to noise ratio.
Every bit of data you give your users will need to compete within some constraint — whether it’s a bloated http request that’s taking up bandwidth, an API filled with cruft (unnecessary content) or an interface that has too many calls for action.
Try to get maximal output, with minimal input.
9. Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem and constructively suggest a solution. Be helpful to your users. Offer a solution always.
Just, this:
10. Help and documentation
I was just as surprised as you are to see this one in a list of design principles.
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.
Conclusion
I hope this was helpful. If you have any questions or remarks, please reach out @NirBenita.
Looking for what to read next?
