Is your Design Thinking just ‘Big Design Up Front’?

Businesses have been using Design Thinking as a design-led approach to software solution definition in recent years, and for good reason.

However, in our experience, we have seen two common problems with its use…

The first is that the need for reliable, predictable processes in businesses reduces the value and power of Design Thinking to a series of workshop post-it note exercises that lead to lacklustre products and results.

The second is that separating Design Thinking into one stage from Agile in the following stage creates an artificial handover between teams causing the knowledge, context and purpose of the problem to be lost, leading to fewer innovations, less engagement in development teams and lacklustre results in the implementation stage.

As a solution, we like to propose that businesses consider Agile Development as a prototyping method inside a Design Thinking framework that amplifies authentic customer feedback, engages your development teams and eliminates the cost and waste associated with an artificial handover.

Let’s find out more.

The nature of the challenge

Design Thinking has become the go-to methodology for prototyping and proving software ideas in real customer contexts, whilst ensuring that product solutions evolve to meet actual needs.

Design Thinking is a design approach wrapped up in a simple, consumable process to help non-designers understand how to approach product design. It has a great promise to revolutionise the use of design within businesses, supporting all areas to create better products and easy-to-use services that drive business results now and in the future.

But, as Matt Nicholson wrote in the first article on Design Thinking, this is different from what we see happening in our Industry.

Instead, time and again, we see the Design Thinking process is used as a replacement for a ‘Big Design Up Front’ phase, taking in a solution idea at the start and often ending with the delivery of a spreadsheet containing high-level feature descriptions, one sentence each, handed over to the Development team to deal with.

Why would a business choose to use Design Thinking like this?

In many cases, businesses prefer linear processes because they view them as familiar, predictable and easier to manage.

Linear processes involve a precise sequence of steps that lead to a predictable outcome, which allows for greater efficiency, cost-effectiveness, and consistent quality, making it easier for businesses to control their operations, optimise their resources, and improve their bottom line.

Humans make up any Business, and humans are typically fearful of failure and therefore adopt the view that any uncertainty is the first step on a long road to failure. They are naturally attracted to the predictable promise of a linear process.

If you need more proof of this psychological need, you only have to look at companies like McDonald’s that have built an empire on their ability to create predictable products at a global scale.

This desire for everything to be a predictable, reliable, linear process has led to the belief that software development is also linear and decomposable into predictable stages, which gave rise to the traditional Waterfall style SDLC phases of Planning, Analysis, Design, Implementation, Testing, Deployment and Maintenance.

Unfortunately, the Waterfall process has been a significant cause of poor software project delivery performance for decades (see The Standish group’s – Chaos Report).

If you view the world as a series of linear processes and squint through the lens of a need for predictability, Design Thinking can be made to fit as a replacement for the Analysis stage and bits of the Design stages.

But Design Thinking isn’t linear. Design Thinking is fundamentally a circle, a cyclic incremental design approach. It has to be pulled apart, compartmentalised, simplified and re-imagined to fit the way businesses want to think, linear, predictable and reliable.

Squeezing it into a stage of a linear process causes it to lose its ability to deliver real value. Arguably, this is precisely the trap that Agile methods have also fallen into. (You can read more here, Software Factory Fallacy). Design Thinking has been tamed from a messy, human-centric, design-led approach to a set of stage gates, post-it note exercises and in-house generated product feature lists.

Which would be fine if it worked, but it doesn’t.

The first problem with taking a linear problem-solving approach to all problems is that not all problems are solvable with a linear approach. The Cynefin framework is useful for categorising the types of problems you are solving. Cynefin is a framework developed by Dave Snowden to help make complex decisions. It identifies five domains of knowledge and tools to navigate them: Obvious, Complicated, Complex, Chaotic, and Disorder. The Obvious domain contains problems that are solvable with rules-based decision-making processes. Complicated problems require analysis from domain experts.

Complex challenges require contextualised solutions

Product Design is a Complex problem.

Complex problems are where the cause-and-effect relationship is only sometimes clear, and the problem constantly evolves and adapts to its environment. The recommended approach is a probe-sense-respond loop to explore how the problem reacts to your attempts to solve it. We don’t know how the market will react, so we try our best guess and see what it does, learning from that experiment so we can inform the next experiment. Interestingly problems can move between domains. For example, as you understand your problem’s sensitivity and how it reacts to what you do, you can learn enough to move the problem to Complicated, where there are experts you can rely on for the results you need.

