Page 3 of 9
Design process in detail
Before you start designing something it is important to spend some time thinking about how the design process will be organised.
Many people have thought about what a good design process should be and there is a lot of excellent and hard-won advice on how to make the best use of your time and resources when designing a product. Collectively these resources describe an agile way of approaching product development. In recent years, achieving an agile process has become one of the most valued principles in developing products, services and even whole businesses.
We have previously described what agile processes are and why we think they are valuable. This section will focus on advising how to organise your design activities in an agile way.
Working in iterations
Traditionally, the time frame between starting a medical device development project and the release of the product to the market is very long, typically this is measured in years. However, most of this time is taken up by activities like running clinical studies and gaining regulatory approval, while the actual time spent designing the product is much shorter.
Whether you have 2 weeks, 2 months or 2 years, you should divide the available design time into a series of short intensive iterations, better known as sprints, rather than having a single long gradual process. It is a good idea to keep the sprints short so that there is an opportunity for regular feedback. At Ctrl Group we default to a 2 week sprint.
Design Sprints Structure
- Start with a sprint planning meeting
- End with a sprint review
- Optionally meet for daily stand-ups
- Optionally track progress of individual tasks if the work is complex and detailed
We have described our typical sprint in Module 2.
Resources
Scrum Guide and
GV Design Sprint
More information about design sprints
Phases of product development
The UK’s Government Digital Services (GDS) provides a useful model for breaking down the agile product development and delivery process into five stages: Discovery, Alpha, Beta, Live and Retirement.
The GDS Service Manual has provided a lot of inspiration in the way that we, at Ctrl Group, think about our product development process.
Here is an overview of the different phases when developing healthcare products at Ctrl Group:
Step-by-step
-
Discovery – What (if anything) should we build? The idea for a product may be well-defined before the design process has begun, with a clear understanding of the need. There may even be similar products already on the market that can act as reference points. Or you may be starting a vague feeling that something should exist but you have no idea what that something should be. The discovery phase aims to gain an initial understanding of user needs and test a few different options for product directions, and two design activities that work best during discovery are fast prototypes and contextual research.
-
Alpha – Are we building the right thing? During the alpha phase we design and build a prototype of the product that will allow people to try it out at a higher fidelity. At this point, the list of features may well change as user feedback comes in through formative research.
-
Beta – Are we building the thing right? The beta phase is about creating a much more detailed product, getting as close as possible to being finished. Summative testing during the beta phase helps with fine tuning product features and design.
-
Live – How should we improve the product? Launching your product isn’t the end of the process. You should still aim to monitor the use of the product in real life, adapting it to real-world user feedback. In fact, post market-surveillance is a regulatory requirement for medical devices.
In medical device development, agile processes are less well-known and are often considered incompatible with regulatory-compliant product development processes. The following section will describe how agile processes can be used whilst and still meeting regulatory requirements for design controls.