In previous posts, I’ve suggested some best practices that could be required as the state modernizes its information technology. In this post, I’d like to highlight the best practices recommended by the Code for America team. They are trustworthy and relevant.

I'll start by apologizing to the Code for America folks. I am going to spin these practices to address issues I see in government IT. I do not expect that this spin will be too different than the original intent. I hope not … but my spin might be different from how you spin.

The first CfA practice suggests Data-Driven Decision Making: “Use real-time data to inform decisions. Set key metrics to determine whether programs and services are regularly meeting objectives and analyze the data to gain insights and drive actions that help improve community outcomes.”

There are lots of ways to interpret this, but I would like to tie it to modern software engineering in a geeky way.

One of the Twelve Factors in the Twelve-Factor Application manifesto I continually refer to requires software (the Twelve-Factor App) to treat logs as event streams. The underlying concept is that every “event” that occurs in your application should be logged. These events include business events like the approval of a benefit or the enrollment of a new member. This relates back to the CfA best practice by building in the generation of data to drive decision-making. Note that these log files are also the source of data to automate operational decisions and automating operational decisions is what DevOps is all about.

I believe that every new software development approved by state overseers whether at the division, department, agency, or above should be required to develop applications that adhere to the Twelve-Factor App manifesto to ensure that every new application generates the data to allow this CfA best practice to be followed. Exceptions to this rule may be granted if there is explicit and approved justification.

The next practice requires User-Centered Design: “Start with people’s needs. Begin projects by conducting research with real people to understand who they are, what they need, and how they behave. Design programs and services around those needs, continuously test with users and refine policy and processes accordingly.”

If there were only one best practice, this would be it.

I might edit this a little to say: Start with the right people’s needs. In this series of posts, I return again and again to the idea that you need a real product owner who uses the application you are working on every day. In the case of Child Welfare Digital Services, these are county employees. In the case of the DMV, these are field office staff or the public. If you follow user-centered design but you do not have the real user engaged, then you will miss the mark. If you think that having a handful of subject-matter experts embedded in the project as proxies for the actual user works, you may miss the mark.

The second part of this practice around designing to user needs — testing and refining — is what agile methods are all about. Agile continuously tests with users after each sprint. In waterfall, continuous user testing is possible but not natural to the technique.

Every new project should have a product owner assigned that comes from the actual end-user community. In other words, every project needs to be organized from the beginning to ensure proper product ownership to ensure effective user-centered design. User-centered design is not only a geeky method for developers. It is something that needs to be baked into the fabric and organization of every project.

I’ll end this post with the next CfA practice suggesting Community Engagement: “'For the people, by the people' takes on whole new meaning in the digital world. Why not use the tools we have at our fingertips to make it easy for everyone to have a say in decisions that impact them?”

The obvious thought is to connect this to the idea of user-centered design. I imagine the Code for America folks want much more here.

We can imagine a user interface for DMV processes that directly engages the public even if we understand that sometimes DMV field office staff will use the interface on behalf of a citizen. We can imagine that field office personnel know what the public wants from their constant experience in dealing with them. But the community of users who need to buy in includes the public.

The community of users who need to buy in to a child welfare system includes not only the county field personnel who will often use the application directly; it also consists of the public who will sit across from the county workers. It includes the non-governmental agencies who support the adoption process.

Community Engagement has two aspects: to get input from the community that makes the result better, and to get support from the community and therefore acceptance of the end result. In my opinion, state staff should be required to include some effort to engage a broad community as part of every project. This broad community should always include the public when state staff are face-to-face with them, even if the application user interface is never touched by the public.

Next week I’ll share the last four Code for America practices. They are powerful, and state overseers would do well to find a way to include these in the review process before any new project is funded.

Rob Klopp describes himself as "a full stack executive with knowledge from business applications down to the bare metal. Experienced in executive management, finance, sales, marketing, and product with a bias towards innovative product strategies. Built new organizations from scratch, transformed very large old organizations, and provided technological thought-leadership over a 35-year career." He blogs at