Boston.gov's Certificate Request Service

Research & Discovery   |    Synthesis & Defining    |    Interaction Design    |     Testing     |      Project Handoff

Overview

The focus of this case study for Designlab is designing a fully online feature to handle citizen certificates requests (birth, marriage and death). Due to logistics at the time of this study, I was living in NYC, and being a similar metropolitan city, the research is based on NYC’s local government services.

In 2016, IDEO worked with the city of Boston to update the city's government website, as a first step to slowly integrate city services into the online space to better serve the city's population. From that project, a brand guide was developed, so that future designers and collaborators had a reference to work from.

With a pre-defined brand guide, I was able to focus on the user experience and interaction design, and apply the stylings according to the guide to ensure a consistent user experience throughout the website.

Getting to know the problem

Boston.gov's new feature request: A logged in environment and a fully online service to request a birth, marriage or death certificate are totally new features to the client. Studying an existing system might prove to be useful, which led me to my local registry in downtown New York City (which offers an online service) and conduct some research on user experiences with the request process.

Key Insights

From this research, I discovered the currently working albeit flawed system of requesting a birth certificate online. The existing online service that New York City has to offer is merely a third party request service called Vitalchek which charges a fee in addition to the certificate and shipping costs. Although slightly better than Boston's non-existing online service, users were not succeeding in their tasks which ultimately led them to request the certificates in person. A key observation I picked up was that NYC's online service is outsourced to a third party site, which breaks the user's task flow, and creates a friction that makes the user untrustworthy of the service. The lack of a logged in environment also dissuades the user from using the online service because they have no way of knowing the status of their request post-checkout. Boston.gov can take this opportunity to start from scratch and design a request service that can tackle these problematic insights.

Through my research, I synthesized my findings using an empathy map and storyboards, to create a primary persona which defines the average user's needs and goals. This persona will be used to validate the design decisions for the solution.

 Reframing the Problem

To guide my ideation, I reframed the persona's needs and goals as 'How Might We...?" questions to define the prioritized features.

Knowing that the proposed solution will have to be in line with Boston.Gov's brand guidelines, I conducted a site audit before laying out sitemaps for both the main portion of the website and the logged in environment. A user flow diagram is also created to determine how the user will navigate and find the new feature within the website. 

Sitemapping

Two sitemaps were created, one of the Boston.Gov's current sitemap and how the proposed feature would fit into the site structure, and the second a sitemap of the logged in environment, to define how the user will be able to access the certificate request service. It is important that users who are new to the website will be able to navigate themselves and find the service they are seeking, and in this case, to request a birth certificate. I've also decided to label the logged in environment as MyGov Portal, which can be accessed on the top header navigation, similar to a login / profile button. 

User Flow

Once the structure of the site is defined with a sitemap, I charted how users would land onto and navigate the site. This helps determine what the user interface requirements are, in order for the user to be successful in their task: creating a user account for the logged in environment and requesting a birth certificate via the online request service. 

Interaction Design: From Low to High Fidelity

Since Boston.Gov had a existing user interface and style tile I could reference, I decided to dive straight into creating high fidelity wireframes for the prototype. The goal of doing so is to make the experience as consistent and seamless as it would if on the actual website, and with Boston.Gov brand guidelines already nicely laid out for me, it wasn't too hard to design the UI for the proposed new features. 

Site Audits

I combed through Boston.Gov's existing site and gathered design patterns and UI elements that I thought would be relevant to building the logged in environment and the online request service. I also audited Vitalchek's request service to glean some insight from the user flow. 

Sketching

When building anything, it's best to have a blueprint before getting started. Just because most of the design elements and styling had been determined, I still had to design the request service's interactions and system architecture. Using data gathered from my immersion research and Vitalchek.com's site audit, I designed a rough sketch of how the user would interact with the interface: from landing on the home page, to creating an account to access the logged in environment service, to filling out an application to request a birth certificate. 

Hi Fidelity Wireframes and Annotations

Even though I was provided with a guideline of how the UI should look, designing how the process should work was still a challenge, especially for a governmental service, where there's a consideration of accessibility and minimizing margin for error. The process for requesting a certificates consists of several steps which didn't require any annotations since the design patterns were based on tried and true form inputs.

With the working prototype finalized, a UI Kit is created as a guiding document to be shared, along with the prototype, with stakeholders and developers. 

Based on initial feedback and findings, users were impressed with the ease of use for a government online service. There were concerns with the task flow having too many steps and fine print to read through, which is a necessary design tradeoff. I've managed to cutdown the process to 10 steps (compared to Vitalchek's 15 steps) which helps break down the task into smaller info chunks, which improves user's focus and minimize margin for user error. 

...and Some Potential Features to explore in further iterations

• Ability to apply for permits

• Request to vote by absentee ballot on Election Days

• File a claim with the city

• Register a Business

• Register a rental property

• Register for towed car alerts