Dieter Rams design principles applied to software

Written by Keith McDonnell. Last updated on Saturday, May 08, 2010.

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 …

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.

Further reading

If you'd like to discuss this article, you can send me an email and/or publish an article online and link back to this page.