Beyond the pitch deck—Apply user research throughout project lifecycles

Research is learning things; design is creating the plans for things to be built.

Civic technologists seek to improve the relationship between the public and government institutions, using digital technology to modernize public services.

The typical problem—outdated legacy government systems / technical debt—is amplified by budget limitations and the lack of a shared vocabulary / mental model for service-delivery success.

Civic technologist leader Merici Vinton explains how technical debt spreads (my emphasis added):

The lack of throughline connecting practitioners across organizations—in government, the private sector, and civil society—means there are not shared career pathways, methods of completing the work, or expectations for outputs.

[This] means it’s incredibly inefficient—people joining expecting one job, discovering one wildly different; agencies, also often immature in their own digital delivery, have no reliable patterns or expectations when partnering; and ultimately no shared vision for what good product development and delivery looks like.

In short, there are ways forward, but there’s a lack of consensus.

As publications like Route Fifty have noted, state and local leaders have been striving “to build effective and sustainable teams amid different and evolving budgetary, political, and operational contexts.” These teams benefit from diversification: a multidisciplinary approach that includes but isn’t limited to experts in policy; administration and program management; technology / IT development; and user experience (UX) and design.

While competing constraints and sudden surprises exist from project to project, a collaborative, agile team—1 with various capabilities and focused knowledge—can help document and drive replicable success. Every project will contain its own nuances, but every agency can start with better options on the path to continuous improvement.

I spoke with Colin, user researcher at Mighty Acorn Digital, to learn more.

Integrating user research into human-centered design

Human-centered design is more than a discovery phase

Colin advocated for human-centered design (HCD) early on in our conversation. Given that Section508.gov and WCAG both integrate HCD / user-centered design methodologies in their respective best practices, early adoption and holistic HCD inclusion are helpful starting points. HCD benefits from applying takeaways gained from continuous feedback loops. Ongoing user research and testing can surface insights learned from constituents over time.

Considering constraints throughout the lifecycle of a project is important, but so is avoiding over-focusing on them. Constraints can distract from creating a UX embedded with HCD. When we don’t lead with the needs of the end user / constituent, we introduce more project risk (such as the delivery delays inevitable in rework).

When user research is treated as a 1-off for pitch decks or overview presentations, Colin said, these findings rarely shape day-to-day delivery, distribution, and access. He emphasized that human-centered thinking isn’t an add-on:

It shapes how problems are defined, how scope is set, and how success is measured.
It requires structures for ongoing engagement with users, not just a research sprint.

Continually address and include constituent perspectives

Colin identified a starting distinction—“Research is learning things; design is creating the plans for things to be built.” These are interconnected processes that require knowledge acquisition and application. During research, user patterns can be found. Designers can understand those patterns and develop interfaces that feel intuitive to users. User analysis can deepen with consideration from multiple perspectives, more easily gained with an interdisciplinary project team.

Increasingly, state and local governments are forming digital service teams with multidisciplinary skills, such as policy, administration, UX, engineering, and operations. Colin has found that successful teams try to keep constituents’ voices present in every iteration, not solely at project kickoff. In an HCD mindset, agencies aren’t the only primary stakeholders—constituents are too. Teams can use agile practices to iterate, delivering in small increments, learning, and adjusting.

User research should inform delivery, distribution, and access

Know your user and how to best serve your user, Colin said. User findings should influence how teams structure information (e.g., phone menus). They should also influence how teams distribute services across channels (such as web, phone, and chat). Another key factor in HCD-focused UX: ensuring it’s easy for constituents with different abilities and circumstances to complete tasks as intended. Colin noted that continuous engagement with HCD guides how delivery, distribution, and access feel for the people who are depending on government services.

Building feedback loops into digital service teams

Use quantitative and qualitative data as twin feedback feeds

Colin and I also discussed 2 feedback feeds—quantitative and qualitative—and why both matter. While quantitative data answers what and how (examples: clicks, submissions, call volumes, and chatbot scores), qualitative data answers why (examples: interviews, field studies, feedback forms, desk research, and journey mapping). Colin asserted that HCD depends on both. Quantitative loops (such as dashboards and analytics) provide ongoing signals about usage and friction. Meanwhile, qualitative research provides the context needed to interpret those signals and design meaningful changes.

