I saw this article on LinkedIn this week concerning the Time magazine article (Code Red) about the saving of healthcare.gov and one of the major items for me was the quote:

“Looking at the highlights of what we have [accomplished], it is notable that delivery of services, whether they be information or transactional, has come before final strategy work is completed. Or put more simply, in an analogue world, policy dictates to delivery, but in a digital world, delivery informs policy. This is what agile means for Government and its services, and if delivered in this way, the ramifications are profound.”

This suggested an Agile methodology approach to governing by all levels of government can be a game-changer to the delivery of public services. The agile approach assumes to be incremental and responsive to continual user feedback.  This means an adjustment of the actual product features as we adapt to the needs of the target user role. Use cases need to be adjusted, user interfaces adapted, and support and documentation aligned.   As the article points out, this is at odds with the traditional, and often current, waterfall approach to service design. The “build it and they will come” approach overlooks a lot of variables that cannot be easily tested in a QA environment, such as the “too many are coming” scalability problem faced by healthcare.gov.

I very much sympathize with the original team that built healthcare.gov where there did not seem to be a single entity that decided what would be delivered in phase 1.  With many stakeholders all dictating their requirements concurrently, you inevitably will have conflicting requirements.  And without a final pragmatic design authority, the design team will attempt to satisfy everyone – and hence often no one.

This team must of felt like I have at times when we had our corporate attorneys involved in the product user interface.  Naturally when you are an attorney your primary job is to be concerned about the protection and liability of the corporation and, secondly, the end user experience. Everyone pretty well knows that few people read the fine print when trying to do something on the web – so including legalese on the business part of a web design is thankless.   I knew, just like the healthcare policy makers, that our attorneys just wanted to make sure that the service was in line with the government’s/corporation’s legal policy. We addressed this directly by giving them a full page where they outlined all the legal issues and then provided links to it at various points in the UI design.  In this way, the legal information was fully covered but did not distract from the actual service.

I am a fan of a transparent and activist government that provides responsive services. This is the only approach that can address the increasing requirements we expect of our governments. Manual processes get stuck in often intentional generalized policies while a public web service has to be very specific in its uses. The agile process of delivering public services enforces specifically defined use cases extracted from the policy makers – and if done well, will have the support of the general public to keep incrementally adding to those use cases.