Living, thinking and doing design
By now, we have hopefully made our case regarding why it is wize to care about design on an organizational level. So now it’ time to get down to business and talk about process. Since we stand on the shoulders of many design giants, we will set the scene by introducing Design Thinking which is at the heart of our ways of working.
Design Thinking (abbreviated DT below) has evolved over several decades. It builds on thoughts and ideas from industrial design academia and practitioners. The expression as such first appeared in a book of Peter Rowe in 1987. At the time, it was an approach to product innovation with little or no hands-on methodology support. The main idea was to humanize industrial design and change focus from an industry-centric to a human-centric design approach.
But the concepts were not new. Industrial design nestor Donald Norman published interesting work already in the late sixties, and in his bestseller ‘The design of everyday things’, first published in 1988 as ‘The Psychology of..’ he does an excellent job of arguing human-centric design.
Over the years DT has evolved with many contributors. It has proven to be a solid foundation for repeatable product- and service innovation and is now firmly established in the industry. It is included in the curriculums of Harvard, Stanford and many other business schools and technical universities. The famous d.school in Stanford offers both designer education and crash courses for managers.
The essence of DT is discovery by empathy, prototyping and iteration. As innovators, we need to make unbiased discoveries to be able to identify true and unmet needs. These needs may be latent and therefore not yet articulated. In order to test assumptions, we want to prototype as early as possible. We repeat until we think we got it. Only then do we go ahead, apply our production processes and build the thing.
DT introduced prototyping and frequent iteration as a novelty in the designer world. This also happened in the software community in parallel – one of many reasons why Design Thinking and (Agile) software development is a great match.
Another angle that DT emphasizes, and that is arguably not common practice in software engineering, is collaborative design. Many traditional projects are managed in sequence, carried out by separate (teams of) specialists, exchanging formal artefacts. In a well-managed DT-oriented design project, there are few silos. Instead, there are frequent cross-functional collaborative activities involving diverse expertise and experiences.
In many of our projects at Jayway, we have had the opportunity to bring people together that due to inter-organizational boundaries never have had the opportunity to work together. This approach has had a tremendous impact on creativity and quality, with long-lasting effects outside of the project context. Especially interesting dynamics have been created in situations with both cross-functional and cross-organizational collaborations; e.g. when our clients also have involved their customers and partners in the creative work.
The process
The process model is suspiciously simple. But while it may take a minute to learn, it takes plenty of practice to be really good at product and service design. The good news is that the learning process can be quick. There are a lot of public-domain resources, and consultancies can be utilized to kick-start and teach how to apply the methodology to your particular opportunities.
One simple and elegant description is the three-phase ‘double diamond’ model (see fig 1) by the UK Design Council.
Double Diamond model. Source: Design Council
At Jayway, we use our own clock model (see fig 2), comprising four segments each representing a disctinct groups of activities.
Together the four segments form a comprehensive and iterative design- and development process.
Understanding
This first set of activities builds the foundation for the whole endeavor. At the earliest possible stage, we need to answer some really important questions:
– Who are we designing for?
– What are their (real) problems and needs?
To answer these fundamental questions we need to develop an in-depth understanding of the problem domain and the needs and wants of the consumer of the prospective product or service. There are many useful tools, but most important is to actually spend time out there in real life, where the problems and needs are experienced. Some designers like to describe this as anthropology, and ethnographical observations of users in their “habitat”.
Some good tools can be found in traditional marketing research, e.g. structured interviews and focus groups. But the most important activities are observation and reflection. Open-ended and unbiased conversations are also invaluable sources of information. Empathy, active listening skills and an open mind are important assets during these activities.
A very interesting aspect of this part of the process is user selection, i.e. deciding who our prime users will be. This will obviously have a tremendeous impact on our design activities, and it may be worthwhile to spend some time to consider this carefully. More often than not, unmet needs are identified; which probably could not have been articulated by just by asking users what they would like next. More often than not, you will discover that the problems you should solve are very different from your initial assumptions.
The output from the discovery will typically be a a large and diverse set of meeting documentation, sketches, interview transcripts, photos, videos and maybe also special artifacts pertaining to the problem domain.
The clock model. Source; Jayway method handbook.
Identify
During the Identify phase, the findings from the field studies and other research activities are analyzed and systematized in order to identify the most important problems and needs – and thus business opportunities.
Based on their structured findings, the team formulates a problem hypothesis. The ideal outcome is a small set of alternatives for further study. This is probably the most demanding activity of them all. It’s a challenge to try and make sense of large data volumes, and it’s not a trivial task to codify and translate conversational content and behavioral observations to actionable data.
It’s important for the team not to be paralyzed by the abundance of data, or fall in love with the first hypothesis. It will be challenged many times and may have to be altered significantly – or even abandoned – as the work progresses.
Create
At this early stage, ‘Create’ is not about releasing a product or service on the market. This comes later. In this context, we focus on developing and testing the ideas – not the product. We want to come up with a number of viable ideas on how to address the discovered opportunities, and we want to verify them with our potential users.
Creative idea generation is important, and there are a number of very useful tools that can add value to the ideation. Empathy mapping, journey mapping (more on that in upcoming case descriptions) and well-managed brainstorms are examples..
Early prototyping is extremely important, and is also very cost-effective. Assumptions can be validated at a very low cost by putting our prototypes in front of- or, even better, in the hands of people representing potential consumers of the product or service. We can then quickly assess whether or not we have made reasonable assumptions, and if our main hypothesis are valid or not. If not, we re-iterate and have another go.
For services and products that are going to be realized in software, there are many good prototyping tools out there. Sometimes it may be even better to use just pen and paper and draw rough sketches. Another and very effective method is to do quick physical mockups to guide conversation. Our experience shows that crude prototypes often promote conversations even better than slick GUIs that falsely appear to be finished products with a risk of hampering creativity.
For service designs where humans will be delivering part of the service experience, scenarios and role-play are very useful tools (and are good fun to perform).
Lean startups
This iterative way of working is becoming established practice in some software-enabled industries and especially in startups. In the lean startup, the basic idea is that whatever business idea you think you have, it is wrong, It needs to change when field-tested with real users. So in the lean startup company (expression jointly coined by Steven Blank and Eric Ries) the goal is to get a minimum viable product (MVP) out the door as quickly as possible.
And this is basically also what the initial phases of Design Thinking are all about. The difference is that in a lean startup, the whole business- and product development is done in this way, while most industrial design projects use the approach initially and, then put their regular and streamlined production process to work once the problem definition has been defined and thoroughly verified.
Mats Weidmar
CEO, Jayway