Building digital services using agile, user-centred methods

Teams building public-facing digital services must use agile, user-centred methods to meet Digital Service Standard #2.

This means:

• your team is set up to work in an agile manner;
• you have a plan to design and develop digital services using agile methods; and
• you plan for frequent iterations and prioritize improvements that will improve the user experience.This is to ensure there are multiple opportunities to conduct user research and iterate to continuously improve the user experience.

Teams should avoid taking a waterfall approach or to focus only on meeting business needs.

Planning your project

Start small

Rather than embarking on one giant, enterprise solution – start small. It’s easy to jump to a procurement that will solve every business and user need your team has identified. But these projects take much longer to make it through the UX Assessment and Service Compliance Checks. If one part doesn’t pass – none of the rest will.

Start small. Pick one service, learn as you go, iterate and you’ll be able to launch a digital service that works for the end user. You can then take everything that you’ve learned and apply it to other services you want to modernize. Teams that take this approach are more successful, launch their services as planned and they’ve caught and addressed usability issues before people tried to use the live service.

Touch base with eServices for assistance determining what platform to use

eServices has common platform components they manage that align with the government’s Digital Service Standards. Check in with them if you’re planning to build a public-facing digital service. They will help you determine which platform you should use or if you might need to go to procurement.

Working with vendors to design and build digital services

Project teams must include the requirement to use agile, user-centred methods in the vendor scope of work. It is important they understand we do not want to take a waterfall approach. Our expectation is a plan that includes time and budget for multiple rounds of review, testing and iteration. Most projects need at least two windows of time per environment to conduct testing with the public and within their team. This can look something like this for each environment.

• Demo from vendor
• Team/user/eServices testing and feedback
• Vendor makes the required changes
• Team/user/eServices re-test and provide feedback
• Vendor makes the required changes
• Team approves

Working together as a team

Project team communication

Project teams may opt to work in sprints or at the very least they should have regular meetings and check ins.

The team should make use of tools for collaboration and communication. Senior management should be present for decision-making or empower a member of the team to take on that role. For example – making the final decision on prioritizing requirements.

If the senior manager is not available for all meetings you should have a process in place to keep them up-to-date on the team’s progress.

Process for prioritizing features and the product backlog

The team’s process and criteria for prioritizing features for the MVP and product backlog should be user-centred. This means focusing on designing and building parts of a digital service that help users complete the task and deprioritizing features that do not have validated user needs. 

You have tools in place to track issues, user feedback, bug reports and support tickets.

Training

In most cases there should be a plan in place to make sure non-technical staff can configure the service and manage content on their own.

Approvals

Teams should make sure they have a plan in place to get department approvals required to launch the service. This could be a formal process, show and tells or demos.