Standardizing and Digitizing Government Forms in Canada: A Digital Service Network Spotlight

This case study was originally published by the Digital Service Network in January 2024. Read the original version .

DSN Spotlights are short-form project profiles that feature exciting work happening across our network of digital government practitioners. Spotlights celebrate our members’ stories, lift up actionable takeaways for other practitioners, and put the artifacts we host in the DSN Resource Library in context.

Background

Forms are a foundational tool of government to serve the public’s needs, with form design playing a critical role in how people access and experience government services. In 2022, the Canadian Digital Service (CDS) kick started an effort to deliver high quality forms by standardizing ministries’ form design and development process. This effort is named “Government of Canada (GC) Forms,” or “GC Forms.” GC Forms now offers public servants the ability to easily produce and publish secure, bilingual, and accessible digital forms.

To learn more, the Beeck Center’s Digital Service Network (DSN) spoke with GC Forms’ Senior Product Manager Stevie-Ray Talbot and Acting Head Ioana Contu. Additionally, team members Carolyn Connors, Sam Sadasivan, and Tim Arney presented their work at DSN and Code for America’s FormFest 2023; we’ve highlighted their insights here.

Developing a product vision rooted in user research

During the pandemic, government operations and service delivery rapidly moved online. At CDS, Talbot was crafting JSON form templates (aka “schemas”) to help government staff meet new and pressing needs for digital forms.

After serving multiple departments looking for similar solutions, CDS assembled the GC Forms team to explore a more standardized approach to form building rooted in shared forms needs. “This was an opportunity to create a quality product once that we could then deploy many times over,” Talbot shared.

Rooted in discovery research, GC Forms developed a product vision:

Help government quickly and easily create simple, accessible online forms that the public can use to apply to or access the information, services, or benefits they need.

To achieve this vision, the team developed a strategic roadmap and tactically delivered rapid iterations of form templates to get frequent and rapid feedback from government users.

GC Forms discovery research strategy

Through their discovery research, the GC Forms team identified two key factors that would serve as the foundation for a product roadmap and establish their technical scope:

1. Classifying forms based on the kind of relationship they establish between government and members of the public. The team’s discovery research helped them identify two broad categories of forms: (1) forms that create a two-way relationship where the form user shares information with the government and the government responds with a benefit or service (e.g., an application); or (2) forms that create a one-way relationship where the form user shares information with the government and the government uses that information to improve a program (e.g., a survey). Early on, the GC Forms team decided to focus on the first category, homing in on a product vision that focused on benefits and service provision.

2. Determining the level of security required for the data being collected in a given form. Under Canada’s Federal Privacy Act, forms must legally comply with security measures like obtaining express consent, only using the data for express purposes, and holding data for limited lengths of time. The team began by supporting “Protected A” level of security under the Privacy Act, which includes information like names and addresses. The team aimed for (and now can) support “Protected B” security for information like social insurance numbers.

After grounding themselves in these two key factors, the team’s primary tactic was to quickly deliver and test basic prototypes to receive frequent user feedback and continuously identify what was most desirable and feasible for a minimum viable product (MVP). Contu helmed the team with a strong mission orientation, emphasizing that improving the form-building experience would help public servants and constituents alike.

Prototyping as an iterative design process

The team structured their work in short design sprints to get on-the-ground user feedback from government employees. This supported the overall strategy of form classification based on complexity, a focus on security, and an approach of early prototyping and iteration based on user feedback. By using a JSON schema based on Talbot’s early work, the team could be responsive to quick iterations across design sprints with minimal development expertise.

The team evaluated the outcomes of each design sprint against a set of success metrics defined as an MVP:

Accessibility: The team first tested iterations in-house, then with public servants who use assistive technologies, and finally with third-party audits to ensure the product met accessibility standards.

Security: The IT team worked with an external auditor to ensure their product operated with a Protected B level of security.

Bilingualism: Canada has two official languages—English and French. As such, the Official Languages Act (OLA) requires all federal government services be provided bilingually. The team held a basic requirement that translating features should be accurate in both meaning and intention with minimal user effort.

