Facilitating a digital approach to handling patient data(6 min)
Background
Sheffield Occupational Health Advisory Service (SOHAS) is a registered charity that gives advice and support to people whose work affects their health or whose health affects their work.
SOHAS partnered with us as part of the Home Office’s digital development programme. We had 28 days over 6 months to research, design and build something of value to the charity.
The problem
SOHAS primarily offers advice sessions to people. Advisors use paper forms to record information about a client's background, health history and details about any advice they provide.
The data is added to a database which is used to perform some analysis, giving insights which help the charity improve its service and bid for funding contracts.
In their brief, the charity’s only requirement was for a new database which was cheaper to maintain and easier to add data to.
| Service name | SOHAS Records |
| Organisation | |
| Period | 01/21 to 09/21 |
| Project length | 28 days over 6 months |
| Phases | Discovery and Alpha |
| Role | Interaction Designer |
Discovery
The idea of diving straight in with a new database was tempting because of the tight deadline. Despite this, we opted for a proper discovery to allow us to understand more about the users and the problems we were trying to solve.
To start, we had a few sessions with the head of the charity to unpick the brief. We then ran six in-depth interviews with advisors to understand their processes and pain points.
User types
Advisors: The paper form caused the most trouble for them. Rarely updated, most of the fields were obsolete. Advisors would shift stacks of them across Sheffield as they moved between GP surgeries to see clients.
Database user: The head of the charity would spend two days a month to manually copy data from the forms. This task ate up precious time they could have used to prepare funding bids.
Mapping out the 'as-is'
I translated the findings from our research into some user journey maps. This gave the team a view of the wider issues, we discovered most of the areas we needed to improve here.
Advisors - journey map
Database user - journey map
Alpha
Designing good questions
We decided that out of the ideas we came up with, fixing the content on the forms would have the quickest impact on advisors.
- We let the users take the lead.
We asked advisors to annotate and highlight parts of the form that caused confusion.
- We re-framed questions.
Our content designers consulted resources by the ONS and NHS about how best to capture data on race and gender.
- We slimmed the forms down.
To make sure that there was a genuine need for capturing certain information, I reached out to the Equality and Inclusion Practice Leads at the Home Office to get advice.
Reducing the reliance on paper
Idea
By replacing the paper forms with a digital alternative, we could:
- eliminate double keying
- allow people to add information to the database from anywhere
- build trust in the data being captured
Risks
Knowing this change would have an impact on the majority of what people at SOHAS do, we had to be sure that this could work. Could replacing the paper forms with a digital service:
- distract from talking to patients?
- reduce the depth of information captured during an advice session?
- increase admin workload on advisors?
Research
So as not to introduce bias into what we found out, we didn’t show any designs to users. Our researchers built on past conversations to gain a deeper understanding of the purpose of the forms. As part of this research we used an adaption of the digital inclusion scale to assess how confident users were in using technology.
Designing digital forms
In my experience, a lot of government services involve replacing some sort of paper format with digital and it is never a case of replicating what already exists.
Finding: We found that advisors don’t fill in the forms in any particular order. They often leave entire sections blank, adding and updating parts on a patient's subsequent visits.
Solution: I generated some high level flows of different scenarios to show the users. We used them as talking points, learning more about which questions are typically asked before, during and after an advice session.
Now that a journey was validated with users, I paired this with our improved questions. I built a series of prototypes in Figma and from this point on we aimed to refine the designs. We completed three further rounds of research.
Adding details in parts
A better way to get insights
Data is precious to SOHAS. It demonstrates their effectiveness in getting people back into employment, this is crucial to winning funding from local authorities. In future, SOHAS hope to use data to look at how the help they offer improves outcomes for patients.
With the time we had left, we had to be pragmatic with what we could achieve.
- We prioritised the most useful insights
I ran a session with our stakeholder to identify what kind of insights are most valuable.
- I considered technical constraints
In rebuilding the database, we had to restructure how data is stored. This resulted in some conflicts between legacy data and new data, constraining how we could do wide searches. I worked closely with the developers to figure out what was possible.
- I got feedback from other designers
I ran a design crit with other designers with experience in internal services with similar requirements.
With the constraints on time and the complexities of the legacy data, the resulting journey was a compromise between what the stakeholder initially desired and what we could deliver.
Enabling collaboration across professions
With one day a week to carry out work, we often found it hard to get everyone in the same conversations. I looked at ways to help keep UCD and technical roles working together.
- I sourced components designers and developers could both use
I referred to design systems across organisations to identify accessible components with examples using React.
- We adapted our ways of working
I set up an hour-long session every two weeks to talk about research and design changes.
- I documented functionality and styling
A single source of truth to build from, this was useful when we didn’t have the time for collaborative meetings.
Autocomplete component from Atlassian Design System
Outcomes
In the final demo to SOHAS, they were pleased with how much we managed to achieve in a short space of time. They intend to carry forward with future improvements with their in-house Engineer.
In an ideal scenario, we would have liked to carry on iterating the service until we met all of their needs. There were some things didn't get round to:
- refining error validation
- testing the live service with users, including users with differing access needs
- adding the functionality to send patient notes as an email summary to patients and GPs
This project was a lot of fun. If you’d like to see more, check out our Figma file .