Continuous Design Thinking
Our process for staying human-centered, no matter what!
One of the best things about creating tools at SAP Labs is that we’re free to use the technology, process, or methodology we think will best support our customers’ and users’ success. Obviously, we’re part of a very large enterprise so we have to justify our choices, but this freedom allows us to constantly challenge our own thinking and bring fresh ideas into the company.
One of the ideas we’ve developed and continue to refine is our Continuous Design Thinking process. The process is a synthesis of Design Thinking, Lean Startup, Lean UX, and Agile techniques. We coined the term Continuous Design Thinking because SAP practices Design Thinking extensively, and we want to leverage and extend that institutional knowledge. We’re also fans of continuous integration, continuous release, etc., and we want to engender that spirit.
Why (the heck) create a new process?
Great question. And this isn’t so much a new process, as a blend of existing, proven methodologies. We need a flexible process that works well for the whole product team: engineering, product, and design. We also need a process that supports our ultimate goal: creating tools, products, services, and experiences that support our users’ and customers’ success. No user or customer ever cares which process is followed.
So, where to begin? We like Agile principles a lot, but rigid adherence to engineering sprints can result in a feature treadmill that loses touch with user and customer problems. Lean methods can be extremely effective, but as Tomer Sharon notes, in practice it’s easy to iterate around an idea that has failed to understand the underlying problem that your target users or customers are trying to address. Iterating inside an echo chamber is not the intent of Lean Startup or Lean UX methods, but in reality it can happen.
Design Thinking should address the “understand the problem” part of the equation. However, in practice the great work happening in Design Thinking workshops here isn’t always connected to the ongoing development work to support products and services.
So, we like a lot about existing methodologies, but we’re making adjustments we find beneficial in our practice here. We’ve looked for those times where it’s easy for teams (including us) to lose sight of users or customers, and made changes to help sharpen our focus. We’ll continue to iterate and refine as we scale our efforts.
What does it look like?
Though we use many different methods and techniques depending on the context, we like to communicate the process simply. We use a slightly modified version of the UK Design Council’s double diamond model. The process is made up of four phases that we run in cycles continuously: Investigate, Interpret, Iterate, and Implement. The phases and activities will likely be familiar to anyone designing and developing software. There’s no set duration for the phases. You might need a couple of hours or several months to complete a cycle. It depends on the complexity of the problem.
What we particularly like about the way the UK Design Council has visualized its human-centered design process, is the equal weight given to both diamonds. In our experience, it helps to emphasize the importance of understanding a problem (from the perspective of users, customers, stakeholders, etc.). The truth is, in software development reality, it’s all too easy to prioritize building features over understanding human problems, so we need a framework that shifts our mindset and behavior.
Investigate & Interpret
The purpose of the first diamond is to understand a problem well enough that we can prepare to explore potential solutions. Before we start building, we want to be confident that we’re targeting a problem whose solution will provide meaningful value for our users, customers, and stakeholders.
The diamond begins with Investigate. Its purpose is to gather data. We are not our users or customers, so it’s essential to get out of our own echo chamber. It’s important to be focused, but also to investigate with an open mind.
Data gathering covers a very large range of possible activities — we aim for the most efficient yet effective method to gather the input we need. Depending on the situation or who’s investigating, we may use methods from Lean Startup, Lean UX, Design Thinking, or formal user research. The Nielsen Norman Group provides an excellent overview of different UX research methods and when to use them.
If we’re simply doing some digging to understand why a feature request keeps coming up, a few short phone interviews may suffice. We’re fans of Bruce McCarthy’s approach to keeping the focus on users and customers within the backlog. The most important point is to have an attitude of wanting to investigate and understand users’ and customers’ needs.
Once we’ve gathered data, it’s time to interpret it. If we’ve been investigating the need for a new tool, it’ll take time — perhaps several weeks — to synthesize all the inputs. If we need to understand the why behind a feature request for an existing tool, analyzing the data we gather may only take minutes. The purpose of the Interpret step is to analyze our data, narrow down our options, and bring our problem into focus. We need to be able to define the problem clearly enough that we can negotiate agreement to proceed and can begin working collectively on potential solutions. Depending on the scale and complexity, negotiating agreement might be a five-minute chat between a couple of team members or a lengthy approval process with stakeholders. It all depends.
We use a variety of methods to help us interpret. We document the key insights, themes, and priorities that we’ve observed or learned in our research. We may create personas or user descriptions to help us understand who we’re going to be designing for. We’ve used journey mapping as a technique to help us understand the bigger picture and identify opportunities to improve the customer or user experience. Journey maps can be helpful tools to communicate needs with stakeholders and agree areas of focus. We often use sketching or rapid prototyping — not to prematurely fix on a solution, but to verify and clarify among ourselves and with users, customers, or stakeholders that we’re understanding the problem correctly.
Once we can clearly articulate the problem and are all in agreement about exactly what we’re focusing on (and not focusing on), we can start exploring potential solutions.
Iterate & Implement
For us, the goal of the second diamond is to release working software that solves the problem identified by the first diamond. Since the process applies equally to a single feature as it does a whole tool or product, sometimes this can be relatively straightforward. However, if the goal is an MVP or a major release, this will involve several iterations and significant effort in implementation.
The second diamond begins with Iterate. Its purpose is to explore a variety of potential solutions and get iterative feedback (from potential or actual users) before committing to full implementation. This can be run in the style of a one-week design sprint where feasible. We typically start sketching, move to paper prototyping, then interactive prototyping of the strongest solutions. Everyone’s involved, this isn’t only a step for the design team. Many of our best “design” ideas come from the Engineering team. It’s also absolutely critical to get out of our own echo chamber and get feedback from potential users.
If our work during the first diamond has been thorough, we should be iterating around a clear problem and need, and our potential solutions should be resonating. Assuming all is well, we move on.
The final step (before repeating the process) is Implement. We agree upon the most effective solution to build, and begin development in earnest. To be clear, this isn’t when engineering begins. In reality, we’ve all been working side-by-side throughout, and much engineering preparation will already be completed. Implement is the phase where the bulk of front-end development and detailed design occurs.
How does this work continuously?
The key is to actively cultivate an attitude of prioritizing making users and customers successful. This process framework helps shift our mindset and day-to-day practice away from being so feature-driven. This is a work in progress for us. We’d love to hear from other teams who are facing similar challenges!
Thanks to Alex M. Wu for the illustrations, and Leslie MacKay for editing. Thanks to Kursat Ozenc, Ben Boeser, Michael Spindler, Dominik Tornow, David Farr, and the whole global Tools team for their contributions and collaboration.
