Patient Triage Dashboard
Patient Triage offered patients a swift means to contact their GP practices, yet lacked sufficient support for practices to adjust their workflows accordingly. Working closely with a new product team, we successfully deployed the Patient Triage dashboard nationwide within a 5 weeks.
Team: 1x Product Manager, 1x Product Designer, 1x Product Ops Manager, 4x Engineers· Timeframe: June - July 2022
TL; DR - How I contributed
01. Led design of the dashboard in just one week.
02. Worked closely with the product team to scope our MVP, knowing we had limited frontend capacity.
03. Provided clear documentation to facilitate handoff to developers.
Outcome: MVP rolled out nationally in 5 weeks, 91.7% Retention, 92.3% User satisfaction
Overview
Accurx mission is to build a world-leading healthcare communication platform. Established in 2016, today over 98% of GP practices use accuRx to communicate with their patients.
Async communications between healthcare providers and patients became even more relevant during lockdown. This was the reason behind building Patient Triage, a way for patients to contact their GP practice via an online consultation, back in April 2020.
Framing the problem
An overwhelmed workforce and dissatisfied patients
GP practices in the UK face challenges meeting patient demand due to increased demand and decreased capacity, leading to an overworked workforce and reduced patient satisfaction.
AccuRx's Patient Triage has improved patient contact with practices, but have not fully delivered on making it easy for practices to action these requests. One reason this isn’t easy today is because Accurx hadn’t given practices the data they need to optimise their workflows around Patient Triage, and appropriately manage their staff to meet patient demand.
The current usage report page was lacking sufficient data and insights, resulting in low usage by practices.
The team
Balancing advocating for design and not being too disruptive
I joined a cross functional team just in time for the kick off of this project. I focussed on the design of the Dashboard in a timeframe of a week, working closely with the rest of the team to prioritise features for our MVP, and have detailed expectations on what current iterations might look like.
The team never had a full time designer before, so I was keen on involving the team in design decisions, and finding a balance between advocating for design and not being too disruptive of established ways of working.
Discovery
Understanding the need for data and insights
In order to understand where we can best place our efforts to give users a greater sense of control, we needed to understand what data is of the highest demand. The first iteration of research calls had already been conducted by our Product Manager, Clinical Lead and Product Ops Manager, giving us clear understanding on our users struggles and needs:
📊 Historical data: Practices need to know what demand they can expect at specific hours of the day/days of the week. This way, they can roughly plan their staffing to align with the anticipated demand
📈 Live data: Practice managers need to understand the team’s live capacity so that they can appropriately manage (assign and keep track of) requests.
Kick off
Ideating!
The project kicked off with an ideation session ran involving people in the team, and some key stakeholders. The goal of the session was to have a shared understanding of our users, their pain points and needs, so that we could ideate together on a number of possible solutions to the problem.
Design
MVP scoping
Running a design critique to agree on what to deliver in our MVP
Once the design was finalised, it was time to involve the team to agree on what was necessary for our MVP. Given the limited front-end capacity, it was crucial to commit to deliverables that could be completed on time and provide value to our users.
To foster collaboration and inclusiveness, I organized a design critique session with the team. This was a new experience for them, but my goal was to create a comfortable environment where everyone could contribute to design decisions and feel empowered to share their input.
I shared some documentation beforehand so that, if needed, people knew what to expect. The session itself was incredibly helpful, and the team agreed collectively to what prioritise. I received useful input to tweak my design, and finalise our MVP.
Handoff and delivery
Providing clear documentation to the team
Once the UI was finalised, I went on holiday 😅. It was important to handoff designs with clear expectations on what was included in MVP, what was nice to have, and what was coming next.
Our MVP has been built and released to our users. Reusing existing components and libraries helped overcome the little front end capacity the team had.
Outcome
Qualitative and qualitative feedback to iterate on the solution
91.7%
users returning to dashboard after 2 weeks
91.7%
users engagement with dashboard in first 2 weeks
92.3%
user satisfaction
It was clear to us that our MVP was only a first iteration to the dashboard, so collecting data and feedback from users after releasing it was the only way for us to understand how to improve the product moving forward. Jynn, the very first User Researcher to join the team, did a great work on embedding a survey in the product so that we could gather feedback while users are interacting with it in real life.
The results we collected were definitely positive, and consistent with what we'd expect to have to iterate on - the ability to set custom time frames to compare data, rather than just comparing the current week to the past one.
The team didn't limit themselves to qualitative feedback, as we also set clear OKRs around retention for this piece of work. Again, data collected was definitely positive, indicating strong potential for the future iterations of the product.
