What is design? As an engineer, I have some tacit knowledge of design – but I have always struggled to explain what it really means.
When I started my career, I spent most of my days dealing with the vagaries of moving water and earth, applying different designs that attempted to bend these elements to my will. I quickly learned what every engineer knows: that there is no such thing as the “perfect” design. There are often thousands of potentially optimal solutions, all of which make different trade-offs and emphasize different things. Sometimes, the trade-offs are a matter of “taste” or aesthetics. Some are about simplicity. Some about speed. Some about economics. Some are about safety. There can be thousands of different parameters to consider, all of which can have an impact on each other.
The easiest design choices are when there are fewer degrees of freedom to explore. When the constraints are tight, many potential solutions exist outside of the design envelope, and can be quickly discarded. When the constraints are minimal, there are more decisions that need to be made, all of which remain up in the air while possible combinations and permutations are weighed up. Occasionally, some of the constraints themselves can be moved – but usually only by taking some other parameter beyond what is normal. New patterns are constantly being created and existing patterns are being refined.
Part of what makes software so complex (and what attracted me to it) is that the degrees of freedom are huge. Water and earth, and the materials we use to control them have to comply with the laws of physics (notwithstanding the weirdness of fluid mechanics). Software is much more malleable and has greater flexibility and the hardware it runs on is getting smaller and faster, providing a greater design envelope to play with. The risks involved are also different. When a dam, or bridge fails, lives are at stake. When twitter falls over (as happened last week) it’s a bit frustrating, but generally not life threatening.
All of this makes developing products where software is a primary component a very interesting design problem. In this context, John R. Moran makes the argument that design is about intent – that creative decisions are made based on an answer to the question “How should it be?”. He goes on to argue that organisations avoid this question in three main ways:
- Preserving – this is when we simply don’t bother asking in the first place, simply keeping what already seems to work without really questioning whether it could be better. This is perhaps the number one reason why incumbents tend to lose when it comes to disruptive innovation.
- Copying – this would be the fast follower strategy. Avoid the question of how it should be by simply copying whatever has worked elsewhere. Saves the time and effort required to design from scratch and making lots of difficult decisions.
Delegating – this is when we abdicate responsibility for answering the question by some means of outsourcing the difficult design choices. Moran offers three different flavours of delegation to choose from:
- Offering a wide range of choices: e.g. Samsung with it’s huge available “selection” of smartphones. In this respect it is Nokia’s business model that Samsung have copied here.
- Trying to offer an omni-functional product: e.g. Microsoft, serial offenders in this area. This perhaps is a manifestation of “Preserving” above, whilst still attempting to embrace innovations that have proven valuable. This strategy works better with desktop software than it does with an integrated hardware/software product where screen real estate is limited.
- Deciding based on user-testing: e.g. Google, Facebook, and Amazon are the examples Moran provides, but he could pretty much have chosen any Web 2.0 company.
We could argue that when we choose to delegate we may offer a reduced number of choices — perhaps we have already made the decisions that matter to the designer. Google decided the links would be blue, but left the decision as to which shade of blue to user-testing. The advantage of this is that we avoid the arrogance (real or perceived) of a designer “knowing best”. At other times, it can signal a lack of care and consideration. There is no question that delegating design can work in many situations, but we shouldn’t confuse discovery with design.
Design is hard. It takes time and effort to understand the intent and then consider all of the trade-offs before making a decision and criticising the end-result based on your understanding of the intent. It can be even more painful to do this when you are collaborating with others. When done well, the result can be delightful, conveying the care and thoughtfulness that went into the product.
Steve Jobs perhaps said it best, in one of my favourite quotes of his:
“As you evolve that great idea, it changes and grows. It never comes out like it starts because you learn a lot more as you get into the subtleties of it. You also find tremendous trade-offs that you have to make. There are certain things you cannot make electrons do, or plastic or glass or even factories or robots. Designing a product is keeping 5,000 things in your brain – fitting them all together in new and different ways to get what you want. Every day you discover something new that is a new problem or a new opportunity to fit these things together.”