How A Design Sprint Could Help Your Health Care Application

Over the last few months, we’ve added Design Sprints to our toolbox; working through exercises to help us define problems, goals, and solutions. A design sprint can be used in any project but I’d like to specifically talk about how it can help with a legacy health care application.

What is a Design Sprint?

Carried out in five stages (whether those are five days or not is up to the group involved) the design sprint allows all the stakeholders to work together to:

1. Discover and agree on the problem to solve.
2. Diverge to determine solutions.
3. Converge to identify which solutions merit consideration.
4. Prototype a final solution.
5. Test it out on actual users.

What’s so great about a design sprint?

The greatest benefit of a design sprint is that it simulates what might actually happen over months into a short week, and gives REAL direction to everyone involved as to what might work or not; eliminating time going down the wrong path.

Design sprints can give clarity on goals, problems, and solutions to EVERYONE involved; not just a siloed creative group, separate from the clients, developers, or users.

Design sprints can also eliminate the potential for perceived solutions and problems to be the focus. You know these kinds of conversations. They start with things like “we need this, because of this” or “we need this because our competitors are doing it”, etc.

Ok, design sprint = cool for collaboration and eliminating costs down the road. Why health care specifically?

We’ve talked in the past about the gaps in the health care industry, and why this is important for everyone (you, me, the kid down the street). That’s to say, there’s A LOT to cover in health care, it’s not just a simple workflow or a marketing site that we just need to “restyle” or “make responsive”.

In a health care application, there are complex workflows (and very severe implications when an error occurs). There are different personas with different needs and usage. There are hurdles and obstacles to keeping things simple, like HIPAA regulations and security that need to be followed and checked throughout the process.

Together, designing a solution can be tricky or daunting, but this might be an issue ONLY if you don’t have the right people involved in the process, from the beginning.

We get it, health care is complex, and some applications are outdated, why not a regular design process?

A traditional design process takes a long time before you really know if your solution will work. By the time the design is implemented, it could be been months (even years!) since you’ve started the process. If it doesn’t work or if a crucial piece was missed, you’ve now spent a lot of time and money going down the wrong path, and now looking at needing to spend more time figuring out a better solution.

A long process also means that your team is bound to lose focus along the way; from stakeholders not being involved when they need to be (until it’s too late and they veto changes), to some stakeholders being louder on very specific items of non-accounted for scope. As the project continues and at points where everyone’s waiting for something to look at or test – the project can feel like it’s losing momentum.

However, a traditional process is still needed, but only after a direction is determined WITH a design sprint.

Design sprint then design process?

Design sprints can invigorate your project.

More importantly, it can also RE invigorate a project as you can do a design sprint at any point in a project lifecycle, not just the beginning. A design sprint can bring out new solutions, get people excited and on the same page. It can be a good way to test the direction and break down assumptions early on in the project.

This means it can actually be done WITH a traditional process. Once an idea is tested, the design team can then flesh out the design and work with the developers towards implementation, since what’s tested in a design sprint is usually a more basic workflow on a low fidelity prototype.

The reason a design sprint works first, is that it aligns all of the team on solving the right problem, and designing a solution together, quickly. This is a great tool to get buy in from everyone, and ensure that everyone’s working towards the same goal as you continue after the sprint.

This way, no one is left in the dark. No one’s taking over the project pushing their agenda. And more importantly, the likelihood of pulling a veto card in the middle (or worse, end) of a project is diminished.

A clearly defined problem and solution provides a north star in the project that everyone focuses on and can rally behind.

What does this mean for legacy application (like one in health care?)

For a legacy health care application that might have years of iterations tacked on, that momentum might be just what’s needed to really make some change or to push the needle. That type of quick dive provides a way to take a chance on new ideas and test them – without the risk of losing months of time and resources.

With a design sprint, you can test your ideas after a few days, on real users, and see if your basic ideas carry weight. No waiting months or years. With that type of instant feedback, you can align your roadmap for the months to come, feeling more confident that you’re steering in the right direction.

Do you think a design sprint could be the type of kickstart you need? Get in touch with us today and we can chat about the options you have and what a project with us might look like.