Don’t Compromise Between Internal and External Users

Increasingly, government service providers and technologists are embracing human-centered design principles and using frameworks that prioritize the users’ needs and instincts. These principles are evident in the new Boston.gov, launched in 2016, with, among other design elements, a reorganization of information by constituent-oriented topics, rather than by City department.

But besides serving as a resource for information, local governments are also responsible for facilitating transactions, ranging from the simple (volunteer sign-ups) to the complex (cross departmental permits and licenses). While the ‘constituent user’ is far from one-dimensional, in designing transactional processes, digital service providers must accommodate the “internal user” as distinct user group.

How do we balance the needs of the constituent user with the internal user? My role in Boston’s Department of Innovation and Technology includes project management and business analysis in service of designing some of these digital applications and workflows. In practice, I have seen it argued that the two user groups have opposing interests, and that one must be prioritized at the expense of the other. I believe this to be a false dichotomy, and that one of the ways we can avoid compromising one of these end user groups is with low-code development platforms.

While customer service culture typically depends on an inverse relationship between the work expected of a constituent– or customer– vs that of staff, tools for government should be designed under the principle that a greater ease of use for government employees translates to greater clarity and consistency for the constituent. When the staff that own the business process have mastery over the technology that facilitates it, you have a staff that can rapidly respond to individual requests, evolving constituent needs and policy priorities, without relying on a central IT team of developers, administrators, or help desk support.

Furthermore, one of the most meaningful advantages of a low-code application tool is that it promotes adoption across business owners. Tools that require heavy programming often require that low-tech front-line staff entrust their business processes to centralized IT staff or project-based consultants. By introducing degrees of separation between the people who do the work and the people who build tools to facilitate that work, you open yourself up to the risk that the configuration doesn’t align well, or that post-implementation support structures fail to keep up with evolving needs. Besides disempowering internal users, you end up sowing distrust, causing under use or misuse of the technology, and, most importantly, failing to improve service delivery.

This is one of the objectives we’re pursuing in Boston with a procurement for a forms and workflow technology solution currently under way. We have an existing set of enterprise application tools that we use to meet the needs of some of our more complex processes. But with scores of forms and associated workflows ranging from low to medium complexity that remain paper-based, we are exploring low-code tools that enable rapid configuration and deployment, and allow us to empower our end users with a greater degree of administrative control.

What are your experiences and lessons learned when it comes to balancing the needs of the constituent user and end user? What do you do to drive adoption and ownership of new technologies among customer-facing departments?

Susanna Ronalds-Hannon is part of the GovLoop Featured Contributor program, where we feature articles by government voices from all across the country (and world!). To see more Featured Contributor posts, click here.