What do government regulations and mobile apps have in common? On the surface, they might appear completely unrelated, but like your favorite app or tech product, regulations shape your behavior and work patterns and are intended to create value for society. If you accept this analogy, the federal government, with over 3,853 new rules passed in 2016 alone, is an extraordinarily prolific product developer.
While federal regulations imposed an estimated $1.9 trillion in costs on the economy in 2016 (that’s nearly thirty-five times the value of smartphones sold in the U.S. last year), the existing rule making process falls short of the best practices used to design products like your mobile device. To encourage a more effective approach, Argive chatted with several Silicon Valley product designers for tips on designing rules that work. We outline key steps in the design process and how they can advance regulatory policy goals.
Regulators should spend time with stakeholders in the regulated community to observe their behavior and understand their needs. According to Justine Li, a product manager at Gigster, developing user empathy is critically important in designing good products, and she goes to great lengths to get this information:
I was working on the v2 product roadmap when I realized that I didn’t know anything about how truckers actually do their jobs, and I couldn’t find quality information by simply reading trucker forums and blogs. To rectify my knowledge gap, I did a 4-day user testing road trip through West Virginia with a trucker named Saint. We used the beta app on the road and from there I was able to map out trucker-specific features like whether gas stations have CAT scales to weigh their load when they cross state lines, whether or not there are clearance limitations, etc.”
The creators of Cornell’s Regulation Room tool, an online platform for federal agencies to solicit public feedback on proposed rules, also emphasized the importance of engaging a broad range of users in the regulatory design process. For example, they were able to dramatically reframe a Department of Transportation rule on disability access by engaging ‘missing stakeholders’ who had not previously participated in the rulemaking process:
“Disability rights organizations emphatically supported DOT’s plan to require redesign of automated check-in kiosks. Some individual travelers with disabilities, however, disagreed that focusing on accessible technology best served their needs. Explaining their own problems navigating the airport environment, they preferred additional human assistance, and worried that requirements for accessible machines would result in fewer customer service personnel.” (Source)
The Regulation Room example demonstrates why engaging individuals with direct situational knowledge, and not just organizations claiming to represent them, is critical to smart rule design.
After conducting user observations, agencies should craft a problem statement from the user’s perspective. According to Justine, simplicity is key: “We write user stories to build shared understanding across all stakeholders. Everyone from business execs to developers should be able to interpret how a feature is intended to function, and develop a shared empathy for the end user. User stories purposely exclude technical jargon.” Regulatory "problem statements" should always be written in an accessible language - one that can be easily understood by a diverse range of people.
The regulatory problem statements in federal notices of proposed rulemakings (NPRM’s) should be greatly simplified to improve accessibility. The Regulation Room creators note in their “Rulemaking 2.0 Guide”: “The current recommendation for readability level of materials intended for use by the public is the 8th grade level. By contrast, all the NPRMs we have worked with on Regulation Room have scored at the late-college/early graduate school level.” By writing regulations in plain language, agencies can lower the barrier to participation and facilitate constructive public feedback.
Agencies should collaborate with partners in the public and private sector to uncover innovative regulatory solutions in response to the problem statement and meet policy goals. For example, agency leadership could invite individuals across their department as well as consumers, workers, and business managers to join brainstorming sessions. Insights from the Regulation Room experiment revealed that active agency facilitation is necessary to ensure participants have enough context to generate relevant ideas. For example, in the Air Travel Accessibility rulemaking, Department of Transportation moderators actively responded to citizen comments to solicit more specific policy proposals.
Prototype and Test
After agencies have prepared several versions or “prototypes” of a rule, they need to test these ideas with the expectation that many will not work. According to Caroline Crandall, a designer and Summer Fellow at IDEO, "Prototypes are not precious, they are made to be broken. They teach us what's missing, what we assumed, what isn't working about a particular idea --- quickly.”
If prototyping a product in a real-life situation is too risky, such as in healthcare, designers test the product in analogous situations. “Prototyping a way for nurses to access tools in a hospital is tricky because there could be real danger in disrupting a high-risk work environment. Another path is to look at systems where people need to access tools, like school libraries or shared machine shops, and prototype in those," Caroline told us.
Before passing a rule that will affect thousands of workplaces and hundreds of millions of dollars in economic activity, regulators should invite private sector firms to test the rule “prototypes.” For example, factories could temporarily implement a new rule and provide feedback on the rule’s effectiveness and cost. A third party auditor could validate rule viability by tracking key outcome metrics, like total workplace injuries. For complex and costly rules, agencies could include testing budgets and a longer timeframe for evaluating success. This test data provides agencies with evidence to validate internal assumptions about regulatory costs, effectiveness, and “usability” prior to finalizing a rule.
Iterate and Refine
As a rule of thumb in product design and development, products are never done. They are designed to be flexible and adaptive to evolving environments and user needs. Similarly, as social and environmental issues evolve, existing regulations must be reevaluated and readjusted for optimum effectiveness.
Product developers rely on a technique called continuous delivery to enable new features, bug fixes, and experiments to be pushed to production and into the hands of end users. These same concepts can be applied to regulatory development, which would require a streamlined, standardized process for gathering feedback, running tests, and analyzing results to find areas of improvement.
In recent years, federal policy experts have called for “prospective retrospective review” that would lay the foundation for a continuous delivery framework by requiring agencies to define rule outcomes and track performance over time. While this framework requires a higher investment in agency time and resources, the social and economic benefits of measuring rule effectiveness is undeniable. Conducting timely “product” evaluations could course-correct problematic rule design. After all, we would never use the same computer from 1970, why should we use the same rules?
This brief introduction proposes how regulatory agencies could borrow best practice product design framework to improve rule efficiency. For more information on the design thinking process, the Stanford Design School offers excellent free online educational resources. For government and advocacy groups interested in engaging and observing citizen preferences, Argive offers free technical resources to facilitate a public dialogue on regulation.
Special thanks to guest contributors Justine Li and Caroline Crandall for providing expert opinion for this piece!
Image Source: Link