Usability: The team conducted interviews and in-house testing sessions for functionality to reduce the cognitive load of using the product. This kind of testing continues today through support tickets and when introducing new features.

With each sprint, the team evaluated how their product performed against these metrics. “We needed the data from the imperfect first iteration in order to improve when we got to the second iteration,” Contu stressed when discussing the importance of their iterative approach. Sadasivan reflected on this learning process during FormFest, sharing that “It’s good to know we have processes that allow for change as our users’ needs inevitably change.”

The team is never short on ideas, but Talbot emphasized that they succeed by remaining steadfast in their vision with the capacity they have. “A lot of my job is saying no to the team,” Talbot joked. They have become highly adept at assessing the pros and cons of potential new features. “You have to understand what the challenges of a public servant are in order to build a tool that is actually useful for them,” Contu noted.

Meeting MVP metrics through customization

A major affordance of the GC Forms team’s in-house approach to building and prototyping is that it enables them to focus on deep customization to meet departments’ needs while remaining committed to their MVP metrics. Examples include:

Customizing for accessibility: Assistive technologies are highly varied. The team’s multi-step testing process brings inaccessible features to their attention, and as an in-house team, they have the ability to adapt the product quickly as these issues come to the fore. With multiple checkpoints in place—manual and automated, in-house and with third parties—the team works intimately with its stakeholders to meet custom accessibility needs and requirements.

Customizing for usability: The team identified commonly desired fields in their research, promoting high levels of usability with customizable “blocks” of packaged fields. For example, the builder adds all fields of an address together as optional “blocks” that are automatically joined together so the user is not required to add them separately. Additionally, the builder requires “locked blocks”—elements that the user building the form may forget to add but that user research revealed as useful or necessary for the respondent, like security statements or a post-completion confirmation message. The privacy notice “locked block” includes terms and conditions in the footer of each form with information about data retention and disposal. The team’s approach to blocks captures their efforts to reduce cognitive load for users of the form builder.

Customizing for bilingual delivery: In-house customization work allowed for bilingual form creation. After testing with French-speaking users, the team realized that the “language toggle” tool they built wasn’t the most effective solution. While the form builder automatically produced two versions—one in English and one in French—the toggle that allowed the user to switch their view between each version was not salient. This led users to unnecessarily create separate forms. The GC Forms team responded by altering the builder’s interface to a side-byside view of translations so that users can simultaneously view their form across languages in real time as they build.

Customizing for security: Security is top of mind for the team, and much of their customization work is shaped through the lens of security requirements. For instance, due to federal regulations, CDS can only hold respondent data for limited periods of time. To comply, GC Forms requires department staff to download a CSV of their form data and provide a confirmation code indicating the data are ready for deletion, after which GC Forms schedules deletion. However, this process can be time-consuming and confusing for departments, particularly those handling large volumes of responses. The team has experimented with iterations to this process, like removing unnecessary alerts and using more plain language to clarify why these steps are required of users. They continue to experiment and customize the product to support an increased use and maintain compliance with security requirements.

Lessons learned

Develop a shared product vision based on stakeholder needs. A clear, outcome-oriented vision helps ensure that development gets off on the right foot and serves as a tool to promote alignment across various stakeholder groups in complex, cross-cutting digital delivery initiatives.

Deliver early based on that shared vision and iterate based on feedback from real users. Launch imperfect, prototyped versions of your product to understand what users want and where challenges lie, and be prepared to respond quickly with experimental solutions. In-house teams can be particularly nimble in this cycle of iteration. Tools like JSON schemas can support this kind of rapid and responsive iteration. “Tech schema is going to be one of your main limiting factors to what you can do, so connect with other teams to talk about what to use,” Talbot advised.

Ground iteration in metrics that help drive toward that shared vision. Iteration is most effective and efficient when you have a clear, well-defined framework to measure and evaluate the success of the iterations and experiments your team undertakes.

Resources and artifacts

To see how this work was put into practice, explore the following assets: