Design Thinking - Deliver
   4 min read    Bharath Sabesan

Delivery is the outcome phase of the Design Thinking methodology. This culminates with the tangible solution that is harnessed and refined based on the previous phases of discovery and design.

Firstly, it’s not new

Delivery is not a new terminology or concept that Design Thinking has coined. It has always been existence and practice across industries and domains. If delivery is a conventional methodology why does a contemporary approach refer to it or continue to refer to it? The answer is simple, Design Thinking approach doesn’t aim at introducing new ways of working rather it aims at reimagining and recalibrating the existing models to best fit business and solve user problems.


Is there only one way?

Delivery models are a separate subject of study in both product and software development and over the years there are quite many models in practice across industries. Focussing on software development lifecycle (SDLC) models some of the popularly used ones are Waterfall, V-model, Rapid Application Development (RAD), Spiral, Iterative, etc. Each of them has their own weights of pros and cons making them widely practiced models. To clarify again, Design Thinking doesn’t dictate the model of delivery rather provides the insights and cognizance to make your delivery model targeted and effective. But one thing that differentiates these models is its philosophical fitment with the Design Thinking approach and the ability to implement it. This is a topic of its own and I can cover them as a separate blog. But on a high level the following points often contradict with traditional models which have led to the evolution of Agile and DevOps kinds of models.

  • Lack of user research information
  • Ability to identify design gaps early in the lifecycle
  • Linear flow making it difficult to iterate with ease
  • Lateness of user involvement



Fail Fast and Learn Fast

Software Development comes with consumption of time, people and cost to get to the solution. The longer it takes to realise the misalignment of an idea the more resources are consumed. Traditional SDLC models often fit into this framework of leaving it too late for efficiency. On the other hand, if solutions are verified and tested earlier in the chain, higher the opportunity to minimise resources and course correct, as required. Agile development models provide this opportunity to validate your ideas and design on the aspects of usefulness, viability and feasibility. Validating earlier allows you to continue working on your solution if there is alignment, pivot in the event of gaps or stop if there is complete misalignment. Failing fast requires a culture where the team has the freedom to fail but can learn something from each failure that helps the team succeed faster the next time. This idea is at the heart of Enterprise Design Thinking. In the words of David Kelley, “Enlightened trial and error beats the panning of the lone genius.”

How to enable this?

  • The first step in failing fast goes back to the first blog of this series where you need to achieve user desirability and prove that you are solving the problem that your users are facing
  • During the definition phase, attempt to define the MVP before adding on features to your ask. Explore crazy ideas and try to map them to MVPs to separate the good ideas from the others
  • In a hypothesis-driven development process, the entire team—design, development, and business—identifies the riskiest assumptions that underpin an idea. Then, the team builds experiments to test them. If the idea is based on flawed assumptions, it fails, and the team can pivot and avoid wasting its limited resources. When the team tests the riskiest parts of the project at the beginning, the cost, risk, and design of the project become more predictable
  • Another key fulcrum point is Technology. Often, projects tend to develop brilliant solutions and discover the inability to keep them working in the environment only during the deployment phase. In solutions that have dependencies on infrastructure and environment, validate how the platform and devices affect your design. Implement as little of your infrastructure as possible to validate an assumption and then implement a bit more to validate the next assumption
  • From an application-delivery point of view, development teams that use DevOps can get immediate feedback to find out whether code or a deployment is flawed. In this way, a team can move to higher-quality code and a more stable deployment environment.

Is that it?

Yes, delivery phase which can often be thought as the devilish of the three is not ought to be. If you have got the first two phases in good shape your delivery phase will be a cakewalk. It doesn’t mean that you will get it right first time, but you wouldn’t have a disaster at the end rather fail early and sprint faster to achieve the goal.

As we end this initial series on Design Thinking phases, I am pondering on my next blog!!

Please reach out to me if you would like to have a conversation around this. Also if you have topics that you want me to research and blog, please do feedback them.