Categories
Design Thinking

It’s never too late to go back to the beginning

No matter how far down the track you are in a software project, you can zoom out and course correct.

A question came up last week and it was a good example for how Design Thinking can help course correct at any stage of a project. Ideally it’s an end to end process, and often it doesn’t happen in true linear fashion – you hear about a project that’s well underway before you are brought in to help.

Without getting into too much detail, a development project is underway that has found lots of roadblocks, both internal, external and technological, and the question is, “how do we fix this?” Design Thinking to the rescue, of course! It’s not outrageous to say, let’s zoom out a little bit so we can figure this out.

Design Thinking can happen at any stage of a project

(Even though it’s best to employ it from the start.)

A project can have these stages:

  1. Initiation
  2. Planning
  3. Execution
  4. Monitoring and controlling
  5. Closure

The important thing to remember is these stages are a cycle. Designers call it the “Double Diamond“. You can go straight through them and you can also go back and forth depending on the need. You can cycle through them several times before a project is complete. Some PMs might balk at this, but I think it’s not only Agile but smart to be open to change midstream if it means solving blocker problems.

My suggestion is to use DT

My suggestion to “how do we fix this” is to go back to the Planning (Discovery) phase and run a workshop to determine all the issues, the efforts undertaken so far, and then come up with a next step. Chances are, the wider team will have ideas that can help. Thanks to DT we can capture and document these and then, hopefully, move forward.

DT can help a team understand these things:

  1. The problem (the most important bit!)
  2. The blockers stopping the development effort
  3. The solutions attempted (and additional solutions possible)
  4. The solution: refine the above steps to piece together a new user journey (and technical implementations!) that will smooth out the experience

Document the above for DX (Developer Experience) so whenever a technical process question comes up, these steps can be used instead of trying to find your way in the dark.

As the team builds up these discussions (Miro is a great way to store them) they can refer back to them and start to work in this way from the beginning. DT isn’t just for design teams, it can be used by everyone to collaborate, learn, and be successful.

By Nathaniel Flick

Hi I'm Nathaniel, a Software Designer - a designer who codes. I create innovative, user-focused digital experiences, blending Design Thinking with practical development and accessibility.

Leave a Reply

Your email address will not be published. Required fields are marked *