playbook.cio.govThe Digital Services Playbook — from the U.S. Digital Service

Digital Services Playbook 1 2 3 4 5 6 7 8 9 10 11 12 13 Digital Services Playbook The American people expect to interact with government through digital channels such as websites, email, and mobile applications. By building digital services that meet their needs, we can make the delivery of our policy and programs more effective. Today, too many of our digital services projects do not work well, are delivered late, or are over budget. To increase the success rate of these projects, the U.S. Government needs a new approach. We created a playbook of 13 key plays” drawn from successful practices from the private sector and government that, if followed together, will help government build effective digital services. See the plays Help improve this content Digital Service Plays Understand what people need Address the whole experience, from start to finish Make it simple and intuitive Build the service using agile and iterative practices Structure budgets and contracts to support delivery Assign one leader and hold that person accountable Bring in experienced teams Choose a modern technology stack Deploy in a flexible hosting environment Automate testing and deployments Manage security and privacy through reusable processes Use data to drive decisions Default to open In detail PLAY 1 Understand what people need We must begin digital projects by exploring and pinpointing the needs of the people who will use the service, and the ways the service will fit into their lives. Whether the users are members of the public or government employees, policy makers must include real people in their design process from the beginning. The needs of people — not constraints of government structures or silos — should inform technical and design decisions. We need to continually test the products we build with real people to keep us honest about what is important. Checklist Early in the project, spend time with current and prospective users of the service Use a range of qualitative and quantitative research methods to determine people’s goals, needs, and behaviors; be thoughtful about the time spent Test prototypes of solutions with real people, in the field if possible Document the findings er goals, needs, behaviors, and preferences Share findings with the team and agency leadership Create a prioritized list of tasks the user is trying to accomplish, also known as user stories” As the digital service is being built, regularly test it with potential users to ensure it meets people’s needs Key Questions Who are your primary users? What user needs will this service address? Why does the user want or need this service? Which people will have the most difficulty with the service? Which research methods were used? What were the key findings? How were the findings documented? Where can future team members access the documentation? How often are you testing with real people? PLAY 2 Address the whole experience, from start to finish We need to understand the different ways people will interact with our services, including the actions they take online, through a mobile application, on a phone, or in person. Every encounter — whether it’s online or offline — should move the user closer towards their goal. Checklist Understand the different points at which people will interact with the service – both online and in person Identify pain points in the current way users interact with the service, and prioritize these according to user needs Design the digital parts of the service so that they are integrated with the offline touch points people use to interact with the service Develop metrics that will measure how well the service is meeting user needs at each step of the service Key Questions What are the different ways (both online and offline) that people currently accomplish the task the digital service is designed to help with? Where are user pain points in the current way people accomplish the task? Where does this specific project fit into the larger way people currently obtain the service being offered? What metrics will best indicate how well the service is working for its users? PLAY 3 Make it simple and intuitive Using a government service shouldn’t be stressful, confusing, or daunting. It’s our job to build services that are simple and intuitive enough that users succeed the first time, unaided. Checklist Use a simple and flexible design style guide for the service. Use the U.S. Web Design System as a default Use the design style guide consistently for related digital services Give users clear information about where they are in each step of the process Follow accessibility best practices to ensure all people can use the service Provide users with a way to exit and return later to complete the process Use language that is familiar to the user and easy to understand Use language and design consistently throughout the service, including online and offline touch points Key Questions What primary tasks are the user trying to accomplish? Is the language as plain and universal as possible? What languages is your service offered in? If a user needs help while using the service, how do they go about getting it? How does the service’s design visually relate to other government services? PLAY 4 Build the service using agile and iterative practices We should use an incremental, fast-paced style of software development to reduce the risk of failure. We want to get working software into users’ hands as early as possible to give the design and development team opportunities to adjust based on user feedback about the service. A critical capability is being able to automatically test and deploy the service so that new features can be added often and be put into production easily. Checklist Ship a functioning minimum viable product” (MVP) that solves a core user need as soon as possible, no longer than three months from the beginning of the project, using a beta” or test” period if needed Run usability tests frequently to see how well the service works and identify improvements that should be made Ensure the individuals building the service communicate closely using techniques such as launch meetings, strategy rooms, daily standups, and team chat tools Keep delivery teams small and focused; limit organizational layers that separate these teams from the business owners Release features and improvements multiple times each month Create a prioritized list of features and bugs, also known as the feature backlog” and bug backlog” Use a source code version control system Give the entire project team access to the issue tracker and version control system Use code reviews to ensure quality Key Questions How long did it take to ship the MVP? If it hasn’t shipped yet, when will it? How long does it take for a production deployment? How many days or weeks are in each iteration/sprint? Which version control system is being used? How are bugs tracked and tickets issued? What tool is used? How is the feature backlog managed? What tool is used? How often do you review and reprioritize the feature and bug backlog? How do you collect user feedback during development? How is that feedback used to improve the service? At each stage of usability testing, which gaps were identified in addressing user needs? PLAY 5 Structure budgets and contracts to support delivery To improve our chances of success when contracting out development work, we need to work with experienced budgeting and contracting officers. In cases where we use third parties to help build a service, a well-defined contract can facilitate good development practices like conducting a research and prototyping phase, refining product requirements as the service is built, evaluating open source alternatives, ensuring frequent delivery milestones, and allowing the flexibility to purchase cloud computing resources. The TechFAR Handbook provides a detailed explanation of the flexibilities in the Federal Acquisition Regulation (FAR) that can help agencies...