Dieter Rams introduced the idea of sustainable development and of obsolescence being a crime in design in the 1970s. Accordingly he asked himself the question: is my design good design? The answer formed his now celebrated ten principles.

Whilst Dieter was an industrial and product designer, his principles can fit anywhere where good design comes into play. In the rest of this article, I will explain what the 10 principles are, and how I think they fit into software development.

The principles in this article are very useful for software developers and designers, but this is also very relevant for technical leaders. As a leader it is good to try and push your teams to make sure they are thinking about the end user. Traditionally, software developers make lousy designers (not all of them before I start a flame war), but aesthetic design, generally, isn’t something that comes naturally to programmers. Therefore having principles like these is great for giving you pause to reflect on how your system / application affects your end users.

The different product images below are examples of products designed by Dieter. Those of you old enough may recognize a few!!

Ten Principles for Good Design

Is Innovative

 “The possibilities for progression are not, by any means, exhausted. Technological development is always offering new opportunities for original designs. But imaginative design always develops in tandem with improving technology, and can never be an end in itself.”

I have talked about innovation before on this blog  I think it is a fundamental building block for how a manager should encourage his team to operate as well as keeping developers motivated and on top of their game. Dieter’s principles fit in with this perfectly. Good design is always about pushing the boundaries of technology and improving technology. Innovation comes from pushing yourself and the systems within which you operate. As the principle states, there is always room for growth. If you are working with a system / architecture that is already very good, that doesn’t mean all the possibilities have been exhausted, you can always find room for improvement, especially as your company grows and the scaling of your system might change with demand. I have found in the past that it is user demand and scale that forces you to innovate when it comes to systems architecture.

Makes a product useful

“A product is bought to be used. It has to satisfy not only functional, but also psychological and aesthetic criteria. Good design emphasizes the usefulness of a product whilst disregarding anything that could detract from it. “

 This speaks for itself. A product should be useful and usable to its end user. This especially applies to software development regardless of whether your software is the product itself or is a supporting system for your business. The most obvious place where this applies is to the user interface and user experience. There have been many books written about user experience and it is a career path all to itself, but regardless of your design prowess, you need to ensure that your software is easy to use and doesn’t create any barriers to the end users. How easy is it to navigate around the system? Is there more than one way to achieve a task? Perhaps there is an easier navigation route for novices in the system where as power users can use a series of keyboard shortcuts. It is always a good idea to design with different levels of user experience in mind. Don’t confuse novices, yet don’t put unnecessary barriers in the way of experts.

This principle doesn’t just apply to the user experience and end users though. Useful ness can apply to good code design too. You should treat other programmers as an end user too. Is the code written in a clean way that other engineers can follow? Have you written sufficient tests to exercise the code you have written? Have you used every exotic language feature under the sun that makes you look very clever but the code is unreadable to less experienced engineers? If so, then you haven’t written clean and useful code. There is a trade-off here between new and exotic features, but have you got the balance right?

Is aesthetic

“The aesthetic quality of a product is integral to its usefulness because products are used every day and have an effect on people and their well-being. Only well-executed objects can be beautiful.”

 For software systems this follows on from the system being usable.  The system may be usable and easy to navigate, but does it look nice and clean? This may seem immaterial, but imagine if you have to use a piece of software all day, every day. Wouldn’t it be much nicer if the software was aesthetically pleasing?

My current team are working on a Call Center application. There is a large team of people that have to sit there talking to customers on the phone and using the software, which is a web application. This system doesn’t have to be the most beautiful system in the world, but we have made sure that it is reasonably good to look at. There are no garish colors on the screen; the colors are all pastel tones so we don’t give the call center agents any eye strain. Information on the screen is laid out in the order that they will need to use it the majority of the time. Controls are not all cluttered together. These are all easy things to do, but they are just as important as the overall functionality.

Makes a product understandable

“It clarifies the product’s structure. Better still, it can make the product clearly express its function by making use of the user’s intuition. At best, it is self-explanatory. “

Can you put a new user in front of your software and they pick it up straight away because it is that intuitive? If not, then your product is not immediately understandable. In a large organisation, this can be very costly. As an example, the company I currently work for operated over 600 retail stores in the UK. Each store has store server and up to 4 PC’s running as tills.

These tills run our own custom Point of Sale software (POS). This POS system is pretty easy to use. It works as a normal till with Cash in and out, but it is also a hub where customers can apply for our loan products. If the system isn’t easy to use then you have a problem, as there are 2400 tills in the estate (600 stores + 4 tills) each has a human user who has to interact with that system. If we push out a new feature and it isn’t understandable we have a problem where up to 2400 people at a time may be confused and there for slow in using the POS. This can be very expensive. I won’t claim to say that we have got it totally right. This system has been running for over 10 years and we are in the process of designing a new one where we have used usability consultants to help make it more usable.

