Over the past few years there has been a significant increase in the federal government’s demand for human-centered design (HCD) services in conjunction with software development and delivery. Organizations like USDS and 18F, CIO’s from private industry, and HCD-savvy government employees have all advocated for a more human-centered design approach to serve the government’s constituents and employees.
The result of this growing advocacy is an increase in demand for human-centered design services. Currently, the primary means of procuring human-centered design is limited to a program/project level. As a general example, when an RFP is released for creating a new web property, it is increasingly common for the RFP to include language that requires some level of human-centered design capability as part of the delivery solution. While this is a significant step forward from a few years ago when relatively few RFP’s included such language, it has created new issues for the government.
By procuring HCD services in a program-specific manner, the government isn’t taking full advantage of the benefits an HCD approach offers. When HCD is applied on a per-program basis, it can create silos of varying experiences for the users of those products. It is common for a user’s journey to take them across several programs to accomplish a task (or series of tasks) to receive services from the government. When those programs are designed in different ways, that user’s journey can be disrupted, or worse, derailed altogether.
One way to ensure a user-centered approach for multiple programs is to create a Human-centered Design Center of Excellence (HCD CoE) that organizationally resides among several programs, possibly in the office of the CIO, CTO, or other non-program specific, service-providing office. By positioning HCD activities at this level, several positive things can occur:
- The HCD CoE can help shape procurements by conducting user research, and in some cases, execute a design sprint (or sprint zero), for a given product pre-RFP. The research can take the form of persona creation, journey mapping, qualitative and quantitative research, and synthesis of existing research and metrics. All of these items can be included as artifacts in an RFP, during a challenge, or at an industry day. This allows the bidding teams to propose more informed solutions since they will have the benefit of knowing the results of initial user research activities. It also allows the government to include user requirements into the RFP/challenge at the same time as technical and business requirements. When an RFP includes both user research and a technical solution in the same bid, it is not uncommon for the technical solution to drive the outcome based on its capabilities and limitations. A better approach is to have the user needs, as defined by research, dictate the appropriate technology.
- The HCD CoE can provide multi-program design governance. As a centralized team, the CoE can create and govern a common style guide for the programs over which it has purview. This can mitigate the risk of poor multi-program experiences for users who interact with those programs. This is especially important for agencies who have not adopted the USDS Web Design Standards, or who have chosen to only partially adopt them. It is important for agencies and programs to maintain their own identity, so modification of the web standards is perfectly acceptable as long as it is done in a deliberate, consistent manner that honors the intent of the standards.
- As a cost savings measure, the CoE can manage shared design assets and research findings. Instead of each program conducting its own research and creating design assets in a silo, the CoE can apply the “do once, use many times” model that is a known benefit of shared services. Chances are good that there are common personas, design elements, and research findings that can be applied to many related programs, and the CoE would be responsible for gaining the efficiencies of centralization and reducing redundant work. Additional cost savings can be realized through early research that validates user stories/features, ensuring that only the functionality deemed necessary or desirable by users themselves is implemented from the outset.
As a point of clarification, it is important to stress that this HCD CoE approach should not take the place of design and research being part of delivery teams and the ongoing agile process. Research and design absolutely need to be part of the agile process all the way through. In addition, the agile process needs to be free to build upon any initial work done by the CoE and alter the trajectory of its project based on iterative design and feedback. The CoE is intended to provide smart starting points for the agile teams to build upon, save money, and provide a governance structure that enables smooth multi-program experiences.
For questions or to discuss further, Keith can be reached at firstname.lastname@example.org