Does Design Thinking Deliver?
INTRODUCTION TO SYSTEMS DESIGN THINKING
The goal of business is pretty simple, right? Provide a product or service that people want so you can make money and stay in business.. For years companies have turned to various tools and methods to crank out new and exciting solutions. One of which has become highly trusted - design thinking. Design thinking has a pretty impressive track record, no one is denying that. However, as products and services gain in complexity seemingly by the minute, design thinking is showing vulnerability in its ability to generate holistic and scalable solutions. Enter Systems Design Thinking. It’s the evolution of design thinking to include systems engineering methods to ensure new ideas consider all perspectives involved and that the idea can successfully scale. Systems design thinking is your new superpower.
In our experience, “traditional” design thinking can fall apart when it’s time to transition the project from its fast-paced, high-energy phase into the devil’s-in-the-details phase of engineering and development. This can leave great ideas gathering dust on the shelf. Initiatives such as Design Thinking 2.0 acknowledge design thinking projects can struggle to scale and suggest introducing systems thinking / design as a replacement to design thinking. We agree in adding systems-focused methods, but not entirely scrapping design thinking.
As already stated, Systems Design Thinking is the evolution of design thinking. It takes the best of design thinking - the rapid generation and testing of innovative ideas - and merges it seamlessly with the holistic perspectives, methods and best practices of systems engineering. In other words, systems design thinking provides a framework to identify innovative ideas, understand their relationship to the various systems they must interact with and then define them clearly and concisely. This lets new ideas stand a chance of surviving the different team-to-team handoffs and transitions which occur from idea to prototype to final solution.
Before we go further, why should you listen to us, who are we? Foremost we’re systems design thinking experts. We not only learned from the method’s creator herself, Sirietta Simoncini, while at Cornell University, we also had the opportunity to help her develop an online version of her curriculum and were the first instructors to teach it. We’ve deployed systems design thinking on all kinds of projects (a girls’ school in Ghana, a consumer product, a new business plan and product, organizational design, etc.). Secondly, we’re systems engineers. We help our clients detangle the complexity of their own products. We’ve also worked with NASA on two different projects developing tools to improve the practice of systems engineering. Lastly, we’re product engineers. We’ve been in product development for 30+ years combined. We know, firsthand, the nuanced challenges associated with developing complex products and the pitfalls that occur during transitioning a project from concept to reality. And we’re NOT process geeks; we only use something if it works.
Figure 1 - The Systems Design Thinking Method
Ok, back to the topic at hand. Reviewing Figure 1 you’ll notice commonality with design thinking. Systems design thinking also adds a Challenge definition phase and we at Aureus are introducing a seventh phase called “Implement.” As the graphic suggests, ideally it’s a relatively linear flow through the method. In reality, however, there is much jumping around and across phases because that’s just how the real world works. Iteration is allowed and encouraged throughout the method so the best ideas with the highest chances of success emerge. Here’s a short summary of each phase:
Challenge - frame the scope of your project that is simultaneously ambitious yet tenable.
Empathize - observe, emulate and engage with actual folks that are potential customers of the yet-to-be-determined solution to understand the challenge from their perspectives.
Define - unpack all the empathy sessions to learn what drives your customers’ wants and needs. Determine what your solution needs to DO without jumping to what your solution IS.
Ideate - identify solutions that you are confident will solve someone’s challenge by meeting their wants and needs. Also, choose the solution(s) that balances the scale of desirability and feasibility.
Prototype - build something that allows you to get feedback as quickly as possible. The value of a prototype is in testing your idea, not building the perfect representation of a final solution. Prototypes increase in complexity and completeness over time based on testing feedback.
Test - determine what’s working and what’s not with your prototype. Use this constructive feedback to refine and iterate your knowledge of the challenge so you can progress through the prototype cycle.
Implement - retain the knowledge regarding your solution so it may be communicated in a manner that allows the prototype to transition into full-fledged engineering design and development. If the project up to this point is poorly documented much will be lost in translation and your baby may grow up to be unrecognizable. No one wants that.
You may be thinking - ok, this sounds a lot like design thinking with a couple of extra steps. Remember, systems design thinking takes what works from design thinking and makes it work better by infusing systems engineering throughout the phases. Systems design thinking can generate innovative products and services that also account for all the complexity required of today’s solutions. It is also valuable for the detailed phases of development, not just the conceptual. Systems design thinking can turbocharge your entire development process.
CHALLENGE DEFINITION
Have you ever been part of a project that had high ambitions but struggled to make progress or contributions that really impressed? Most of us likely have. The project typically starts with a lot of energy and excitement. Team members are busy working but when it comes time to review significant progress, leadership is underwhelmed. The team is demoralized and life is sucked from the project. Sad times. Why does this happen? Why do some projects spin in circles while others strike proverbial gold?
There are many reasons but one we want to focus on is how well the project team understands what they’re attempting to do and why they’re doing it. This may sound unnecessary at first glance. Of course your teams know what they have to do, right? They may understand what specific work products they must do with respect to their role but do they know WHY they are designing and launching that new product or service? Do they have a clear understanding of the challenge they’re solving and to whom it’s important? We all know how to do our job, but sometimes we don’t know the bigger reason as to why we’re doing them.
Why is challenge definition so important? A clear challenge statement will ensure your team stays focused on the bigger issue they’re attempting to address. It helps them see how their individual efforts aggregate into something bigger than the sum of their efforts. It keeps your team from chasing its own tail - working really hard with very little to show. It’s the same idea as planning a trip - you have to know where you’re going before you can choose the roads on which to drive. Else you’ll just drive around until you run out of gas - just like the team with no clearly defined challenge.
What’s a good challenge statement look like? There’s no set formula but it should be important to someone, ambitious yet tenable and not suggest a solution. Some challenge statements attempt to tackle too much, resulting in diluted efforts and little progress. Some are too focused and prescriptive, stifling innovation. A good challenge statement unites the team and inspires them to solve a worthy problem. Here are a few examples:
Reimagine the family experience (from one of Sirietta’s classes).
Create a model for sustainability in education (also from one of Sirietta’s classes).
Redesign the product development culture in order to encourage the practice of holistic thinking across the organization (from an organizational study I led).
Define a profitable business that enables work-family balance and freedom of mobility (Aureus Innovation’s challenge statement).
All these challenge statements are ambitious and define a big picture for potential solutions. They also do not suggest solutions. The third one, “Redesign the product development culture…” adds a refinement “...to encourage the practice of holistic thinking…” This is to reduce the scope for the specific project. Again, there’s no perfect recipe and a good challenge statement will likely go through several iterations until you land on the final. The iterative process itself helps you to see the problem from different perspectives.
It’s worth pointing out that the challenge statement is different from the “how might we” statement you may be familiar with from design thinking. The how might we statement will also be developed in systems design thinking, but not until the Define phase of the method. The challenge statement sets the tone for the project - you know there’s a problem worth solving and generally where to dig for clues, but you’re not ready or able to nail down what you specifically aim to deliver. Later, the how might we statement either refines your initial challenge statement or possibly replaces it. It all depends on what you discover during the Empathize & Define phases.
So how does one arrive at an inspirational challenge statement? A great challenge statement is ambitious yet simultaneously tenable. It energizes the team without suggesting any solutions. There are tools to help you think through your challenge and get it defined as clearly and concisely as possible. Here are a few:
Disagio - an Italian word loosely translated as “discomfort.” In the States we may call it a “pain point.” The gist is that it points to something problematic enough for someone to want to do something. It’s more than just a trivial annoyance.
Inspirations - personal experience, anecdotes from friends, family or co-workers, published material; anything that has given you reason to believe that your disagio can be the foundation of a worthy challenge.
Stakeholder Map - this helps you identify all the key players in your challenge, such as decision makers, gatekeepers, etc, and how they’re potentially related to one other. These are not personas that you create later in the method, although your stakeholders could inform aspects of an eventual persona. It’s helpful to identify what items of VALUE the individual stakeholders provide to the project. You may not be super clear on what value the project delivers to the stakeholders at this stage, but you will during the Define phase. At this point, however, the stakeholders should resonate with your disagio and inspirations. The stakeholder map is also used to identify the chain of command and its influence on things needed by the project, such as resources.
User Groups & Fields of Action - the groups of people you intend to empathize with, organized demographically, geographically, etc. Your Fields of Action won’t be used until you begin empathy sessions, but considering the folks you want to engage with at this stage can get you thinking about their perspectives and their challenges.
There are undoubtedly additional tools to help clarify your challenge and its scope. In using these tools, remember that their purpose at this stage in the project is to develop a CLEAR & CONCISE challenge statement. One which your team can rally around, allowing you to set a unified direction for the project from the outset. Also remember that this initial understanding of the challenge can change as you progress through the systems design thinking method. Keep your team and your stakeholders updated on any changes - you don’t want to leave any key players in the dark.
SOFTWARE TOOLS
How about software tools? What should you use to facilitate your project? Why should we even discuss software tools at this time? A couple of reasons:
Seeing is believing. In this type of work the method sometimes doesn’t click until you see it in action.
Tools can help or hinder your ability to move efficiently through the method and generate effective outputs. This will become more and more evident as you progress through systems design thinking. Remember from earlier, a goal of systems design thinking is to improve your innovation’s ability to be implemented at scale. Effective and usable documentation is a HUGE part of this - ask any engineer. If you start out with effective documentation in mind from the start, you already have an advantage.
What software do we recommend? This is tough, honestly, because what’s currently available falls short in one regard or another. The design thinking side of systems design thinking needs speed and freedom of expression. A tool must allow the team to move quickly and intuitively. That’s why teams often resort to what they know and are familiar with (whiteboard sketches & post-it notes eventually translated to PowerPoint). The systems engineering side of systems design thinking needs accuracy and trustability. A tool must allow engineers to understand what’s going on with no ambiguity. This implies something more formal and structured than PowerPoint, but it comes at the expense of speed and intuitive use.
What tool to choose then? We suggest, and will show, two tools:
Web-based Collaboration “Whiteboard” Tool - if you’re conducting your project 100% in person then whiteboards and post-it notes can fit the bill, but we’re guessing there’s at least one team member located remotely. Even if not, there are a lot of advantages to using a web-based whiteboard, such as multi-person authoring, autosave, easy organization, etc. These tools allow you to move very quickly and allow a very large degree of freedom. We won’t promote a specific one, however, we suggest that your web-based whiteboard has the ability to export its contents as a .csv file. Check out the export functionality. Some web-based whiteboards export a very generic .csv, which isn’t very useful when you start generating more content. Make sure the .csv export has all the elements of your board (or a purposefully selected subset) with ample data for each element (unique ID, name, element type, relationship start / end, text / description, etc.). Another nice feature is the ability to add tags to your whiteboard data. The need for tags will become apparent later on in the method when you’re dealing with bigger sets of data.
“Modeling” Tool - a whiteboard tool is what we call a “drawing” tool. It lets you do pretty much whatever you want, it is very free form. A modeling tool, on the other hand, has a formal structure to the elements you use. There is meaning to the elements you choose and how you relate them. A modeling tool massively reduces the ambiguity of what you’re capturing by structuring it in a certain and consistent way. Systems Engineers are typically familiar with modeling tools that use SysML (Systems Modeling Language). SysML-based models are increasingly used to orchestrate the upfront work involved with defining a technology or the program to implement it. For this reason, we will suggest and demonstrate a SysML-based model, again not promoting any specific vendor’s application. There is a mixed reaction to SysML. We are very familiar with this topic and one of our NASA-sponsored projects studied this challenge. It’s well beyond this introduction to systems design thinking, but if you’re interested, reach out and we’re happy to discuss what we’ve found.
Let’s now see the method and these tools in action! For demonstration purposes, we’re only showing the Stakeholder Map within the Challenge definition phase. Most of the other outputs of this phase are simple text boxes.
As you’d expect, it’s pretty fast and easy to use the whiteboard tool (Figure 2). There is nearly complete freedom in how you create. Normal functions (copy, paste, etc.) are as expected. If you’re comfortable creating PowerPoint slides then you’ll have no issues picking up a whiteboard tool quickly.
Figure 2 - Whiteboard Tool in Use
The modeling template is a bit more involved to use (Figure 3). Since each element on the diagram is its own unique item, you can’t just copy and paste. However, it’s still pretty straightforward, especially if you’re familiar with SysML concepts. The benefits of the modeling tool will become more and more apparent as the project progresses. For now, both the whiteboard and modeling tools seem to offer similar value.
Figure 3 - Modeling Tool in Use
These two tools give you options for capturing your project information. It’s pretty simple at this stage and nearly any software could work. However, we suggest you keep in mind the criteria discussed above, especially regarding collaborative whiteboard tools - they’re not all created equal. Later, as you generate a LOT of data, tools you may be tempted to use (PowerPoint, keynote, google slides, Excel, etc.) will let you down and you’ll have to do a lot of rework to make your info useful. Likewise, as your understanding of the challenge becomes more clear through the Define, Ideate, Prototype and Test phases, the whiteboard tools will start to let you down. You will want to understand how a change in your prototype traces back to insights discovered during the Define phase. That will be a manual / memory process in the whiteboard tool. This is where the modeling tool really starts to show its value. Traceability reports are a breeze for the model. Also, in the Implement phase, a model is almost mandatory, especially with today’s highly complex products and services.
If you can, at this stage, we suggest using both. Conduct your team sessions in the whiteboard tool so that you can move quickly and not worry about formalities. During off time, replicate your newly defined information in the modeling tool, even if you don’t use it for a while. Think of it as giving your future self an advantage. This approach has the advantages of both the rapid drawing tool and the more formal modeling tool.
That’s it for the Introduction and Challenge definition phase in Systems Design Thinking! Next time we’ll move on to Empathize, which is really the core of the method, as it is in design thinking.
If you’re itching to get going on your own project and can’t wait for our next blog, please reach out! We’re happy to help you get going as quickly as possible.