Bad Technology or Bureaucratic Red Tape? Why Citizens Don't Trust Digital Government Services
Governments continue to invest heavily in digital platforms, yet citizen trust and adoption can remain difficult to secure. The instinct is to treat this as a technology problem: fix the interface, add more features, run another awareness campaign. But according to Alana María Ali, a Trinidad and Tobago-based digital government and trade facilitation advisor, and Nicole Greene, a GovTech communication strategist and digital public infrastructure (DPI) advisor from Trinidad and Tobago, treating low adoption as a technology problem alone overlooks other important causes.
Asked directly what frustrates citizens more — bad technology or bad bureaucracy — Ali and Greene approached the question from different angles but arrived at a similar conclusion. Greene's framing: digitizing a broken process without changing it doesn't transform anything, it just makes the frustration portable. Ali's version: technology can be fixed, but a broken process just gets faster. Citizens still hit the same wall, only sooner.
That distinction — between digitizing a process and actually redesigning it — runs through the rest of the conversation, and it reframes what "citizen trust" actually depends on.
Why government digital services struggle to meet citizen expectations
One of Nicole Greene's central points is that citizens do not evaluate a government platform against other government platforms. They evaluate it against the best digital experience they have had recently, and that experience is very often from the private sector. Someone who is entirely comfortable navigating complex digital services elsewhere can still walk away from a government platform disappointed, simply because it does not meet the standard they have already internalized.
She argues this creates a specific obligation for the state: designing for inclusion, not just designing for the digitally confident user. The people who need government services span very different levels of comfort, access and trust, and a platform built around a narrow, tech-savvy persona risks excluding some of the audiences who need it most.
Which government services struggle most with adoption — and why
Ali and Greene pointed to different but related patterns in where adoption breaks down.
Ali's observation is that social benefit and welfare platforms — services like grant applications or social assistance programs — tend to be the ones where design quality is most often overlooked. Her reasoning is that these services are meant to serve people at the lowest socioeconomic strata, and the investment in understanding how that specific user group will actually interact with a system often does not match the investment that goes into services aimed at more digitally literate audiences, such as a business registry.
Greene's example works from the citizen's side of the same problem: some services face resistance not because they are complicated, but because the perceived cost of making a mistake on a system the citizen does not fully trust feels higher than the cost of standing in line in person. In some cases, she noted, this gap is wide enough that citizens will pay someone else to queue on their behalf rather than use the digital option themselves.
How to design digital government services for the hardest user
Alana María Ali's core design principle is to build for the hardest user, not the average one. In her framing, the hardest user is typically someone with low connectivity, low digital literacy and low trust in government — and she is explicit that comfort with consumer apps does not equal digital literacy. Being fluent in scrolling social media, in her words, does not mean someone can confidently navigate a government application form.
She connects this to a second principle: reliability before features. In her experience sitting through platform design discussions, teams are often eager to add sophisticated functionality — her example is a feature that could transpose a handwritten document into digital text — before the core system is stable. Her argument is that citizens will forgive a simple, even basic system, but they will not forgive losing their data or being timed out mid-application and having to start over. Every feature added before the core is stable, in her view, is a liability rather than an improvement.
A related, more specific problem she raises is the experience of silence during an application process. Citizens interacting face-to-face with an officer can ask in real time what happens next and when to expect a result. Many digital systems don't replicate that reassurance — a citizen submits an application and receives only a confirmation number, with no clear next step. That silence, in her account, is often what sends people back to a physical office rather than trusting the process online.
Ali illustrated the value of designing around actual behavior, rather than an idealized user, with Rwanda's national services platform, IremboGov. Her point was not about the platform's specific technology, but about what the country got right before building it: understanding that Rwandan citizens were already transacting through mobile money and interacting with services through basic mobile phones, using short numeric codes rather than typing. According to her, the platform was designed to work within that existing behavior rather than requiring citizens to adapt to an unfamiliar interaction model.
Communication is not the last mile of digital transformation — it's the foundation
Nicole Greene's argument is that communication failures are usually design failures that surface later. Her first point is that many teams build around two or three typical user personas and consider that sufficient — without accounting for the institutional
stakeholders, community leaders and informal "ambassadors" who need to understand and support a platform before citizens ever see it. If ministries connected to a service don't understand how it fits into the wider digital strategy, or if there is no one on the ground able to explain and defend the platform in spaces the implementing team can't reach, adoption suffers regardless of how well the platform itself works.
Her second point is about how governments read the aftermath of a launch. In her view, a quiet launch — no complaints, no visible pushback — is often mistaken for success. She argues this can be a red flag: every community that wasn't reached, every question that went unanswered, leaves what she calls an information vacuum, and if the state doesn't fill it, misinformation will.
Her third point concerns what happens when trust visibly breaks down — she referenced examples such as contact-tracing apps, digital ID rollouts and health platforms, without naming specific programs or countries. Her observation is that the common institutional reflex is to respond with more promotional communication: more ads, more messaging, more voices repeating the same reassurance. In her assessment, this doesn't work, because a trust deficit can't be resolved by broadcasting louder. She argues the more effective response is to step back from official messaging and let trusted, independent voices — technologists, community leaders, professionals who have tested the system — speak publicly about the platform and openly criticize it. In her view, criticism can be an opportunity to improve and better align with stakeholder needs.
Her broader claim is that strategic communication should not be treated as the final stage of a digital transformation project, layered on right before launch. In her framing, it deserves the same rigor as the technical build, from the earliest stages of design.
Why launching a digital service is only the beginning
Both speakers returned repeatedly to what happens after a platform goes live, not just what happens on launch day.
Ali described this as one of the most commonly overlooked parts of large national projects: a clear plan for who handles problems once the system is in production. Her questions were specific — who answers when something breaks, who is accountable when a citizen hits an error mid-application, and what the feedback loop looks like between frontline staff encountering these issues and the product team responsible for fixing them. This is the context for her summary line: the platform itself is not the product — the sustained, functioning service around it is.
She gives a project-level example from her own experience working on Saint Lucia's digiGov platform, the Government of Saint Lucia's integrated e-services portal. During early design discussions, her technical team initially built toward a "one checkout per application" model. She recalls pushing back, arguing that Caribbean users often think in terms of a single household transaction — for example, a family may need to renew passports and obtain several updated birth certificates rather than submitting separate applications for each family member. According to her account, roughly three months after launch, a change request added a shopping-cart-style checkout allowing multiple applications to be submitted and paid for in a single transaction.
Greene offered a comparable example from Trinidad and Tobago's online driving permit renewal system. At launch, the system covered a deliberately narrow use case: renewal only, for specific vehicle classes, excluding anyone who needed a name change or medical documentation. Her account of the previous process — long waits at licensing offices, informal businesses that had grown up around helping people queue and complete paperwork — was offered as context for why even a limited digital option represented a meaningful improvement, both for the citizens who used it directly and for the reduced congestion it created for everyone still using the physical office.
She recalls public skepticism at the outset — doubts about whether the system would actually work reliably or deliver on time. What changed that sentiment, in her account, was that the system performed as promised, which led citizens to start recommending it to others who fit the eligible criteria, effectively becoming informal advocates for the platform. She noted that the state agency has continued developing the service and adding more eligible classes rather than treating the initial rollout as finished — another example, in her account, of the importance of continued development after launch.
Common mistakes governments make when launching digital services
Drawing the two speakers' points together, several recurring failure patterns emerge — not as a formal checklist from the episode, but as themes both guests kept returning to from different directions:
Underestimating who actually needs to be engaged before launch. Greene's argument is that teams often stop at end-user personas and miss the ministries, legislators and community figures who influence whether a platform gets adopted or actively resisted.
Treating silence as validation. A quiet launch is not necessarily a successful one — it may simply mean feedback isn't reaching the team that needs it.
Responding to distrust with more messaging rather than more listening. In Greene's view, when adoption is already faltering, adding volume to official communication tends to reinforce the distance between citizens and the platform rather than closing it.
Underinvesting in users with low digital confidence and low trust in government. Ali repeatedly emphasizes that services aimed at these users often receive insufficient attention to design, making adoption and use more difficult.
Treating launch as the finish line. The digiGov and Trinidad and Tobago driving permit examples both point to a broader theme in the discussion: launch is not the end of the work, and services continue to evolve once citizens begin using them.
What this means for governments building the next digital service
Neither guest suggested there is a formula that removes the risk of a rocky launch. Instead, their arguments point toward a shift in where effort and attention are placed: less on presenting a polished platform on day one, more on the structure around it — who is responsible when it breaks, how feedback moves through the system, and who has been brought into the conversation before the system goes live rather than after.
One of Ali's key points captures the throughline of her argument: governments need to treat digital platforms as services that require ongoing ownership, support and improvement, not as one-time technology deliveries. Her phrase for it was direct — the platform is not the product, the sustained functioning service is — built on her points about ownership, reliability and support after launch.
Greene's argument complements that idea. Strategic communication should not be treated as the last mile of digital transformation — it is the foundation and deserves the same rigor as the code.
Watch the full Code the State episode
This article draws on Bad Technology or Bureaucratic Red Tape?, an episode from Code the State's Women in GovTech series, hosted by Helen Uvarenko with guests Alana María Ali and Nicole Greene. Listen to the full conversation for the complete discussion.
