All the previous phases culminate in this one: the build. Within this phase, there are several steps, including finalising the features, translating the designs and content into the product and signing off the functional specifications.
Below are some processes that will occur in this phase:
Functional Specification Document
This document is typically led by the developers and defines what the product will do. This should be reviewed at least once or twice. reviewing must be specific and clear and should consider what is not mentioned in the FSD. An example :
- “A user should be able to see their questionnaire scores.”
- Product was built so that the user can see their most recent scores.
- The first sentence did not specify that the user should be able to see their most recent scores and historic questionnaires (which was an important but assumed point that was not integrated into the build initially).
User stories
User stories are an explanation of a software feature written from the perspective of the end user or customer, for example:
- As a doctor, I want to be able to see my patient’s tracked data, so that I can monitor their progress.
- As a patient, I need to receive reminders to help me remember to take my medication.
Tip: It is worth discussing the purpose of a feature with the developers, e.g. “I want people to be able to have an overview of appointments”. There are often different ways that an outcome can be achieved. In this case, one could have a list of appointments, a calendar in a patient facing app or link with an external calendar - different solutions will be good for different scenarios and budgets, and there may be a simpler way of doing something than we assume!
User journey mapping
This is an overview of what users will see throughout the use of the product and in which order. For example:
- What is the onboarding flow - how do people register / sign in?
- What do they see when they first get to the home screen or user portal?
- Are all elements always available or are they shown at certain times?
- Is all content available to be consumed at once or is it gated?
- When and what type of notifications and messages are sent to the user
Ways of working
The term Agile is used to describe the development process / project management. Essentially this means a process which delivers components in a continuous and iterative manner. This is different to the Waterfall approach, which is a linear, step-by-step process.
Agile software development involves the creation of minimally sufficient stand-alone app components (e.g. the registration screen for an app), testing of these by presentation to stakeholders (e.g. the customer, end-user, or investor), making modifications based on received feedback, reflecting lessons learned in the requirement analysis, and iterating this process until all stakeholders are satisfied. Minimal components may involve mock-ups and prototypes with limited functionality.
Agile is typically a faster approach as multiple elements are worked on at the same time, with feedback being provided throughout. It allows for changes and pivots to be made more easily (but these must be budgeted for). One potential issue is that frequent stakeholder involvement can result in ‘scope creep’, a phenomenon where stakeholders will change and/or add feature- and functionally requests far beyond those agreed in the initial requirement specification. To avoid this problem and its negative impacts, it is important that both client and software developers track and communicate these changes as well as their impact on the agreed budget and timeline for app delivery.
A waterfall approach is likely to be a lengthier build time so may take longer to get a product to market. It is potentially more risky as there is less visibility of elements en route to the completed product and feedback is only elicited at this point.
Because iterative, agile methods are generally faster and better at avoiding costly mistakes than linear, waterfall methods, they have become the method of choice for many kinds of project management beyond software development. For example, the UK government is delivering their digital services using agile methods and has developed a guide for project managers. An agile approach is also used by the Medicines and health Regulatory Agency (MHRA) In this context, it is important to note that one of the core values incorporated in the original Agile manifesto is user-centeredness (‘individual and interactions over processes and tools’), which nicely aligns with the shift to holistic, person-centred health and social care.
