I went to a retrospective of Dieter Rams design work at the London Design meseum during the summer. He’s the master of the simple, elegant and functional aesthetic. I could really see where Jonathan Ive gets his inspiration.
Quite helpfully, he came up with 10 design principles:
Good design is …
- a useful product
- aesthetic (has beauty)
- an understandable product
- thorough down to the last detail
- environmentally friendly
- as little design as possible
All very Zen, but how can we put this to good use in the software world ?
Applied to user interface
A useful user interface clearly presents the information without requiring interaction. In the UI context useful and understandable are synonymous. Read Magic Ink: Information Software and the Graphical Interface by Bret Victor for more on the perils of interactivity. You can find out if your UI is useful by doing usability testing.
Dont rely on fashions or fads. Instead, try and understand the principles of graphic design such as layout, color, typography. If you use as little design as possible your interface should be long lasting in that it will never look out of date.
An unobtrusive design is free from unnecessary ornamentation. What Tufte would refer to as “administrative debris” :
“The idea is that the content is the interface, the information is the interface not computer administrative debris.”
You can really be ruthless in pruning here. See how Ryan Tomayko improved his website based on Tufte principles .
I would agrees that aesthetic or beauty is important to good desgin. Despite the current trend for A/B tested hyper optimised pages. For one thing, it gives you pride in your work.
Applied to software (code) design
The first crtieria of well designed code is that it is actually useful. Trite though it may sound, it must do what it’s supposed to do without bugs.
Your code should be understandable by end users and developers. For end users, speak and understand THEIR language. Use as little jargon as possible. For developers, your code should read as close to pseudo-code as possbile.
As little design as possible. Amen to that. Don’t try and over-engineer your application and beware gold plating. Use design patterns and complex algorithms to solve a problem, not improve a solution.
How can you make your code long-lasting? By making it (a) easy to change and (b) resilient to failure. For example, (a) one of your vendors has gone bust and you have to replace a key piece of your architecture. You should have a layer of abstraction where you can plug in the new vendors code in ONE PLACE. Similarly, your new vedor is flaky but solvent. You can mitigate this by (b) handling outages gracefully and storing missed calls in a queue and try again later.
- If you haven’t already, you should Magic Ink: Information Software and the Graphical Interface by Bret Victor. It’ll change the way you think about interface design for ever.
- Dieter Rams on Wikipedia
- Nice explination of Dieter Rams 10 principles