Important point: I will try to explain Jakob Nielsen’s 10 design heuristics. I’ll show you, as a developer, how to make your product and the code behind your product more useful.
Why should I care?
Developers are designers, they just use a different medium. Therefore, knowing how to design the system is also part of your final product.
Focusing on making the underlying design more useful will help determine the following:
Easier for new developers to get started
System maintainability and ease of change
How effective you are as a developer of this system
When I work with developers, I find that these ideas already exist among programmers — they just haven’t expressed them to designers yet. Much more needs to be done, but the foundation is there. Isn’t that good news?
There wasn’t any actual code in my example, because I think people are too sensitive about the right way to write any software.
Like designers, programmers like to use their creativity to solve complex problems. I’d rather you consider the following rules for designing systems than a set of strict rules that say “this is the best way to solve the problem of (b).”
What are design heuristics?
Heuristics are just learning from your experience. It is a method for finding usability issues in the user interface so that they can participate as part of the iterative design process.
We get 3-5 heuristic design experts to use our product and determine if it meets the most basic usability rule, which is “10 design heuristics” compliance, which is a simplification of heuristics.
So let’s get started.
1. Visibility of system status
Ever uploaded images to a website? Like a profile picture on a social network?
The main rule is to always keep you aware of the status of uploads. The above example just tells you the status of the upload. And seeing it improve makes users more comfortable, don’t you think?
2. Matching between the system and the real world
When writing a document or naming a component, always try to use familiar terminology. Understand who your target audience is, and then use words, phrases and concepts they are familiar with.
3. User control and freedom
The system should allow you the freedom to explore its content, but in a more responsible way, it should allow you to recover from mistakes you might have made. For example, support for “undo” and “redo”.
4. Consistency and standards
Both Apple and Microsoft disagree about the order of the OK and Cancel buttons. Which is better?
Neither good or both good? Of course, it doesn’t matter. What matters is that you make sure all user interaction systems are consistent.
To do this, you should not leave your users confused as to why different words, different environments, or different operations get the same results.
5. False prevention
It is important to prevent errors in the first place where they can occur.
When we started, we had QA people looking for defects in our products to ensure quality. Then put them on the production line and ask them to figure out how to make a product without defects from the very first step. You’ll be surprised how efficient it can be when flaws in something you’re doing are discovered first rather than last.
– Mary Poppendieck
6. Identification
Displaying a logo that improves user usability is another helpful thing.
The CLI(command line interface) is a prime example of a complete disregard for this principle and, in doing so, demonstrates elegance (it makes up for what it lacks in flexibility and efficiency).
7. Flexibility and efficiency
Provide a latent, hidden layer on top of your system to help experienced users become more efficient through “noise”.
The Cli is an example of how powerful “hidden” interface functionality can be (we can even choose to extend it).
Concise 8.
Originally listed as “aesthetic and minimalist design”. This principle is about improving the signal-to-noise ratio.
All the data you provide to your users needs to be constrained — whether there are bandwidth hogs for bloated HTTP requests, flawed apis, and interfaces that require too many requests.
Maximize output with minimum input.
9. Help users identify, diagnose, and recover from errors
Error messages should be expressed in plain language (no code), show the problem precisely, and constructively suggest a solution. It is useful to the user. And offer a solution.
Just like that.
10. Help and documentation
I was as surprised as you were to see this on the list of design principles.
Even if a system can be used without documentation, it is best to provide help and documentation. Any such information should be easy to search, focus on the user’s task, list specific steps to take, and should not be too large.