What the resident and provider portals had to do
Nova Scotia was putting essential health services online for the first time. Two portals, two audiences.
Residents needed to:
- Renew a health card
- Update a name, address, phone number, or organ and tissue donor status
- View a digital copy of a health card
- Submit forms and inquiries
- Enroll in Family Pharmacare and Seniors' Pharmacare
Providers needed to submit forms and view their letters and pay statements.
All of it had been done by mail. People reach for these services at the point they need care, not at a moment when they have patience to spare. Someone renewing a health card is not comparing options or shopping around.
One participant, shown that a digital copy of a health card could be viewed on a phone, answered with the moment she had needed it: "I could have used the view health card a couple of weeks ago, when I couldn't breathe at the hospital and I forgot my card."
That is the standard the portals had to meet.
The portals needed a design direction, not more screens
By the time I arrived the project had been running for months. The early screens had been drawn from the technical specification, which is a sound way to make sure nothing gets missed and a poor way to learn whether a service works for the person using it. They were reviewed internally and did not hold up.
The team saw the gap themselves. They brought in a designer to take the design work forward, and then brought me in to set the direction, bring research into it, and get the project back to something the organizations involved could be confident in.
What had not happened yet was the work of understanding the service itself. How does a person actually renew a card? What are they holding in their hand while they do it? What do they need to see before they believe it worked?
Requirements tell you what a system has to do. They do not tell you what the experience should be. Closing that gap takes someone whose whole focus is the experience itself, and that was the role I was brought in to fill.
Two options: improve what existed or start over
I reviewed both portals, the prototypes, and the material behind them first. What that review found was not a design problem. None of it had research behind it, so nobody could say whether the screens worked, only whether they covered the specification.
Out of that came two honest options for the team.
- Refresh what exists. Accept that it will not be the best possible experience, and make it better step by step.
- Rework everything. Reset the project and rebuild from a proper foundation.
Putting the expensive option on the table is what made this a decision rather than a default. We took the first path, and set the design direction from there.
Designing for what the team could build and maintain
Three things shaped every choice: what the team had capacity to build, what the technology allowed, and how much time was left.
A direction the team cannot keep going after I leave is not much use to them. The work had to fit the people who would inherit it, and build on what they were already good at.
The designer on the team was doing the hands-on design work throughout, from the sitemaps and flows to the screens themselves. My role was to set the direction, review the work, and stay close enough to it that she could move quickly without second-guessing where it was going.
Getting design two weeks ahead of development
Planning and building at the same time invites rework. We moved design two or more weeks ahead of development, and settled the foundations before the build picked anything up:
- Component library
- Site map and flows
- Copy, written against the flows rather than filled in later
- Password and security rules
- Accessibility basics such as base text size, line height, and line length
The provincial digital service pattern library gave us answers to start from, so we were not working out how a standard form field should behave.
Working ahead costs time before it saves any, and it only holds if the open questions get answered inside that two-week window. That is the one thing a sponsor can clear and nobody else can.
Weekly updates and a demo every two weeks
I set the reporting structure and the team delivered it: short weekly updates covering what changed, what was next, and what needed a decision. A demo every two weeks. Prototypes instead of slide decks, because a deck asks people to imagine the thing while a prototype just shows it.
Screens had been going out as slide decks, small enough on the page that the details were hard to read. A prototype asks less of the person reviewing it.
Testing the flows with residents and providers
We ran two rounds of research with residents, 19 people in total, remote and in person, and a further round with 4 providers.
The first round covered the everyday tasks: changing an email address, replacing a lost health card, viewing a digital card, updating donor status, requesting a temporary absence, and submitting a form. The second round covered health card renewal and both Pharmacare programs.
Finding participants takes lead time and a small budget, and booking it early is the difference between research that shapes the design and research that arrives too late to change it.
What the first round of research found
The first round confirmed what the review had already flagged. Primary, secondary, and supporting actions were hard to tell apart. Help was missing at the screens where people needed it most, including a form upload page that never said what could be uploaded. People arrived there and asked what they were meant to attach, and where to find the form in the first place.
The clearest finding in that round was simpler than either. People pressed save, believed they were done, and were not. A second action was still waiting further down the page. As one participant put it, "When I hit save, I would have expected it to be done. I would not expect to have to scroll around and look for another way to update."
That is not a labeling problem. It is a flow built from a list of requirements rather than from how a person moves through a task.
The designer came into these sessions alongside me and took on more of each one as the rounds went on, so she learned the method by running it rather than by reading about it afterward.
The second round found people finishing tasks they did not understand
The reworked flows held up. What the second round found was not navigation at all. On the Seniors' Pharmacare enrollment, people completed the steps and did not understand what they had agreed to.
They could not explain what a copayment was, or how the two payment options differed, after choosing one. They could not tell the difference between enrolling and registering. The consent section asked for a social insurance number in language dense enough that one participant read it twice and still asked what it committed them to. Another described the form as reading like assembly instructions.
Finishing a task is not the same as understanding it. A flow can test well on completion and still leave someone holding a decision they could not explain to anyone else. Only watching people work through it tells you that, and only if you ask what they think just happened rather than whether they got to the end.
The people using the portal were often not the people it was for
Every participant who worked through the Seniors' Pharmacare enrollment described doing it for a parent rather than for themselves. Not some of them. All of them. One described how long that took: "It took me five years to get my mom to get online banking."
That changes the design problem. A form filled out by someone helping a family member needs different things from one filled out alone: a way to save and come back when the other person is not there, language plain enough to explain to them, and a copy of the confirmation that reaches both people. Participants asked for all three without being prompted.
None of it was in the specification, because a specification describes the transaction and not the situation the person is in. A single round of testing focused on task completion would have missed it too.
Rebuilding confidence when progress was hard to see
Nobody on this project was working with a single partner organization. There was a chain of organizations, each answering to the next, and each one further from the work than the last.
A project that has been running for months and has already changed direction once is a project people watch closely, and reasonably so. When progress is hard to see, the people at the far end of that chain start to doubt it is going well. That is what anyone does when they cannot tell how something is going.
So a large part of the work was not design work at all:
- Progress became visible on a set schedule, so nobody had to ask how things were going.
- Working prototypes replaced descriptions of what we planned to do, so people could react to something real.
- Decisions came with their reasoning attached, so the direction could be defended by people other than me.
- Sign-offs and acceptance criteria were agreed rather than assumed, so approval meant the same thing to everyone giving it.
- The strategy went to the organizations above us in person, presented by me, which is not something to ask a team to take on for you.
By the time I left, the conversation had moved from whether the project was going well to what should happen next. That was as much of the result as anything that shipped.
What the research did not solve
Two rounds of research were enough to change the design. They were not enough to finish it.
Some problems survived the rework. A third of the second-round participants still could not find how to log out, a fix that had been made and had not landed. The electronic signature step stayed unresolved for the people it mattered to most: participant after participant said their parents would struggle to sign with a mouse or a trackpad, and there was no version of that step which removed the difficulty rather than moving it.
Testing on a desktop prototype also hid things. Two participants could not see a primary button because their screens were smaller than the prototype assumed. That is not a finding about the design. It is a finding about the method, and it is the reason responsive testing went into the framework the team kept.
The honest summary came from a participant at the end of a session: he thought it was ninety percent there. That was the right read.
What the internal team could do after I left
The rework was not assumed to have worked, it was tested. In the second round, participants read the section explaining what would happen next, noticed which of their answers had changed, and valued having a reference number to keep. Those were the exact problems the first round had found, put back in front of people to see whether the fixes held. One participant, looking at a renewal reminder inside her account rather than in the post, described the problem the portal actually solved for her: "I would have no idea when to renew. I lose letters, I forget to renew. I could never lose this."
The work handed over was internal, and that was the point:
- A designer who was already designing the flows, and who could now plan and run usability sessions, and present her own work. The presenting mattered as much as the rest, because work that never gets shown convincingly does not get built.
- A usability study framework the team could run again without me, including the test planning, the session scripts, and the responsive coverage the second round showed was missing.
- Testing results with recommendations attached, so the findings arrived as a plan rather than a pile of observations.
Coaching someone through live research takes longer than running the sessions yourself. That extra time is what leaves a team able to run research without you, and it is the first thing to get cut when a schedule tightens.
Five things you can use on your own project
These five made the most difference on this project, and none of them cost much to try.
1. Ask what just happened, not whether they finished
Completion is the easiest thing to measure and the least informative. Ask a participant to explain, in their own words, what they just agreed to and what happens next. On this project that one question separated the flows people could finish from the flows people understood, and those turned out to be different flows.
2. Test the fix, not just the design
Put the screens you reworked back in front of people rather than moving on to new ones. A second round is how you learn that a fix did not land. Ours told us one of the problems we thought we had solved was still there, which is not a comfortable finding and is much cheaper to have before launch than after.
3. Let people use their own device
Two participants could not see a primary button because their screen was smaller than the prototype assumed. A desktop session will never show you that. Let people bring the device they would actually use, and treat what breaks as a finding about your method rather than an inconvenience.
4. Have the designer run the sessions
Not watching from the back, running it. Watching someone hesitate on a screen she had designed does not come through in a written report, and it is the fastest way for a designer to stop defending decisions and start testing them.
5. Write the copy against the flow, not after it
Copy written to fill boxes that already exist carries over whatever those boxes assumed. Written against the flow, it shows you the gaps early, while they are still cheap to fix. Most of what confused people on this project was language, not layout.
