It’s time to get creative

Posted by: NHSBSA Editor - Posted on:

We’re living in an age where we are chasing the latest buzzwords and trends. We hardly slow down to look at the path we’ve covered to see if we’ve delivered or not. We should take the time to acknowledge how difficult (and amazing) it is for a large organisation such as the NHSBSA to develop digital products, get feedback and reach ‘real users’ as quickly and frequently as they do.

But it’s not all rosy.

In this blog, I share some of the challenges we come across and how we’re overcoming them and will continue to overcome them.

It’s time to get creative.

Agile – what is it?

Agile is a term used to describe approaches to software development. It emphasises continuous delivery, team collaboration, continual planning, learning and releases.

A lot of digital products and services here at the NHSBSA are now being developed using this method.

We only allow them to go ‘out in the wild’ (being used or tested by real people) once we’ve:

  • Completed a discovery – part of the development lifecycle where you gather detailed information on what your end users want
  • Survived a GDS assessment – to ensure our products meet the Digital Service Standard and protect the quality of GOV.UK
  • Delivered your Minimum Viable Product (MVP) – made a product with just enough features to satisfy early customers, and to provide feedback for future product development

Manageable, valuable and achievable product delivery

How do we make this happen? Let’s start at the beginning.

Most projects start with a hypothesis. This can take many forms whether it could be a business problem, a user need or just an idea. What it shouldn’t be is a solution.

We shouldn’t just blindly accept this initial hypothesis either – it’s important, if not essential to question its validity. It’s not that the person who gave you it is wrong; it’s just that they probably didn’t have the time to fully investigate it. As a user experience designer, that’s our job. We ask questions such as:

  • Will this save the money the business expects it to?
  • Is it a problem for the user in the way that we think it is?
  • Can it even be done?

Once we have the entire picture it allows us to understand if we are looking at the right thing to begin with. You could spent a lot of time and money designing a very elegant solution, deliver it efficiently and then realise nobody needed it or that it actually costs the business more money than it saves.

MVP is a process and not a product  – Eric Ries, author of The Lean Startup

In simple terms, an MVP is a sketch and the final product is an oil painting. When developing a product, we sometimes forget to sketch and go out full pelt with the oil paints.

In the product development world, this means more features squeeze their way in and users have to wait to get the final product.

This is where we need to get a bit more creative.

An MVP can be anything. I always ask myself, ‘what can we delivered quickly to bring users the most value?’. This could be anything from streamlining an existing process to improvements made to a paper form from learnings you’ve made while researching the digital version.

People often tell me they found this process stressful, I don’t think it needs to be

It’s difficult for teams to get past the idea that they’ll get a chance to add or improve things after the MVP reaches the end users, or that the first thing they give to users doesn’t even need to be the digital product at all.

Deciding what makes the cut for your MVP should be an exercise that takes place after you have looked at and investigated the entire problem. All you should be doing is taking a look at all of the things you’ve learned and created as a team – prototypes, process improvements, changes to existing paper process and deciding what can and should be achieved first and how.

If you look at it like this, an MVP should relieve pressure – not cause it.

Look into the future

To enable efficient continuous improvements in the future, it’s important to understand what else is involved at the beginning.

This means that once you’ve delivered the MVP, you have a backlog of things that are already in the pipeline. They don’t all need to be fully solved or thought through, but we do need to look a little further and wider than the MVP.

This will allow your team to keep up momentum and will ensure that you don’t build a ‘Frankenstein’ product by building features you don’t have time to properly think about and test.

So what’s the take away?

Embrace the process of MVP and smaller releases; be creative, open-minded and embrace agility.

While you’re overcoming some of the more complex issues such as authentication, environments and legal battles that naturally come from working on new digital services, always ask yourself ‘is there anything else that can be released’ because sometimes, the smallest changes can benefit users the most.

Contact if you have any questions or would like to learn more.

Leave a Reply

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