Digital Service Handbook
Understand people and their needs
Whether your users are private citizens or government employees, you must include real people in your design process from the beginning — and throughout the lifecycle of your service. Understand the needs of the people who will use your service. Do research to develop a deep understanding of who those people are, how they behave, and what that means for the design of your service.
Key questions to answer
- Who are your primary users?
- What are they trying to do, and how do they currently do that?
- What problems or frustrations do they experience?
- What do your users need from your service to achieve their goals?
How to meet this standard
You’ll engage users for research and feedback throughout the Digital Delivery lifecycle. At a minimum,
- Explain the user needs your service addresses and how you found those needs during Research and Discovery
- Give examples of user goals, user personas, or user profiles for the service
- List the user stories for the service
- Explain how you tested the service with real users and what you learned — identify the parts users found difficult and explain how you’ve changed the service to make those parts easier for users and how you tested and researched to confirm this
- Explain how you will continuously monitor and improve the service, including how often you plan to research and test the service and your plans for incorporating changes to address user problems
Establish the right team
Put in place a multidisciplinary team that can design, build, and continuously improve the digital service. The team should be led by a Product Manager who is accountable for the service and has the authority to make decisions about the service.
Build your team around a skilled Product Manager empowered to make decisions based on the outcomes of research, testing, prototypes, and performance metrics. This is not the same role as the Project Manager, whose primary task is to keep team members accountable to the agile delivery process.
How to meet this standard
Your team should include these roles.
Work in the open
When you build and launch a service (or a feature) on the Veteran-facing Services Platform, the front-end code will be visible to anyone visiting the GitHub repository. This helps other teams inside VA (or other government agencies) who may want to reuse the software you’ve built.
When you first begin work on your service for the Veteran-facing Services Platform, you’ll be given access to the “Product” repository on GitHub (visible to people within the VA organization). We encourage you to publish as much of your product, research, and design work as possible in this repository.
By working in the open on GitHub, you can
- See what other Veteran-facing Services Platform teams are working on
- Ask other Veteran-facing Services Platform teams for comments or feedback on your designs or code
- Accept code contributions from people on other Veteran-facing Services Platform teams
- Reuse documents and design materials produced by other Veteran-facing Services Platform teams
How to meet this standard
At a minimum,
- Publish code to the Veteran-facing Services Platform GitHub repository
- Use GitHub Issues (or another agile project management tool) to track team tasks so they’re visible to the whole team
- Publish your team’s product, research, and design materials in the GitHub “Product” repository
Design the whole experience, from start to finish
Although your service is designed as a digital experience, it probably exists in the context of a larger goal your users want to achieve. For example, Veterans applying for disability compensation first need to obtain certain documents that may require telephone calls or filling out paper forms.
Understand the complete end-to-end journey that users take to complete their goal, including the actions they take online, on a phone, or in person. Every encounter — whether it’s online or offline — is part of the user experience and should move users closer to their goals.
How to meet this standard
Your understanding of the end-to-end experience will evolve over time as you design and build your service. At a minimum,
- Explain the end-to-end steps that users take to achieve their goals and how your service is integrated into that context
- Show a journey map of all the touch points in the user’s experience of your service, from learning about the service to understanding how to cancel or stop using the service
- Describe your support plan, including the “help” content within your service and how users can request additional help via phone or in-person
- Create prototypes that demonstrate the end-to-end experience
- Explain how often you’ll do research and testing for each stage of the Digital Delivery lifecycle and how the results will be used
- Describe the results of research and usability testing and how the results will be used to improve the service
- Explain any problems found during testing, as well as your proposed solutions
Help people reach their goal the first time
Your service should be so simple that your users — including those with accessibility needs or who lack digital experience — can succeed on their very first attempt without the need for any assistance.
If your service is complex or challenging to use, your users will need to contact your agency for help via phone or an in-person visit. Or they may stop using your service altogether. This leads to user frustration and lack of confidence in your agency, as well as higher operational costs.
How to meet this standard
At a minimum,
- Make sure that the service explains who it is for, how it works, and how to use it — make this content visible without requiring users to sign in
- Include contact information so users can learn more about the service and get help using it
- Demonstrate that the majority of users succeed the first time they try to use the service
- Explain how often you’ll use research, testing, and analysis of analytics to make regular improvements to the service
- Test that the end-to-end experience works for all users, including those with impairments
- Make the service accessible, including for users with limited digital skills
- Do usability testing at least once before the service goes live, and prioritize making improvements to the service
- Make design and content decisions based on user research, testing, and analytics
- Use performance analytics to identify areas where users are unable to complete their tasks and prioritize fixes for these
Make the user experience consistent
The user experience of your service must be consistent with other services your agency provides. Using existing interaction design patterns, visual style, and editorial style means
- You can save time by reusing existing patterns and code (which have been refined over time based on user research and data)
- Your users will be more confident they can use your service because of its similarity to the other Veteran-facing Services Platform tools they already use
How to meet this standard
At a minimum,
- Reuse components from Formation, VA.gov’s design system
- Follow the Veteran-facing Services Platform Content guide for writing copy for your service
- Make sure your service is responsive and works on mobile devices
Design for accessibility
Accessibility is about making sure your service can be used by as many people as possible. Thinking about this from the beginning will help you make sure that nobody is excluded.
When we talk about designing for accessibility, we’re not just talking about designing for people with disabilities. We mean designing for people in the widest variety of real-life circumstances.
All users will have different needs at different times and in different circumstances. For example, a person’s ability to use your service can be affected by their:
- Health - they may be recovering from a stroke or traumatic brain injury, or they may have a broken arm and be unable to use their mouse
- Location - they may be in a noisy cafe or an area with slow wifi
- Equipment - they may be on a mobile phone or using an older browser
- Digital experience - they may need phone (or in-person) assistance while using your service
Before you design or build anything, think about how these users will access and use your service.
How to meet this standard
At a minimum,
- Seek a wide variety of users for research and testing, including people with disabilities, other impairments, and those with limited digital experience
- Reuse components from Formation, VA.gov’s design system (which have already been tested for Section 508 compliance)
- Use Formation’s color palette and typography (which have already been tested for Section 508 compliance)
- Test your service using the simplified process for VA Section 508 compliance (which involves automated tools for testing Section 508 compliance, in addition to periodic manual testing)
Embed privacy and security by design
Typically users won’t use a service unless they know it’s secure, confidential, and their privacy is protected while they use the service (and after they stop using it).
How to meet this standard
At a minimum,
- Identify the data the service will collect, use, store, create, and/or update
- Describe how the data is being transmitted and stored
- Explain how long the data is kept, how it will be used, and how it may be shared
- Put in place appropriate legal, privacy, and security measures
Be agile and user-centered
Build and release your service using agile delivery practices. Agile practices allow teams to break their work into small chunks (iterations) and release these every day (sometimes multiple times per day).
This means your service gets into the hands of your users — and you can collect their feedback — much faster than using waterfall delivery methods. For example, you could release a new feature, collect feedback from users, make improvements, and release that feature again in just a few weeks (or days).
How to meet this standard
At a minimum,
- Explain how your team works in an agile way, using agile tools and techniques, and how you’ll continue to do so when the service is live
- Describe design options for prototypes and explain why some were discarded
- Give examples how your team has responded to user research and usability testing
- Identify any problems found in research and describe the solutions to improve the service
- Show how the design of the service has changed over time because of user research findings
- Have a quality assurance testing and rollback plan that supports frequent iterations to the service
- Apply the same iterative approach to evolving the way your team works together
Test the end-to-end service
Continuously test the end-to-end service in an environment identical to that of the live version. Doing this helps you find problems before you launch a live version, which means you’re more likely to release something that works for your users.
How to meet this standard
At a minimum,
- Design your service so it accommodates the expected number of users and can support more users if demand increases
- Separate content, design, and functionality so updates can be made independently of each other
- Follow recommended best practices for coding in your chosen tools
- Test the service in the staging environment using the required automated testing tools
- Follow the process for frequently monitoring and testing your service, even when changes are not being made
- Follow the process for managing failures (bugs, outages) and how to notify users
- Follow the process for data storage and recovery in case of data loss
- Document how your service was built and how to maintain it, and keep the documentation up-to-date
Measure performance and iterate frequently
Use analytics, alongside user research and testing, to evaluate the performance of your service. Use this information to analyze the success of your service and turn that analysis into user stories and features for the next phase of development.
Your service should be adaptable so it can respond both to changes in policies that affect the service and to changing needs of your users. Design and build your service so it can be improved on a frequent basis, and make sure that you have the capacity, resources, and technical flexibility to do so.
How to meet this standard
At a minimum,
- Define the metrics you’ll use to evaluate your service and the tools you’ll use to do that
- Use Google Analytics to capture information about how users interact with your service
- Monitor and evaluate user feedback about your service from other touch-points like Help Desk phone calls or in-person visits
- Show how you’ve used qualitative and quantitative data to improve your understanding of user needs and to identify areas for improvement
- Explain what you’ve built in each phase of the Digital Delivery lifecycle and why you built it
- Demonstrate your team has the ability to deploy software frequently with minimal disruption to users
Encourage people to use your service
Encourage people to choose your digital service over non-digital touch points. This will
- Save money by reducing the number of people who use non-digital touch points such as the Help Desk
- Allow non-digital channels to focus their attention on people who are unable to use digital services on their own
- Help Users develop their digital skills and understand your agency as a modern government agency
How to meet this standard
At a minimum,
- Understand how different touch points meet the needs of users trying to complete a task that is part of your service
- Design your service so that it has clear advantages over other touch points, for example, saves time over submitting a paper form
- Have a plan to increase the number of people who use your digital service
- Identify the organizations and groups that help Veterans complete VA-related tasks, and ask them to support your service
In writing these Digital Standards, we sought inspiration from the experiences and expertise of several government teams. In particular, we were inspired by USDS, Gov.uk, Ontario Digital Service, and 18F.