Over 115,000 Ontarians passed away in 2020, and each of these unique deaths went through the same mandatory death registration process. Death registration allows grieving families to bury their loved ones, close billing accounts, and settle estates. Federal and provincial governments also rely on accurate death-related reporting in healthcare planning.
Unfortunately, death registration in Ontario is paper-based, slow, and full of duplicate work between medical, funeral home, and municipal staff. The end-to-end process takes 6 weeks to complete (on average), and delays leave families waiting to say goodbye to their loved ones. Paper forms are also prone to error, which retraumatizes families months later when a company or government office rejects an incorrectly-written death certificate. Meanwhile, the users involved all consider mounting deathcare paperwork a distraction from their real jobs.
Our team (including my amazing co-UX designers Myuri Thiruna and Diane Robertson, as well as 4 program and business analysts) knew that a revamped, digitally-focused process could help if implemented carefully.
How could we build an online death registration system that made things better for 3 distinct user groups and grieving families?
Discovery around this project focused on 3 core user groups working directly with death registration documents: medical practitioners (including both doctors and coroners, who would take over medical investigation in specific cases), funeral directors, and municipal staff processing forms. I joined the project in time to help develop the discussion guide and facilitate 1:1 discovery interviews with 30+ medical practitioners in Ontario who had experience with death registration.
From previous team members, we had access to past work that had been done with funeral home and municipal staff. I led synthesis sessions where our team used open qualitative coding to come up with themes applicable to our medical practitioner work, and then bring in findings from other sessions to determine overarching themes.
Key issues included:
If you're interested, I consolidated all of our research into a deck here.
Through our interviews and related research work; I learned a lot about the contexts in which medical professionals, funeral directors, and municipal workers worked and their interactions with families. Families are largely shielded from the death registration process, unless something goes wrong along the way. As such, they became a key secondary stakeholder to consider rather than our primary user group.
To make our findings digestible and applicable to process improvement; I made slide decks, user proto-personas, and journey maps. Here's an example of a detailed journey map for a coroner's death registration journey (1 of 3 types of medical practitioner sub-journeys):
Click to enlarge
Maps like the one above usually showed things at a more detailed view than we needed for design activities. So, I also created simplified current and future state maps for conceptual decision-making:
The current death registration process compared to our proposed online pilot (named, not by our choice, EDR)
Finally, I led our team through an activity to build research-backed design principles for our new online death registration system. This was an introduction to most of the team to this concept and why it was important. Our new system would be:
Our design process began with the usual suspects: inspiration from other national and subnational death registration systems from around the world. I also got our team to branch into patient case management and funeral home management software to get a feel for the types of interfaces that deathcare professionals were familiar with. Since our users typically used desktop computers, we departed from mobile-first in order to prioritize this experience.
Our project team planned to pilot the beta online death registration system in a few specific communities across Ontario. I convinced the product manager that it made sense to involve interested medical, funeral, and municipal staff in these areas with our work early: to shape our overall direction and help us refine our mid-fidelity designs.
After working with our team to prioritize our key questions, I led co-design workshops with 5-10 members of each of our 3 user groups to shape the details of our mid-fidelity designs (e.g. error message styles and interactions, questions per page, dashboard style).
Here are some sample screens from our workshopped prototype:
This project was an exercise in balancing thoughtful design with legal and business constraints. My first wireframes were based on case management systems, with all 3 user types adding information to one shared profile of the deceased person. We had many discussions with leadership about the usability advantages of this format, but they couldn't accept it from a legal liability perspective (even if each user's changes were logged in detail), so I adapted.
The new flow had each user create their own document, and then match it to the documents created by other users if available. Understanding that misspellings of names or date transpositions can happen, match suggestions happen even if a document is not a perfect match. Users are able to review details, and unmatch a document anytime before they submit.
To balance the burden of users entering repetitive information across documents, we revisited and streamlined some of the other steps in the system that could add burden to users. For example, we compromised with the business area team to lower the burden of nagging about empty fields (which were "nice to have" for policymakers and annoying for everyone else). We also revisited steps, adding more selective disclosure to hide and automatically populate fields that are irrelevant (for example, hiding pregnancy-specific questions from people safely outside of the pregnancy age range).
I also successfully fought (going up to the business team director and senior IT levels) for a departure of the business team's long-standing practice of using postal code-based address lookup in all of their online products, in favor of Google Places Autocomplete (for local addresses) and combo boxes that mimic autocompletion (for lists, like countries or facility types). While consistency with the team's other products would have been conceptually nice, research clearly showed that deathcare practitioners (especially coroners and hospital staff, with limited information about the deceased person) usually didn't have information about relevant postal codes.
I developed and led usability tests with about 8 members of each of our user groups. Based on findings (ranked by severity and feasibility), we made changes to our final screens. Below are some examples of key changes:
You can take a moment to step into a medical practitioner's shoes and explore the electronic death registration process. If you get stuck in the prototype, click out onto this text or the caption below it, and then scroll.
This flow, with some of the elements pre-filled, will guide you through creating your own Medical Certificate of Death. Blue highlighted elements are all clickable, if you get lost.
This solution is currently active as a year-long beta pilot, based on our final prototypes. Users in over 30 medical facilities and funeral homes in 3 communities across Ontario are trying out online death registration, alongside or instead of the existing process. We await final results, but some things look promising...
As always, I learned a few things from this work:
Made with <3 in Toronto and Seattle.