Most government software stinks. Here’s what you can do about it.

In the last week alone, I’ve booked a dental appointment via text, tracked a package online during its cross-country journey to my doorstep and ordered dinner delivered from my favorite locally owned deli through an app.

The pace at which our technology simplifies and makes unremarkable what previously took multiple calls, appointments and trips around town is mind blowing. And yet we quickly adapt to these changes, taking them for granted, even. That’s because these apps are fast, reliable and provide such a seamless user experience that we are more likely to notice when they don’t work than when they do. 

The primary differentiator between a seamless user experience and a clunky one is whether or not a company has put resources into improving that very thing: user experience, or UX. Software companies with UX designers track details like how many clicks it takes to perform an action, the placement of dropdown menus, the design of in-app messaging and how one process integrates with other technologies in a workflow.

Yet, when it comes to the software state and local government employees rely on every day to get their jobs done, it’s increasingly apparent that there hasn’t been a priority placed on improving the experience for the end user. The list of issues requiring efficiency-sapping extra steps and workarounds can range from the mundane and annoying to major roadblocks like clunky user interfaces and painfully slow load ties to manual workarounds in place of easy integrations. These issues all waste time, frustrate users and hamper agencies’ ability to deliver on their missions.

According to a survey of our customer user base, 100% of respondents said that the software they use on the job requires manual workarounds or switching between systems to complete common tasks. Only 14% believed government leaders prioritize an excellent user experience for the technology that they buy.

How did it get this bad and what can be done about it? Here are three primary reasons government software stinks. By understanding these reasons and why they occur, agency leaders can start to consider how transformative software can increase efficiency, job satisfaction and constituent service. 

Lowest Price, Technically Acceptable

Lowest price, technically acceptable, or LPTA, is a government purchasing philosophy that’s been around for a long time. LPTA purchasing requires a bid to meet the minimum technical requirements at the lowest price. Yet, by definition, this means from the very start the buyer is already compromising on the final product by accepting a subpar experience. 

Typically, the rationale behind LPTA isn't just to save budget, but that LPTA is seen as the “safest” approach with the lowest risk of protest from a losing contractor, even if it doesn't produce the best outcomes (and often produces downright terrible ones).

“Technically acceptable” generally includes functional or regulatory compliance requirements set by agency personnel who often don’t actually use the software in question. It would be more effective for agency decision-makers to focus on user experience requirements such as ease of integration with existing systems, efficiencies gained through automation and the portals the public has become accustomed to using for self-service—the things that most directly impact those using the software. 

By focusing on UX and not LPTA, agencies can better ensure their systems align to their end users’ day-to-day processes, tasks and needs, ultimately enabling increased productivity while more than making up for any marginal cost differences. 

Limited Motivation to innovate

Often government leadership views the lowest risk option as not making a change in the first place. That’s partly because implementing new technology is rarely painless for state and local governments. Change starts with a complex purchase process and then requires installing new systems, testing them, teaching workers how to use them, then troubleshooting any issues. The long road of implementation, training and adoption is a huge reason why legacy software and processes somehow limp on, even when the workflows clearly are falling short of expectations for service delivery.

Leadership risk aversion completely disincentivizes innovation in companies that serve the government market. Government tech companies know the people making the buying decisions aren’t necessarily clamoring for something new and better. Large software vendors have become accustomed to the fact that there are rarely any meaningful repercussions for offering a subpar user experience with poor support, since the likelihood of their customers switching remains relatively low. 

Keeping legacy software in place well past its prime also makes it harder to attract top talent, especially younger employees who may evaluate a job based in part by the type of support and tools they receive. According to a recent survey by Dell Technologies, 80% of Gen Z employees say that technology would influence their job choice. 

Maintaining legacy software for too long and making younger workers feel like they're using outdated tools can further hamper their productivity and motivation. Many state and local governments are already struggling to attract entry-level, Gen-Z talent, despite it being the fastest growing group in the workforce. Touting state-of-the-art technology tools will only grow in importance for recruiters in the years ahead. 

But there is another way: built-for-government, commercial-off-the-shelf applications that are designed and developed to serve government use cases. These solutions, delivered by teams who have installed the software and conducted staff trainings many times before, make implementations fast and predictable.

Asking the Right Questions 

Here are four basic, but important, questions technology buyers should ask that can help ensure their agency gets the solutions it needs.

• Is the application designed for state and local government? Software originally designed for government is more likely to include the specific out-of-the-box processes, workflows and reports agencies need to get up and running fast, with minimal additional customizations or tweaks. In addition, companies that build for the public sector often use a government-centric innovation process, meaning they are designed around government end-users’ voice and requirements from the very beginning. At the end of the day, agencies want a software experience that’s been designed for their needs and accounts for critical security standards, such as cloud security certification from StateRAMP. 

• What type of support is the agency entitled to receive and is there a direct line of communication after implementation? Agency buyers should be sure to understand the type of support included with their purchase. Traditional commercial tech support is usually insufficient for government users who frequently want the ability to make business-oriented “how to” inquiries or have questions about specific government processes. In addition, it’s important to make sure IT managers are comfortable with the process for support, including the specific point of contact and the preferred ways to communicate and resolve any issues—before any purchase. If the agency or the software provider employed a third-party consultant to install and configure new software, will the vendor be able to support the team’s ongoing support and service needs?

• Who is going to be using this software? Too often, purchasing decisions are made by senior leadership who don’t use the software being replaced on a daily basis. It’s important to include end users in product evaluations and make them a critical part of the decision-making process. End-user teams should be offered multiple opportunities to demo the software, ask questions and provide their thoughts. Do they feel it will meet their needs?  Does the user experience allow for greater daily efficiency? Does it empower them to deliver on their tasks more seamlessly?

• Are other agencies with similar regulatory compliance needs using the software? Ask around. Have colleagues at other agencies or institutions heard of the software? Have they had positive experiences? Do they think the vendor understands their specific compliance and regulation issues? How easy has it been to adopt the software? Is it intuitive by design and less clunky for their specific government use case?  Does it require going outside the system to spreadsheets and other documents for workarounds that can introduce inefficiencies and increase the potential for errors?

Why should government workers have to settle for technology user experiences that are outdated by decades or more in their work lives when they would never accept them in their private lives? Especially when that work is done in support of taxpayers and their critical needs. 

It’s time to demand more of the technology our government and institutions use every day. By selecting software that’s designed with the specific needs of state and local government in mind, agencies can empower end users to do their work more efficiently and, in turn, spend more time focusing on their mission, not their technology.