In Colin’s experience on various projects, digital service teams can set up feedback loops to help teams maintain continuous improvement. Quantitative monitoring can be a permanent feedback source. Teams can also schedule and budget for recurring qualitative work—such as user interviews and usability tests—especially when metrics raise questions.

Turn research findings into shared infrastructure across the team

A shared communication and documentation system has proved useful to Colin in these highly collaborative UX projects. His team members use his findings to make shared decisions that involve input from product, design, engineering, and operations. Because constituents’ needs, policies, and technology continue to change over time, Colin notes that a design that worked last year may not work now. He has found that continuous loops help teams identify those shifts early and adjust content, workflows, and access paths.

On a current project, he did a lot of desk research on the history of the services and audiences using them; that research is still being discussed and applied. The team recently discussed a recommendation feature for phone menus. A user speaks into the phone to ask the bot a question; the bot replies with an answer. The project’s quantitative data shows where calls drop or where bots fail to answer confidently. Any future qualitative insights, in this case about cognitive load and memory (e.g., difficulty choosing from long lists of options), could help shape the number and wording of recommendations.

Watch for common failure modes

What can happen, I asked Colin, when user research is used in a pitch deck and then forgotten? He identified a couple common patterns to avoid.

Failure mode 1: Research only informs the roadmap.

In-depth research is reduced to a few bullet points for slide digestibility.
Those bullets help set direction, but the detailed understanding of constituents isn’t internalized by project managers, developers, and designers.
Result: The project team makes several decisions without user context, eroding the benefits from initial research.

Failure mode 2: Application of findings is blocked by constraints, then quietly dropped.

Example: Research shows a website fails on phones, but teams feel locked into legacy platforms and do nothing.
Over time, this builds technical debt and entrenches inequitable access.
When research is used only to win approvals or market a good story, constituents’ voices are effectively silenced during the implementation.

Making user research sustainable for state and local agencies

Preserve findings through shared artifacts and team rituals

Colin shared the following ways to maintain continuous engagement with HCD and research findings:

Shared artifacts—Share research reports, journey maps, and user narratives shared across project management, engineering, design, and policy—not just leadership.
Ongoing communication—Hold regular team discussions where user evidence is part of trade-off decisions (e.g., how many options a phone bot should present).
Embedding research in rituals—Include user stories in sprint planning and retrospectives; review key findings when new features or policies are proposed.

Design feedback loops agencies can operate after vendors leave

Colin also advocated for building sustainable feedback loops for agencies, not just consultancies. Knowledge sharing is important to us as a consultancy: we want organizations to continue succeeding after our project contract ends.

There will be challenges and complications to long-term implementation—formulate a plan while vendor or partner help is available. Continuous feedback is new for many agencies; find a comparable model of success and use it to create an agency-specific plan. As Colin observed, the higher the effort required (such as manual exports and ad hoc analysis), the less likely teams are to maintain it.

AI integration and automation are emerging options that can help teams lower effort without losing HCD. Civic-tech vendors like our partner Bloom Works have published principles for using AI in ways that support, rather than replace, HCD. Where appropriate, AI-assisted synthesis can summarize themes from unstructured feedback, under human review and judgment. Colin also encouraged using simple workflows for collecting qualitative feedback, such as short surveys, periodic interviews, and frontline staff debriefs. The goal is still HCD and iterative improvement; technology exists to make it easier for teams to keep listening and adjusting.

Practice HCD under real-world constraints

At Mighty Acorn, we work to understand the constraints of state and local governments while also keeping projects rooted in HCD. Centering the constituent or end user means driving from prioritization, not perfection.

An agency may have limited staff and budget, competing compliance requirements, legacy systems, and various levels of cross-agency coordination. UX is 1 priority, and teams can’t implement every finding immediately. Simultaneously, there will be evidence (metrics and user feedback) available when trade-offs are made that affect UX.

Colin encouraged a stance of advocacy plus pragmatism: HCD and UX practitioners can advocate for user needs as strongly as possible. They should also recognize and overtly state when technical or legal constraints are real, and document those tensions—as well as ways forward or around—for future modernization efforts.

It seems fitting to close with an assertion from Merici Vinton: “Technology and excellent user outcomes must be viewed as a strategic imperative at the highest levels, not an afterthought left to a silo within [an] organization.” Civic tech aims to address the technical debt and reputational damage of older systems that met requirements but failed people. In this field, we’re working to re-center and re-prioritize digital government by the people—especially built for the people.