Building better digital products in government through an agile and iterative approach
My personal experience working with different processes at the Canada Energy Regulator, and the challenges I ran into along the way.
What goes into the process of building a digital product or service in the public sector?
Processes can vary depending on the team, project, and organization, but at the Canada Energy Regulator teams are trying to move towards an agile approach. This method allows for close knit collaboration so that teams can iteratively launch new products and features.
Different barriers and blockers within the government can impede our best attempts to continuously improve our products. From policy-level challenges to legacy issues, budgets and the way teams are structured, I will go over my last few project experiences when it comes to working in agile.
Code for Canada Fellowship
I first worked in government as part of the Code for Canada Fellowship. My team was comprised of a developer, a product manager, and a designer. We were tasked with improving the digital participation process for people that wanted to get their voices heard on federally regulated energy projects. The redesign successfully launched this year, but it was met with some challenges.
My team followed the fellowship process model at the time. This model has both benefits and tradeoffs. For example, a longer research process that includes collaborating with impacted communities builds trust and transparency. Involving my team in the research and user testing process allowed them to empathize with the challenges participants go through. This led them to become more aware of the user needs within their own processes and made them major advocates for creating the best experience.
At the beginning of the fellowship, my team tried to set up two-week sprints, but we quickly realized it did not work as we intended.
When working in sprints, the design needs to be two steps ahead of development. Hitting the ground running was difficult when we had to start from level one. There was not a lot of existing data to inform our work and documentation was difficult to find.
It took time to find people to conduct user interviews with, analyze the results and turn them into actionable requirements. Some of these dependencies pushed back the design and development timeline.
My team was also stuck on the wrong solution for some time despite knowing what the ideal direction could be. Initially, I designed user flows to work around the constraints of government web-login standards. However, policy-level decisions had to be made before we could implement our best solution. This issue was eventually brought up to our stakeholders, and a decision was made in favour of our proposed idea.
Another challenge my team had was that we did not have any internal developers with us at the start of the project due to resourcing constraints. We were eventually able to get those resources during design hand-off, but this process made launching more stressful.
Legacy constraints also made it impossible for our team to launch iteratively without impacting the overall system.
Partway through this project, my team transferred all our user stories from a paper format to Axure DevOps. This was a move to help ease communication and allowed for better documentation.
All the factors listed above prevented our team from truly being agile for this project.
Canada Energy Regulator — Applications Dashboard
Applications Dashboard is a separate project I worked on this year at the Canada Energy Regulator. It was created to help hearing participants understand what they need to do at each part of the process.
Phase 1
In the first phase of the project, the team worked on creating a timeline for the hearing process. I joined part way through to support the design on the mobile side and start on new features. At that time, there was no formal system used to keep track of our sprints and tasks.
Phase 2
In this phase, my team ran two-week sprints on Axure DevOps over the course of three months. Our team is made up of one project manager, one product manager, five developers, two business analysts and two designers.
Below is the general breakdown of our process.
Pre-sprint prep
Before the start of every sprint, the whole team gives advice on what will go into the coming sprint and create a rough story estimation. The product manager will prioritize what work needs to be done in each sprint. I will review the backlog of user stories with my product manager to get aligned on the work I will be doing in the next two weeks. From there, I will estimate the story points for each user story. Story points help quantify the level of effort it would take to create a feature. In this case, we use the Fibonacci scale.
Once the user stories are agreed upon, I will break them into smaller tasks and estimate the number of hours it will take to complete it. If there is too much work for within one sprint, user stories can be moved into the next one.
During the sprint — from a design lens
Within each sprint, my team has 15-minute daily standups where we provide updates to go over the things that we are working on for the day and discuss any blockers.
During the design process, I typically produce a few different iterations before reviewing my work with other designers. Sometimes I will co-collaborate or host a mini workshop to generate design ideas.
My team and I try to conduct user testing or interviews to get feedback for each feature we create. In addition, we are in the process of getting automated feedback through surveys and Google analytics.
Throughout the design process, I try to have on-going and open communication with the developers.
I will typically meet with the developers to go over the selected concept(s) and answer any questions they may have. This helps catch edge cases early on and reduce any questions down the line. If I am showing various design options, I also get development time estimations to support the decision-making process. Other stakeholders may be consulted as well.
Once the designs are finalized and ready, I will meet with the developers to hand off the work.
When a feature is completed and within the testing environment, I will review the work for any design discrepancies and provide feedback. If I spot a bug, I will add it as a task and tag one of our developers. As soon as a bug is fixed, two people will check it to make sure it is done correctly.
Working with multiple languages and content
We also translate all our information into French on an ongoing basis. Formal processes have not been fully established but are in the works. Below is an example of how to structure the process for smaller French translations.
Our team does not have any copywriters, so the business analysts work on policy related content. This is reviewed by someone from the communication teams. Sometimes I will also work on copywriting for smaller batch content.
Managing urgent changes and changes in priority
Sometimes things will come up that will cause me to reprioritize my work. For example, I was working on a visualization feature for the timeline, but due to a change request from our business stakeholders, this feature was moved to the backlog and replaced by a search engine feature.
When it comes to urgent feature level changes, product managers will often prioritize and assess the needs to be made before a release. This decision is usually based on several factors such as risk assessment, effort versus value, severity of usability issues, etc.
Release windows
For smaller features, we try to have a mini release after two to three sprints, depending on if the user stories are completed. Shorter release windows work well when we have minor updates to make. All other larger features or functionalities get shipped at the end of each phase.
Evolving features and changing user needs
Sometimes after getting feedback from our users, a feature needs to be further iterated on to provide a better experience. One of our studies highlighted a lack of affordance in the timeline. There was no indication to the users that they could interact with the timeline, so a new user story was created for the following sprint.
Other studies provided insights that required minor design changes related to an existing user story, in which case, I would add another task under that story. If a feature is out of scope, it will be added to the backlog.
Benefits of a 2-week sprint
Having structured 2-week sprints helped our team work more efficiently when it came to feature delivery. Iterating and testing within our sprints made it faster to identify areas we need to improve on rather than waiting until after things are developed. It also allowed for better communication and helped us deliver within the timeline we set out.
End of each phase
We usually end each phase with a retrospective on what we learned, what went well, what did not go well and what we will carry forward. This helps us improve our process for the following phases. One example of that is incorporating a standardized French translation process so that developers can access them in one place. Another learning we had early on was to not sugarcoat or understate project risks. It is important to communicate them urgently and clearly to stakeholders.
After a phase is completed, we also celebrate with a launch party, where the team bonds over games, drinks, and other fun activities.
Getting buy-in from team members
Digital transformation is a huge focus within the Canada Energy Regulator. It means modernizing existing processes to be more adaptive to the needs of our users. There is interest from across the organization to move towards a human-centered approach through the products we create. Getting team buy-in for new processes can look like providing resources or guidance during the transition phase.
For example, when I was working as a designer under Code for Canada, we transitioned from a paper-based process to Axure DevOps. There was a learning curve, but with enough support from my product manager, our team was able to get acquainted quickly.
On the other hand, adapting to new processes may mean restructuring how existing teams work together. This was a major move made by the leadership team recently.
When I first started working at Canada Energy Regulator, developers were put into teams on a project-to-project basis. Resourcing was hard to come by and general team goals were not always aligned. In my current project, designers and developers are integrated into the team from day one and will stay throughout the entire project lifecycle. We are also starting to see more people understand the value of design and ask for designers within their team (YAY for small wins).
In both projects, there were small bumps along the way when it came to adapting to new processes and software. Both teams were able to successfully adopt more efficient internal processes because everyone in the organization is open and committed to change.
Beyond that, getting buy-in from team members takes time to build up. It looks like bringing people to the table. Whether it is encouraging non-designers to come to your design critique sessions or hosting a workshop on how team members envision the organization’s hybrid work model to be. These methods can all create support and buy-in from people, which will have a lasting impact on the projects they work on.
Thanks for reading this far. If you are also designing products in the public sector, I would love to learn about your processes! What are some of your challenges? What success have you seen?
