Who is Dieter Rams ?
Indifference towards people and the reality in which they live is actually the one and only cardinal sin in design.
One of the most influential product designers. He is known for his work at the Braun company where he designed many everyday products like radios, calculators, record players, video cameras and even electric shavers. An architect by training he transitioned to designing products under the tutelage of Fritz Eichler, another influential designer working at Braun.
He is an ardent minimalist and is associated with the functionalist school of industrial design which emphasizes on the principle that buildings should be designed based solely on their purpose and function. Rams is also an idol of the infamous Apple designer Jony Ive and many Apple products pay tribute to Rams' work for Braun, including the Calculator App, which references the 1977 ET66 calculator prior to a redesign. Around the 1970s Rams was contemplating the answer to the question “Is my design a good design?” and the answer he came up with was distilled into his celebrated 10 principles.
Good Design is Innovative
What good is a software feature that doesn’t solve a problem or improve an existing solution to a problem. The purpose of designing a solution is to find a unique solution to a problem.
Good Design makes a Product Usable
Usability is a necessity, Design for the sake of design is pointless, you don’t want to solve problems which are not problems. Good software actually improves someone’s life not just clatters or hinders it and fits the need of its users.
Good Design is Aesthetic
The aesthetic quality of a software product is integral to its usefulness because products are used every day and have an effect on people and their well-being. A software with good UI/UX can bring joy to its users.
Good Design makes a Product Understandable
Design must serve to make the product understandable. As uncle bob once said Architecture screams intent. A software’s design must be focused. Well designed software is intuitive for its users and plays on common interaction patterns to make it self seem familiar at first glance. At best the software is self-explanatory.
Good Design is Unobtrusive
Software fulfilling a purpose are is like a well made tool. Its neither a decorative piece nor a work of art. Its design should therefore be both neutral and restrained, to leave room for the user’s self-expression. Software should never hinder its users ability to perform their tasks.
Good Design is Honest (WYSIWYG)
Software must not misguide or manipulate its users. It does exactly what it looks like. No dark patterns / anti-patterns should be used. Well designed software upholds its dignity and integrity and does not resort to gimicks to please its users.
Good Design is Long Lasting
Instead of chasing new trends or fads a good software architecture should fit the problem in the long term and should survive multiple iterations and functionality revamps. Our industry is every changing and a new trend seems to emerge every few months but the patterns which are timeless such as OOD, FP, GoF, PoEAA are what can always be counted on to design good software.
Good Design is Thorough
Software design and architecture cannot be vague. It cannot simply revolve around high level diagrams and guidelines. It must be detail oriented and take into account all the edge cases that occur in reality. No technical decision must be arbitrary or left to chance. The care and accuracy in fitting the design to the requirements show respect towards the consumer of our software.
Good Design is Environmentally Friendly
Good software design must take into account sustainability. Making efficient usage of hardware resources and not over Not every software projects needs to be broken up into microservices and deployed into a kubernetes cluster.
Good Design is As Little Design As Possible
Less, but better
Well crafted software concentrates on the essential aspects, and it is not burdened with non-essentials, gimicks or fluff. Over engineering solutions only increases the complexity of a codebase. This complexity shows itself in maintenance costs, feature development times and defects. Next time you’re working on a new piece of functionality, think about what really needs your design input, and what’s already been solved for you. The fewer moving parts you have, the less there is to go wrong.