Is unobtrusive

“Products fulfilling a purpose are like tools. They are neither decorative objects nor works of art. Their design should therefore be both neutral and restrained, to leave room for the user’s self-expression.“

Going back to usability and user interaction, everything in your application should have a purpose for being there. The design should be simple and functional. Going back to my example of the call center application that my team are working on, there is nothing in the screen design that shouldn’t’t be there. The system is a tool that people use to do their jobs, and everything has to have a purpose.

Is honest

“It does not make a product appear more innovative, powerful or valuable than it really is. It does not attempt to manipulate the consumer with promises that cannot be kept.“

To me, this reads as, does your system do what it says on the tin. Does the system perform its stated purpose?  Does the system deliver on everything that it has promised? The last thing you want to do is release a system saying it does feature X, and when the end user tried to use that feature, the system fails miserably. This is an example of the system not being very honest with it-self. If you follow agile iterative development and you get to near deployment time and a feature isn’t quite working as you expect it to, then disable it for that release and include it next time around. Your users will thank you for it in the long run and it will be help you prove that your system and your developers are honest in their approach.

Is long-lasting

“It avoids being fashionable and therefore never appears antiquated. Unlike fashionable design, it lasts many years – even in today’s throwaway society. “

How many times have your worked on an application or feature and said “it doesn’t matter if this is not perfect, it will only be in use for a few months”, and then 2 years later you are still trying to support it? I have been there before, and it is not nice as you end up supporting a crappy system that becomes a large piece of technical debt. No matter what you are working on, even if you think it will be short lived, prepare for it to be around a long time. Design your system to last a long time.

The first part of the principle is important as well. This is about avoiding being fashionable. You don’t have to operate on the bleeding edge all the time.  Using slightly older technologies is perfectly fine and in a lot of cases with corporate systems, this is preferable as there will be an inherent level of trust and stability with technology that is a few years old as opposed to something that is very new.

Is thorough down to the last detail

“Nothing must be arbitrary or left to chance. Care and accuracy in the design process show respect towards the consumer.”

I equate this principle in the software world as don’t cut corners. Take care with what you are working on, even if you expect it to be a short term tactical solution as opposed to a long term strategic solution. Take care with your code. Try to follow the Solid Principles, Make sure your test coverage is high and pay attention to your code metrics.

• Structured Code Reviews and Code Quality Part 1

• Structured Code Reviews and Code Quality Part 2

Is environmentally friendly

“Design makes an important contribution to the preservation of the environment. It conserves resources and minimizes physical and visual pollution throughout the lifecycle of the product. “

I must admit I struggled to include a reasonable explanation for this one. In Dieters case with physical product design there are lots of choices you can make for the design to affect how environmentally friendly your product is. This can include what materials you use to construct the product down to how you package the product. This is a little harder to relate to software as  a lot of software is distributed digitally these days, although there is still a lot of boxed, and off the shelf  software still available.

One area where this may be a concern is around how we deploy software. Taking my company as an example, the Point Of Sale system is a fat client that has to be deployed onto each till in the stores.  Remember I said we have around 600 stores in the UK, with up to 4 tills per store. This could mean up to 2400 machines that the software has to be deployed onto. One of these deployments is a major exercise that requires people on site to monitor the deployments overnight. If the Point of Sale was a Rich Internet Application, then the deployment strategy would be much simpler as you only need to deploy to a central server and the tills load up the POS software through a browser.

Is as little design as possible

“Less, but better – because it concentrates on the essential aspects, and the products are not burdened with non-essentials. Back to purity, back to simplicity.”

This principle for me really is a culmination of the other principles discussed previously around less is more, clear aesthetics, honest and usable. Try not to create any barriers for your end user. Try to empathize with your users. Imagine yourself using your application every day. In my mind being more minimal always wins over cluttered and excessive features.

Conclusion

Dieters 10 principals where originally written about physical product design, but I feel they are just as relevant, with a little spin, for software developers. As a developer I think it is worth taking note of these principles, and as a development leader you should encourage your teams to follow these rules, or rules like them. There is no law that says you have to follow all these principles, but I think they make a lot of sense. Just because people long before us didn’t have the same technology as us, they all had to solve very similar design and usability problems, so it is always good to look back into the past for inspiration.