HealthTech
Openmind Wellbeing
An online tool that helps companies look after their staff
Key outcomes
- Traced testing back to the agreed requirements, so coverage stayed high before launch
- Cut the number of defects reaching each launch through staged testing and early fixes
- Protected and handled personal information correctly from the very beginning
The problem
Most tools for looking after staff wellbeing are a bit of a patchwork: one app for booking sessions, another for surveys, another for reports. Openmind Wellbeing set out to do all of it in one place: wellbeing services, keeping staff involved, scheduling, messaging, and simple reporting.
What I did
- Talked to the client and worked out what the product really needed to do, turning a big, fuzzy idea into a clear, ordered list of what to build first.
- Wrote the documents the build team worked from, with plain descriptions of each feature and how people would use it, and kept a clear line from “here is what the business wants” all the way to “here is what we built”.
- Mapped out how each part should work, from booking sessions through to reporting and admin, and looked for ways to make them simpler.
- Helped check the work and test it with the team, right through to launch.
Why it was tricky
Anything close to healthcare comes with real responsibility. Staff wellbeing information is private, so protecting people’s data had to be part of the plan from day one, not something bolted on at the end.
How it turned out
The result felt like one proper product rather than a collection of separate features, and it is live at lyfetech.io. Because the way it worked was written down clearly, new team members and client staff could learn it quickly.
A sample of my work
Illustrative only. It contains no confidential client information.Weekly status report
The short weekly summary I used to keep the client and the team informed of progress.
- Work included
- The booking, engagement, messaging and reporting features have all been agreed and confirmed.
- Timing
- The reporting section is running a little behind. A plan to recover the time has been agreed.
- Budget
- Spending remains in line with the plan.
- Risk and compliance
- The protection of personal information was built into the plan from the very beginning.
Key stages
- Requirements agreed Stage 1
- Booking and engagement features built Stage 2
- Reporting and administration Stage 3
- Client testing and launch Stage 4
A sample of my work
Illustrative only. It contains no confidential client information.Risk and issue log
How I tracked the risks, assumptions, issues and dependencies on a product that holds private staff wellbeing information.
| ID | Type | Item | Impact | Owner | Status and response |
|---|---|---|---|---|---|
| R1 | Risk | Staff wellbeing information is private and must be protected at every step. | High | Project Manager and development lead | Managed. Data protection was built into the plan from the first stage and checked at each release. |
| D1 | Dependency | Booking, messaging and reporting all rely on one shared set of records. | Medium | Development team | Tracked. The shared records were agreed early so the parts stayed in step. |
| A1 | Assumption | Employers manage their own staff and settings from an admin area. | Medium | Product team | Confirmed with the client before the work began. |
| I1 | Issue | The reporting section was running a little behind the plan. | Medium | Project Manager | Resolved. A short recovery plan brought the timing back in line. |