To succeed in this problem domain, businesses must adopt a more exploratory approach that encourages experimentation, innovation, and adaptation requiring a shift away from rigid, linear processes towards more flexible and adaptive approaches, as Design Thinking originally intended.

Forcing Design Thinking into a linear process prevents the context-building and messy mental exploration of a problem space. Ignoring the wider context leads to obvious solutions that are narrowly focused, often missing the immediate context and wider systemic impacts such as the impact on the Climate or Economy. (See Natasha Jen).

Instead, researching, visiting and immersing yourself in your customers’ situation helps deepen your understanding of what’s required to address their real needs while appreciating their specific situation, mindset and tools available is part of what leads to those surprising leaps in innovation and is a very human thing. If you’ve ever had a lightning bolt idea in the shower, you have already experienced the power of this approach.

The second problem arises because linear processes have stages. When one stage ends, the next starts till you’ve completed all the stages. When viewing Design Thinking as a stage of Software Delivery rather than an overall process, it becomes separated from the rest of software development.

If Design Thinking is at the Ideation stage, the next stage is typically seen as Construction, building the software, typically using an iterative and incremental agile software development approach. Design Thinking has worked at a medium level of abstraction, the Why and What of a potential solution. Construction needs the ‘How’.

Construction takes as an input detailed knowledge of what the solution does at a very lower level of abstraction than design. Every button, form field, text element and screen transition needs described in a way that a computer can understand it.

By separating your project into two distinct stages, you create a gap between those that know and those that don’t. Typically different teams are assigned at each stage with a handover now required. This handover requires everything learnt so far collected together in a form that one group can pass over to a new group. It requires all the context, knowledge and learning to written, review meetings, endless questions, offline review periods, translation into Stories for the backlog, backlog reviews, traceability exercises and even more planning meetings.

As humans, we fundamentally lack the language to describe our consciousness in this way. It’s the difference between going on a summer holiday and writing a report about what you did on your summer holiday. It takes a huge talent as a writer to describe the experience adequately by writing it down, and even then, it will be a pale reflection of the real experience.

Instead of artificially separating the definition and development phases, Design Thinking and Agile should instead integrate into a single iterative and incremental process. Several studies have shown that this approach, keeping definition and development together, has numerous benefits for product development, developer engagement, project risk profile, and business results. For example, teams can ensure that they are building a product that meets the needs of end-users, reducing the risk of building something that no one wants. This approach also promotes developer engagement and reduces the risk of project failure by ensuring that the development team is always working on the most valuable features.

When put together as a cyclic continuum, Design Thinking is continually researching, discovering, defining and testing what Agile is planning, designing, deploying and reviewing. When used together effectively, there is no separation of “why” the product is needed from “how” it’s built. As a result, designers, Developers, Researchers and Business experts have a continuous responsibility to review any feedback and evolve the product throughout the entire lifecycle.

Messy human solutions need proactive support to get right

Design Thinking is iterative and incremental. It’s messy. It’s human. Embrace its nature. Please don’t force it to fit into a linear process, or you’ll lose its power to change the meaning of Design at your Organisation for the better.
Design Thinking should view agile as a prototyping method for proving your assumptions, gauging reactions and exploring customer reactions. Viewed in this way, Agile teams can be involved much earlier, start making without waiting for a list of features, and crucially are part of building a shared understanding of what the customer needs.

Embarking on a Design Thinking and Agile journey is an incredibly inspiring venture. Using these two approaches can create amazing experiences that customers will love. The combination brings the best of both worlds- agile’s validation feedback loops and design thinking’s powerful customer-focused mindset. This synthesis can help you discover an outstanding, sustainable product with a solid foundation for success. Furthermore, utilising these tools means that your Definition of a Product no longer has to be separate from its Delivery stage. Rather, Design Thinking and Agile come together as one united SDLC process customised to your company’s context and needs.

If this approach sounds appealing to you and your team, know that it is possible without excessive effort! With the correct guidance, professionals can quickly achieve exceptional outcomes with minimal fuss. So why not give it a try? If you want to combine Design Thinking with Agile in your SDLC, get in touch today!