Since Design Thinking is a methodology growing in popularity and being taught at leading universities around the world, I thought it would be a worthwhile topic to explore. Just what is this design thinking and how does it compare to other mythologies, such as Agile?
To begin, Design Thinking is linear, or sequential in nature and comprised of five distinct “stages”, starting with Experimentation and ending with a result that you are (hopefully) “satisfied” with. Further, Design Thinking is often defined as: “creative, logical thought applied or performed in each of its 5 stages”.
In the drawing below, I’ve sketched out each of the stages (Experimentation, Prototyping, Test/Present, Gathering Feedback and Redesigning) that make up design thinking into a “workflow” of sorts:
Iteration to Satisfaction
Typically, being “completely satisfied” with a result is not obtained after performing a single iteration of the design thinking process and the entire process can be (and usually is) repeated until a desired result is obtained. In fact, the number of iterations performed may vary based upon a variety of factors, as the below image illustrates:
Design Thinking or Agile Thinking
Based upon the above, (and if you have some experience with Agile) you might rationalize that the description of Design Thinking appears to be very similar to that of the Agile methodology of software or solution development. In fact, the Agile “workflow” includes stages that make up a very similar workflow: Requirements, Development, Testing, Delivery and Feedback, as shown here:
So, it would seem that perhaps at the highest level, the five stages of both methodologies align (at least to some degree), but if we take the time to survey each of the stages, there are some important differences.
1. Experimentation versus Requirements
In this stage we are trying to understand and describe what the problem is (we know the problem at hand) or, in the case of design thinking what “opportunity” there might be (what is the problem at hand we should be focusing on?).
2. Prototyping versus Design
Here, in this stage, the goal is to “cobble together” what some would refer to as a “working strawman” (sometimes called a “proof of concept” or POC) that meets just the minimal level of requirements defined or uncovered in the first stage. With Design Thinking, the goal or objective is to create a clear and concise problem statement, not a working model.
3. Test/Present versus Testing
In Design Thinking, this stage focuses on presenting what was “defined” or “put together” as a problem statement in the prior stage, with the agile workflow, the goal of this stage is to ensure that the POC that was built (in the previous stage) “works” correctly as designed based upon the understood requirements.
4. Gather Feedback versus Delivery
In this stage of Design Thinking, the reactions and responses from presenting a problem statement developed in the previous stage are recorded. In an Agile iteration, this stage is used to (assuming a successful prior testing stage) actually deploy the POC for use (or “productionize” it).
5. Redesign versus Feedback
Finally, in this stage, with both Design Thinking and Agile methodologies, all of the responses and feedback that have been recorded during the iteration are “digested” as lessons are learned from users’ experience with the work to date and when a sound understanding is reached, the POC or problem statement is redesigned or modified in order to address each of the responses collected during the prior stage.
Methodology Differences
While it is somewhat true that these two methodologies (workflows) could be considered to be fairly similar in nature, there is a critical difference. That is, whereas the agile process is an approach to problem solving, the design thinking is an approach to problem finding:
To “paint” a clearer picture, and to acquire an improved understanding of this difference, you can now take a closer look at the key first stage of each of these process workflows and note the differences seen.
Agile
Let’s starting with looking at the Agile methodology.
The requirements stage of this workflow is to define, understand and document the requirements for (the iteration) based on a product backlog, sprint backlog, customer and stakeholder feedback. In other words, the requirements define the purpose or reason for performing the iteration. If it is not the first iteration, the requirements will focus on enhancing the previously created prototype by making improvements to how it works or even adding new features or functionalities.
The “requirements” defined should be “what is required” (the necessities) to be delivered (after completion) of the iteration in order to be considered successful.
Most individuals involved in software development in some way will realize that requirements gathering is absolutely vital in the software development life cycle. Misunderstood, incorrect or missing functionalities will result in wasted time and money and potentially failure of the project.
Typically, requirements gathering centers around solving a specific problem or meeting a direct known need. Typically (or strongly suggested) requirements should be captured in a feature-oriented, value-oriented way, rather than a solution-oriented way. In other words, solve the “what” not the “how”.
As an example, suppose the requirement is to provide daily sales activity reporting to a department manager. In this use case, the requirements would include specifics around what information is needed and timing of that information so as to keep it current and correct but would not dictate or call out such details like database table names (where the actual information is stored).
These requirements are usually gathered though user interviews and the development of artifacts such as storyboards, wireframes and simple “static” prototypes (perhaps a “mocked up” report in MS Excel) and are often documented as “stories”.
Note: Many interesting tools such as JIRA are popular options for this purpose (www.atlassian.com/software/jira/agile).
The “take away” from the above is that there is a “problem” defined: i.e. “…department managers require daily sales information…” and the objective is to define the specifics of what that actually means.
This requirement definition is used to create a problem statement (a concise description of the issue or need to be addressed or the condition to be improved upon). The output or deliverable of this stage of the workflow is then used by the project team to comprehend the problem and work toward developing a solution.
Design Thinking
Now let’s switch (from thinking about the Agile methodology) to the Design Thinking methodology; here, the first stage (the experimental stage) begins with the exercise of empathizing with a situation or scenario (rather than a problem).
This idea of making the effort to relate - or to empathize – with a person or group of people and their behaviors and motivations is critical to the design thinking workflow. The empathizing process has proved to be important because people often don’t know, or are just unable to articulate, these things explicitly, so the understanding develops through observing users and their activities in context to identify patterns, ask questions, and challenge assumptions, rather than just relying on the spoken word.
This approach is used in the Design Thinking workflow in an effort to identify the right problems to focus on and (hopefully) solve. Design Thinking approaches a scenario from a human perspective, with the objective of designing an innovative and desirable solution, service or experience that reflect all desirable aspects, rather than just focusing on the mechanics or “math” to solve a stated problem or equation.
Conclusion
Design thinking, executed effectively, supports the design of a better product, service, process, strategy, architecture, and experience, since whatever the outcome, it should meet the users’ needs and preferences, rather than simply executing on a design or plan created in a laboratory by scientists (or team of software developers). In addition, design thinking, perhaps coupled with Agile, can help us develop and evolve practical and innovative solutions to today’s business problems.
When implementing a planning, analysis or reporting solution it is worth incorporating ideas from both Design Thinking and Agile methodologies, depending on the problem at hand. While QueBIT’s CARE methodology is founded on Agile principles and has helped deliver success on hundreds of client projects, Design Thinking has growing relevance as companies begin to think in terms of digital transformation for internal operations, which means considering people and processes as equal partners to technology in driving business value.
