By Chris Thomason: I was involved in a discussion about alternative design processes recently when, by a strange coincidence, a client asked a similar process related question of me. This discussion evolved into a focus on the purpose of the process rather than the process itself, which reminded me of an interesting story I heard when I was living in Africa.
One day a rich farmer finds one of his prize cows in a deep hole. He gets some ropes and tries to pull the cow out and fails. He then gets a lifting block and tackle and tries to lift the cow out and again fails. He then gets a tractor to drag the cow out, but this too fails. In exasperation he shouts to his herdsman to ‘Get that bloody cow out of the hole – and do it before I get back!’
An hour later, the farmer returns to see the cow grazing happily in an adjacent field. The farmer is amazed and asks the herdsman how he did it. The herdsman replies ‘You told me to get the cow out of the hole and so I did.’ And the herdsman walks off.
The point is that we should focus on the end result rather than the process. The purpose of the process is to help achieve the end result – and nothing more.
If people know how to achieve an output that meets all requisite needs, then they may not need the process. However, a process is always useful as a safety net for when people aren’t sure what to do or need some additional guidance. Additionally, processes may have intermediate milestones that need to be achieved and measured, and the process helps to identify these milestones and what the measures of success at each milestone are.
A good design process shouldn’t have too many milestones otherwise it becomes too controlling and prescriptive and doesn’t allow for the input of appropriate design flair. This asks the question of should you even have a process or should you have guidelines rather than a process?
Processes are usually well-structured with appropriate toolkits, techniques, templates and tasks assigned to each stage, which in itself can be a problem. Often a different stage of the process may also warrant the use of a tool from another stage, Most processes don’t inhibit the use of tools from other stages, but to the inexperienced user it may be a cause of consternation – If the tool isn’t shown in this stage then is it not a good thing to use?
In service design we frequently employ customer journey mapping to understand the different touchpoints external customers have – but what about employees who are the internal customers? What about your employees using processes to design and deliver new services internally? How structured and formalised do processes need to be for this activity? Certain processes involved with risk sensitive areas such as stock, finance and data need a rigorous system to ensure control. However, in design related aspects of our work, just because we have a process, does that mean we will do better design?
As I said earlier, what if we had guidelines – or even just a set of tools – and instead we aimed to change people’s attitude to design? What if we could allow non-designers to feel they were displaying designer-like behaviour in their work output. And what if we allowed accomplished designers freedom to design in the way that allowed them to best deliver what they are capable of? This is less about process design and more about cultural and organisational change.
As I said at the start of this post, should our conversations be on the process or on the purpose of the process? Our should design be up to the individiual and their skill level and personal preferences? After all, as long as you get the cow safely out of the hole, does it really matter how it was done?