So you’re keen to get involved in the design of a tech product? Great. More tech would be likely to succeed if designers got users involved from day 1 – your input is crucial. But it has to be more than your voice, because you need representation of all the users and consider the needs of tech–super savvy right through to the technophobes. Workshops are a great way to engage with all your users, and to get ideas of the really important features, the nice to haves and, in our experience, the ‘wow, why didn’t we think of that?’ elements. Our advice – be bold, think big and shoot for the stars. It might not all be possible, but some of it will be and that is what will make the tech you help develop amazing.
Develop a design brief
Workshops are a great way to build your design brief – essentially a shopping list of the things you want and how you want them to work. Give everyone a voice and ensure you include representatives from all your user groups. There are lots of ways you can get your workshop attendees to really engage and come up with some great ideas – see https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond for some inspiration!
Once you have a draft design brief you can present this back to at least some of the people who attended the workshop, plus some other potential users. This will enable you to sense check what you have captured and tweak it as needed.
This design brief will be your compass for the rest of the project so it’s vital to spend some time to get it right. And you don’t have to do it alone. A lot of health tech companies want to come and listen to users needs so they can better understand what they want.
Working with developers
What you don’t need to consider at this point is how this will all work. Unless you’re secretly an IT developer and you’re going to be writing the software yourself, the nuts and bolts of how is not your concern. The tech developers that you work with will tell you what’s possible and what’s not, but if you don’t ask for it, there is no chance you will get it.
The tech developers will typically produce a paper prototype or other mock-up which will allow you to see what the tech might look like/what it will do before they build anything. The next step is for them to produce something you can look and try. It won’t have all of the features you planned but you should be able to see some of the things it can do. Most developers will want feedback on the product as they go along and with each iteration. This allows feedback to shape what is being built and stops them spending time on unwanted and useless features.
This is also where your design brief is vital – keep referring back to it so you stay on track and ensure what is being built is what you and the users wanted.
Minimal Viable Product
At this stage, you may have the minimum viable product (MVP). In effect, this is the bare bones of the product – it might not do everything but it will do some of the key activities and so can be tried out. You can use the MVP with a selected group of users and give feedback on what works and what didn’t, so changes can be made. This cycle of feedback, improve, retest might go on for a while but is vital to get the product to a point where you are all happy to release into the wider world.