What the resident and provider portals had to do
Nova Scotia Health needed one portal for residents and another for healthcare providers.
Residents needed to:
- Renew an MSI (Medical Services Insurance) 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."
The health portals needed a design direction grounded in research
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.
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 give the organizations involved confidence in where it was going. The agreed outcome was a design direction tested with residents and providers, and a way of running research the team could keep using after I left.
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, not what the experience should be. That was the gap I was brought in to close.
What the portals project had to work around
My plan opened with an intake assessment and conversations with stakeholders, so the direction would fit the project and the team as they were. I led the design and research process, while the organizations involved brought what they knew about their services and systems. The constraints were clear from the start. I joined a project that had been running for months, with screens already designed and some already built, and with a fixed budget and a fixed launch date. The content management system was already set, and the technology behind the portals limited what could change. A development team was ready to build, so work had to keep flowing to the developers while the design direction was set, and anything already developed had to be improved in this pass rather than rebuilt. Progress also had to be visible across a chain of organizations, each answering to the next. Recruiting participants for research took lead time and a small budget.
2 options: improve what existed or start over
I reviewed both portals, the prototypes, and the material behind them first. The review found that 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 2 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.
I recommended the refresh. The team didn't have the capacity to rework everything from scratch, the technology set limits, and developers were waiting for work. Small improvements could ship early and show progress while larger pieces were reworked in stages. Putting the rework option on the table anyway meant the team chose the refresh knowing what it gave up.
Designing for what the team could build and maintain
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 2 weeks ahead of development
Planning and building at the same time invites rework. We moved design 2 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 2-week window. That is the one thing a sponsor can clear and nobody else can.
Weekly updates and a demo every 2 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 2 weeks. Prototypes instead of slide decks, because a deck asks people to imagine the thing while a prototype just shows it.
Testing the flows with residents and providers
We ran 2 rounds of research with residents, 19 people in total, remote and in person, and a further round with 4 providers. A recruiting firm already approved by the government found participants from its own vetted list, against criteria I set, and I facilitated the sessions.
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."
The problem was the 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. (I wrote about how teams build that shared understanding.)
The second round found people finishing tasks they did not understand
The reworked flows held up. The second round found a problem with understanding. 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 2 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
All 5 participants who worked through the Seniors' Pharmacare enrollment described doing it for a parent rather than for themselves. One described how long that took: "It took me five years to get my mom to get online banking."
That changed what the form had to do. A form filled out by a caregiver 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 3 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.
Building confidence by making progress visible
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 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.
A large part of my role was keeping every organization informed and confident:
- 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.
By the time I left, the conversation across the organizations was about what should happen next.
What the research did not solve
2 rounds of research were enough to change the design. They were not enough to finish it.
Some problems survived the rework. 4 of the 12 second-round participants still could not easily 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: 3 of the 12 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. 2 participants could not see a primary button because their screens were smaller than the prototype assumed. That was a gap in the method as much as the design, and it is the reason responsive testing went into the framework the team kept.
A participant summed it up at the end of a session: he thought it was 90% there.
What the internal team could do after I left
We tested the rework rather than assuming it worked. 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.
5 things you can use on your own project
These 5 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
2 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
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.
Last updated October 27, 2026
