Monthly Archives: October 2025

Executive Summary

• Challenges in AI-Enabled Government Services: Designing AI systems for government case management involves high stakes and public trust. Past failures (e.g. welfare or benefits algorithms that harmed citizens) show the risks of moving too fast without safeguards. A human-centered approach is critical to avoid alienating users and exacerbating mistrust. This white paper outlines how human-centered design (HCD) principles can guide responsible AI integration in government services.

• AI and HCD Principles: We review how AI intersects with core HCD values – transparency (making AI decisions explainable), inclusion (addressing bias and diverse needs), privacy (protecting sensitive citizen data), trust (building user confidence through accountability), and usability (ensuring AI tools are accessible and intuitive). These principles must frame any AI project in the public sector.

• Integrating AI into Design Processes: Practical guidance is given for each design phase. In Discovery, AI can assist in analyzing public feedback or large datasets, but designers must ensure algorithms don’t introduce bias early on. In Ideation, generative AI can spark solutions, yet human insight must validate ideas against real user needs. During Prototyping, AI-driven tools (like adaptive UIs or simulators) enable rapid iteration, while continuous user feedback ensures usability. For Validation, AI can help test scenarios or accessibility, but human-centered metrics (e.g. user satisfaction, fairness outcomes) determine success.

• Using AI in Research Activities: We explore how AI can augment user research and policy analysis. Techniques include using natural language processing to synthesize qualitative data and cluster themes from open-ended survey responses or case logs. AI can assist in persona building by aggregating characteristics from data, though designers must inject empathy and avoid stereotyping. In opportunity mapping, analytics can reveal patterns (e.g. service gaps or at-risk populations) that inform strategic design decisions. Throughout, researchers should treat AI as a supporting tool for sense-making, not a replacement for human empathy and critical thinking.

• Case Studies and Design Patterns: Real-world examples illustrate pitfalls and best practices. A cautionary tale is Australia’s Robodebt system, which automated welfare debt decisions and caused public harm due to errors and lack of human oversight. The Netherlands’ benefits-fraud algorithm (SyRI) used proxies like nationality, resulting in discriminatory outcomes. These underscore design patterns to avoid – e.g. black-box algorithms without recourse. In contrast, agencies like the U.S. Patent Office successfully use AI to assist staff (speeding up patent classification) with humans still in control. Common design patterns for AI in case management include “human-in-the-loop” review for sensitive decisions, transparent explanations for AI outputs, and fail-safes like manual override and appeal processes. We provide pattern examples such as AI-driven triage tools that flag cases but defer final decisions to caseworkers, and chatbots that handle FAQs while escalating complex issues to humans – all aimed at augmenting staff rather than fully automating critical judgments.

• When Not to Use AI: Clear guidelines are given on the ethical boundaries of AI use. Designers should avoid using AI where it may violate rights or fairness, such as in decisions with serious repercussions (benefits denial, legal actions) without human review. If data is biased or poor quality, an AI system will likely perpetuate harm – sometimes the responsible choice is not to deploy AI at all. Proportionality is key: the use of AI should not exceed what is necessary to achieve legitimate aims. We outline red flags (e.g. when AI’s “black box” nature would erode transparency or if an AI tool cannot explain its reasoning) and emphasize always providing an opt-out or human alternative in public services.

• Frameworks and Toolkits for Responsible AI: The paper highlights frameworks and checklists to help teams evaluate and integrate AI responsibly. Google’s People + AI Guidebook offers best practices on when AI is appropriate, how to ensure user control and feedback, and how to handle AI errors gracefully. A 2025 guide from the Center for Democracy & Technology proposes an “AI Fit” assessment – a structured four-step framework asking agencies to identify the problem, consider non-AI solutions, evaluate data and risks, and document decisions transparently. We also reference design guidelines like Microsoft’s 18 human-AI interaction principles, which provide actionable advice (e.g. “Make clear what the system can do” and “Make clear how well it can do it” to set user expectations). Designers are encouraged to use such toolkits and checklists to ensure accountability, value alignment, fairness, and user benefit are built into AI solutions from the start.

• Metrics for Success, Trust, and Fairness: Traditional KPIs (like efficiency or user satisfaction) must be expanded to include trust and equity measures for AI systems. We discuss how to evaluate an AI-enabled service’s success in terms of public trust earned, quality of outcomes, and absence of biased impact. Practical methods include user surveys and observations to gauge calibrated trust (do users understand what the AI does and its limitations?). Fairness can be validated with metrics such as demographic parity (checking if outcomes are equally distributed across groups) and equalized odds (ensuring error rates are comparable across demographics). We emphasize continuous monitoring: agencies should audit AI decisions for disparities and employ techniques (like bias dashboards or third-party audits) to ensure the system maintains fairness over time. The white paper provides examples of metrics and tools (e.g. IBM’s AI Fairness 360 toolkit and NIST’s AI Risk Management Framework) that organizations can use to test for bias and track trustworthiness throughout the AI lifecycle.

• Future Directions and Designer’s Role: In conclusion, we look ahead at the evolving role of designers in AI governance. As governments adopt AI, designers must act as ethical guardians and user advocates on multidisciplinary teams. This means collaborating with data scientists, policy experts, and stakeholders to embed human-centric values into algorithmic systems. Designers will increasingly contribute to governance processes – from drafting ethical AI policies to conducting impact assessments and ensuring inclusive stakeholder participation in AI system design. The paper calls for a culture where human-centered designers are key decision-makers, ensuring that public-sector AI deployments are not only innovative but also transparent, fair, and aligned to the public interest.

Introduction: Challenges of AI-Enabled Design in Government

Government agencies worldwide are experimenting with artificial intelligence to improve public services. From automating routine tasks to analyzing large datasets for insights, AI promises increased efficiency and improved citizen experiences. In the U.S. federal government alone, over 700 AI use cases were identified in 2023, and that number more than doubled to 1,757 by 2024. Case management systems – which handle processes like social service applications, permits, investigations, and benefits administration – are seen as prime candidates for AI augmentation. The complex, paperwork-heavy workflows in case management could potentially be streamlined by AI for fraud detection, document classification, chatbot self-service, and predictive analytics to spot issues proactively.

However, designing AI-enabled systems in government comes with unique challenges and high stakes. Unlike commercial products, government services often involve vulnerable populations, legal rights, and public accountability. Mistakes can lead to serious harm – as seen in the high-profile failures of automated decision systems. For example, Australia’s “Robodebt” program in 2015 used an algorithm to detect welfare overpayments, but errors in the AI’s logic led to false debt notices, causing stress and hardship for thousands of citizens. In the Netherlands, a 2019 child benefits scandal involved an AI system (SyRI) intended to predict fraud; it flagged many innocent families (often of immigrant background) as high risk based on biased indicators, resulting in wrongful loss of benefits and even family separations. These cases underscore how well-intentioned AI can go awry in government contexts if human oversight and ethical safeguards are lacking.

A fundamental challenge is the public’s trust. Surveys show broad mistrust in AI systems across the political spectrum, fueled by concerns over bias, privacy, and lack of understanding. Government agencies cannot afford a “move fast and break things” ethos; a single mishandled AI deployment can erode citizens’ trust not only in technology but in the government itself. Thus, designers face a dual imperative: leverage AI’s benefits (speed, scale, pattern recognition) while preserving humane, transparent, and fair service delivery. In practice, this means AI should support government workers and citizens, not replace human judgment inappropriately or operate opaquely. As one Brookings analysis noted, efficiency gains from AI must be balanced against maintaining the “interpersonal communication” and empathy that people expect from public services. For instance, faster automated airport screening is useful, but passengers valued respectful treatment by staff even more.

Human-Centered Design (HCD) offers an approach to navigate these challenges. HCD focuses on deeply understanding user needs, iterating with feedback, and designing solutions that are usable, equitable, and aligned with human values. When applied to AI in government, HCD means putting people at the center of algorithmic systems – from affected citizens and front-line case workers to policy makers and other stakeholders. This white paper examines how human-centered designers can responsibly and effectively incorporate AI into their process. We will review key HCD principles (transparency, inclusion, privacy, trust, usability) in the AI context and provide practical guidance for integrating AI tools into design and research activities. We’ll also discuss real-world case management examples, patterns for success, and clear criteria for when not to use AI. The goal is to equip designers and decision-makers with knowledge and frameworks to harness AI’s potential for public good safely and ethically, avoiding pitfalls that undermine public trust or equity.

AI and Human-Centered Design: Key Principles

Human-centered design and artificial intelligence must be brought together with care. AI capabilities can enhance government services, but they must align with fundamental principles that protect users’ rights and wellbeing. Five interrelated principles – Transparency, Inclusion, Privacy, Trust, and Usability – should guide any AI project in the public sector. These echo widely accepted ethical AI guidelines (such as UNESCO’s AI ethics principles and various governmental AI frameworks) and map closely to human-centered design values. Below, we review each principle and how AI both challenges and can support them:

Transparency and Explainability

Transparency is a cornerstone of both HCD and responsible AI. In design, it means being open about how a service works. For AI systems, explainability – making the machine’s decision process understandable to humans – is critical. A human-centered AI should not be a mysterious “black box” that leaves users guessing why it made a determination. Transparent AI systems provide clear insight into their decision-making and allow users (or oversight bodies) to understand how outputs are generated. This is especially crucial in government case management, where decisions might affect someone’s benefits, eligibility, or legal status.

Designers should strive to implement AI features that can justify their recommendations in plain language. For example, if an AI tool flags a social service case as high-risk, the interface might show: “Flagged because prior similar cases with X, Y, Z factors had higher incidence of issue.” Such explanations help case workers and citizens comprehend the rationale, enabling informed action or appeals. Transparency builds trust: users are more likely to trust and accept AI-assisted decisions when they can see the reasoning. Conversely, opacity can breed suspicion or misuse. Human-centered designers must work with data scientists to ensure that at least a contextual explanation or relevant factors can be communicated for any automated recommendation. Techniques like model cards and decision flow diagrams can be integrated into the design to document how an algorithm works.

In practice, achieving transparency may involve trade-offs. Highly complex AI models (like deep neural networks) might be accurate but hard to interpret. Designers might opt for slightly simpler models or additional explanatory modules to ensure end-users are not left in the dark. Transparency is also about process: being open with the public that an AI is being used, what data feeds it, and how it’s evaluated for bias. Documentation and disclosure (for instance, publishing algorithmic impact assessments or user-friendly explainers) are part of a transparent design approach in government. Ultimately, transparency isn’t just a feature – it’s a governance strategy that enables accountability and user empowerment.

Inclusion and Fairness

Government services must serve all citizens equitably. Thus, inclusion and fairness are non-negotiable principles in designing AI systems. Inclusion in HCD means involving diverse users and considering a range of abilities, backgrounds, and contexts in design. In AI, it extends to mitigating bias in algorithms and ensuring outcomes do not disproportionately harm any group. AI systems are only as fair as the data and design choices behind them. Unfortunately, biases can creep in at many stages: biased or unrepresentative training data, flawed algorithms, or even how users interact with the system. Human-centered designers need to be vigilant in identifying and addressing these biases.

One aspect is diversity in data and testing. Designers should question whether the datasets powering an AI reflect the populations served. For example, if a case management AI is learning from historical case outcomes, are there historical biases (e.g. stricter scrutiny of certain neighborhoods or demographics) that could be perpetuated? Techniques like data audits and bias testing should be part of the design process. Fairness metrics provide a systematic way to check for disparities. Common metrics include Demographic Parity, which ensures people from different groups have similar probabilities of positive outcomes, and Equality of Odds, which requires that error rates (false positives/negatives) are balanced across groups. For instance, if an AI is used to predict which benefit applications might be fraudulent, equality of odds would mean it has similar false-alarm rates for all demographics, so one group isn’t unfairly targeted.

Inclusive design also means considering edge cases and vulnerable users. A responsible AI system should be tested with scenarios involving underrepresented groups to see if it performs consistently. Involving community representatives or civil rights experts in the design review can uncover fairness issues that a homogeneous team might miss. Additionally, inclusion covers accessibility: ensuring AI interfaces accommodate users with disabilities or those with lower tech literacy. For example, an AI chatbot for a government service must be usable by people with visual impairments (screen-reader compatible) and available in multiple languages to include non-native speakers.

Design patterns to promote fairness include “bias bounties” (inviting outsiders to find bias in the system), providing user feedback loops to report suspected discrimination, and implementing algorithmic audits as ongoing procedures. A key principle from UNESCO is that AI actors should promote social justice and not exacerbate discrimination, taking an inclusive approach so AI’s benefits are accessible to all. For designers, this translates to continuously asking: “Who might be negatively impacted by this AI? Whose perspective is missing?” and then adjusting design and data accordingly. By foregrounding inclusion, designers help ensure AI-enabled services uplift everyone, rather than reinforce existing inequities.

Privacy and Data Security

Privacy is paramount in government systems, which handle sensitive personal data (financial records, medical information, etc.). Any AI feature in case management will likely involve data – possibly aggregating or analyzing personal case files, correspondence, or behavioral patterns. Human-centered design mandates respect for user privacy and agency over their data. Ethically, citizens should not have to trade their dignity or security for algorithmic convenience.

Responsible AI design follows the principle of privacy by design. This means privacy considerations are baked in from the start, not an afterthought. Designers should collaborate with AI engineers to minimize data collection (only what’s necessary for the AI’s function) and to incorporate safeguards like encryption, anonymization, and role-based access control. For instance, if AI is used to summarize case notes or predict outcomes, perhaps it can work with de-identified data or on-premises, so that personal information isn’t exposed to third-party systems. Indeed, concerns about feeding government data into public AI models have led to approaches like using private AI models or on-site machine learning that keep data within agency firewalls. The design must communicate these safeguards to users, as transparency about data use builds trust.

Another aspect is user consent and control. In a human-centered approach, individuals should be informed when AI is used and have some control over their data. For example, if an AI assistant helps fill out forms by pulling data from various records, the interface should clearly ask permission and let the user review or edit information before submission. Providing options to opt out of AI-driven personalization or to purge one’s data are design considerations aligned with privacy rights and emerging regulations (like GDPR or state data protection laws).

Security overlaps with privacy: AI systems must be secure from breaches or manipulation. Designers might not handle the technical implementation of security, but they should ensure the user experience does not undermine it. This could mean avoiding overly broad data sharing between systems, or educating users (through UI cues or training) on how their data is protected. The recent trend toward “confidential AI” emphasizes using encrypted processing or federated learning to keep data safe while still leveraging AI insights.

In summary, a human-centered designer working with AI in government should champion strong privacy practices and help create clear privacy notices and controls in the user interface. The system should earn the right to use personal data by demonstrating responsibility and giving value back to the user (for example, saving them time) in a way that feels respectful. By doing so, designers uphold individuals’ rights and sustain the public’s trust that government will be a careful steward of their information.

Trust and Accountability

Trust is both an outcome of the above principles and a principle in itself guiding design decisions. In the context of AI, trustworthiness refers to the system’s ability to perform reliably, fairly, and transparently so that users can confidently rely on it. Building user trust is essential, because even a well-functioning AI is ineffective if people refuse to use it or actively circumvent it due to lack of confidence. To cultivate trust, AI systems must demonstrate accountability – meaning there are clear human responsibilities and fail-safes associated with the AI’s actions.

From a design perspective, trust is fostered by setting correct expectations and delivering on them. Users should understand what the AI can and cannot do. One practical guideline is to “Make clear what the system can do”and “Make clear how well it can do it” – advice from the Microsoft Human-AI Interaction Guidelines. For example, if a predictive model in a child welfare case management system flags at-risk cases, the UI might display a confidence level or past accuracy rate: “This prediction has about 80% accuracy based on historical testing”. Designers should convey the AI’s capabilities and limitations upfront, which helps users develop an appropriate (calibrated) level of trust. If users believe the AI is infallible when it isn’t, they may either over-rely and get burned by errors, or conversely, if they assume it’s worse than it is, they might ignore useful guidance. Calibrating trust means the user’s confidence in the AI aligns with the AI’s actual reliability.

Accountability mechanisms in design ensure that AI is not operating unchecked. Human-centered design for government AI often incorporates a human-in-the-loop. This could mean requiring human approval for certain AI-generated decisions (like before denying a service or flagging someone for investigation). It could also involve providing appeal channels – if a citizen thinks an AI-driven decision is wrong, the system should make it easy to request human review. Another example is logging and audit trails: the design might include an interface for administrators to see how the AI has been making decisions over time, which can be used for accountability reviews or public reporting. Such features align with calls for AI accountability and traceability in governance frameworks.

Moreover, trust is reinforced by continuous improvement and feedback loops. Users tend to trust systems that show they are listening and improving. Designers can implement features for users to give feedback on AI outputs (e.g. a caseworker marks an AI suggestion as useful or not). This not only helps refine the AI (if it’s designed to learn from feedback) but also signals to the user that the AI is accountable to them. Microsoft’s guidelines encourage, for instance, “Support efficient correction” (make it easy for users to fix AI errors) and “Encourage granular feedback”. By allowing users to correct or critique the AI, the system shows humility and invites partnership, which is key for trust.

In summary, designers should treat trust as a design goal: incorporate explainability, reliability, user control, and human oversight in the experience. And they should remember that trust is earned, not given. Pilots and user research should gauge trust levels – asking questions like “Do you understand why the AI suggested this?” and “Do you feel comfortable following the AI’s recommendation?”. If the answers are negative, it signals the design needs adjustment to be more transparent or to better align with users’ mental models. With diligent design and testing, AI systems can become trustworthy tools in government services, wherein users feel confident that while AI is present, people remain in charge and accountable.

Usability and Accessibility

No matter how advanced the AI, if the system is not usable, it will fail to deliver value. Usability entails that the system is easy to learn, efficient to use, and satisfying for the user. In HCD, this is a core objective – and it remains equally critical when AI is part of the mix. In fact, AI can introduce new usability challenges: non-deterministic behavior, complex settings, or outputs that are hard to interpret. A human-centered approach ensures AI features enhance the user experience rather than complicate it.

One key is to integrate AI seamlessly into existing workflows. Government caseworkers and staff have established processes; an AI tool should ideally slot in without causing disruption or confusion. During the design process, special attention is needed in the prototyping and testing stages to refine AI interactions. Rapid prototyping with iterative user feedback allows teams to identify usability issues early, such as an AI recommendation that might be presented at the wrong time or in a confusing manner. As noted in one HCAI (human-centered AI) resource, in prototyping and testing phases AI solutions are iteratively refined based on user feedback, emphasizing usability and accessibility. This might involve simplifying the interface, improving the clarity of AI-generated text, or adjusting how the AI asks for input.

Accessibility is another vital dimension – ensuring that people with different abilities can use the AI-driven service. This extends beyond meeting technical standards (like Section 508 compliance for IT systems) and into the realm of equitable user experience. For example, if a system uses a machine-learning model to classify and route citizen requests, the interface should not only be navigable via a screen reader, but the logic should also avoid disadvantaging those who can’t interact in certain ways. A voice-activated AI assistant for a government service must have an alternative input mode (text or button-based) for users who are deaf or hard of hearing, and vice versa for users with visual impairments. The inclusive design mantra applies: “design for the extremes, and the middle will benefit.” AI can even assist in accessibility – e.g., automated captioning or translation can help serve users with language barriers – but those features themselves need user-centered refinement to ensure accuracy and usefulness.

Designers should also keep AI user controls straightforward. If there are settings to adjust AI behavior (for instance, tuning how “aggressive” a fraud detection algorithm is, or choosing preferences on what an AI assistant can do), these should be presented in an understandable way. Many users are not AI experts, so avoid jargon like “confidence threshold at 0.8” – instead, use plain language (e.g., “Standard vs. Strict mode”) and tooltips or examples to explain. A guideline from research is to “Provide global controls” for AI behavior – meaning users should have a say in the AI’s role, such as turning a feature on/off or selecting different levels of automation. Global controls increase perceived usability because they let users tailor the experience to their comfort.

Lastly, error handling and fallback are critical to usability in AI systems. Because AI can and will be wrong at times, designers must plan for those moments. A robust design will ensure that if the AI fails (e.g., “I’m sorry, I couldn’t find that information”), the user isn’t left stranded. Either the system should gracefully degrade (perhaps offer to connect to a human agent), or provide suggestions to rephrase a query, etc. These safety nets maintain overall usability and user trust. The user should feel that the system is reliable in the sense that even when AI components fail, the overall service still helps them accomplish their task.

In summary, usability in AI means keeping the human front and center: AI features should reduce friction and cognitive load, not add to it. When AI is truly human-centered, users may barely notice the “AI” – they just see a smoother, smarter service. Achieving that requires rigorous user testing, inclusive design practices, and humility to simplify AI to fit human needs, rather than expecting humans to adapt to complex AI.

Integrating AI into the Design Process

Implementing AI in a human-centered way isn’t just about final principles – it’s about how we build and iterate these systems. The design process for case management solutions (or any service) typically goes through phases: Discovery, Ideation, Prototyping, and Validation (testing). In each of these stages, artificial intelligence can play a role, both as a tool to assist designers and as a target for design (i.e., designing the AI features themselves). Below, we break down how AI can be integrated responsibly at each step:

AI in the Discovery Phase (Research and Problem Definition)

The discovery phase is about understanding the context, user needs, and defining the problem. Designers engage in user research, gather data, and analyze insights. AI can supercharge this phase by helping to handle large volumes of information and revealing patterns that might not be immediately obvious. For example, in a government agency’s discovery phase, there may be thousands of citizen feedback comments, case files, or call center transcripts to review. Natural Language Processing (NLP) algorithms can summarize text or cluster common themes, giving designers a head start in identifying pain points or frequent issues. AI-based analysis can help in processing surveys or social media data to see public sentiment about a service.

However, using AI in discovery should be done thoughtfully. A designer might use an AI tool to perform initial text analysis on open-ended survey responses from caseworkers about their workflow challenges. The AI could cluster responses, showing perhaps that “difficulty in tracking case status” and “excessive paperwork” are dominant themes. While this is useful, designers must validate these findings through human analysis – reading sample responses or conducting follow-up interviews. AI might surface correlations (e.g., certain locations have higher backlog issues), but it doesn’t explain why – that requires human context and empathy. Triangulation of AI-derived insights with traditional qualitative research (interviews, field observations) is important to avoid misinterpreting data. Additionally, designers should watch for AI bias in research: if the data is skewed or the algorithm highlights sensational but less relevant patterns, the team might chase the wrong problem. Keeping diverse researchers in the loop and using AI as a supplement – not a replacement – ensures a grounded discovery phase.

AI can also assist in stakeholder mapping and needs finding. Some government agencies use network analysis tools (a form of AI) to see how information flows or which departments interact frequently, helping identify key stakeholders for workshops. Machine learning can predict which service components cause the most delays or errors by analyzing historical case processing data. These predictions can help designers prioritize areas to investigate further.

From a human-centered perspective, co-discovery with AI is emerging. This means involving users in reviewing AI findings. For instance, a design team could show caseworkers an AI-generated summary of their pain points and ask, “Does this reflect your experience? What’s missing or inaccurate?” This engages users early and checks the AI’s usefulness. Notably, an HCAI approach encourages involving users at all stages – even in interpreting research data. It keeps the process inclusive and ensures the problem framing is correct.

In summary, during Discovery, AI can be like a smart assistant that handles the heavy lifting of data crunching, allowing designers more time to synthesize and empathize. But designers must remain in the driver’s seat, critically analyzing AI output and combining it with human insight. This ensures the problems defined are real and meaningful, setting the stage for relevant solutions in later phases.

AI in Ideation (Concept Generation and Co-Creation)

Ideation is the creative phase where teams generate solution concepts. Here, AI can play two roles: aiding designers in creativity and being part of the brainstormed solutions (especially when aiming to leverage AI capabilities in the end product).

On the first role, there’s increasing exploration of AI as a creative partner. Generative AI models (like GPT-4 or image generation tools) can produce a myriad of ideas, sketches, or scenarios that spark human creativity. For example, a design team working on a case management interface might prompt a generative AI for “alternative ways to visualize a citizen’s case timeline” and get back several rough concepts to critique. Or they might use AI to generate hypothetical personas or future scenarios (“imagine a system that could automatically fill out all forms for a citizen – what would that look like?”). These AI outputs can break the blank-page syndrome and introduce out-of-the-box ideas, which designers can then refine or combine. It’s important, however, to curate and critique AI-generated ideas against HCD criteria: Are they feasible? Do they actually solve user needs uncovered in discovery, or are they just novel? Designers should ensure any AI-suggested concept is anchored in real user pain points and context; otherwise, it’s easy to get carried away with tech-driven ideas that lack user value.

AI can also enable co-creation with stakeholders. For instance, during workshops, participants could interact with an AI tool that visualizes their suggestions in real time. In a session with case managers, someone might say “it would be great if the system could flag duplicate applications automatically,” and an AI prototyping tool might mock up a quick interface of that concept, giving the group something concrete to discuss. This rapid materialization of ideas can enrich ideation, making abstract suggestions tangible. It also empowers non-designers to see their ideas in action, fostering a sense of ownership.

The second role is considering AI-driven features as part of solution ideas. In government case management, ideation might include ideas like “What if we had an AI assistant to help caseworkers prioritize their tasks each day?” or “What if an algorithm could predict which cases need escalation?” When proposing such concepts, HCD principles demand we think of how those AI features would interact with humans. The team should ideate not just the feature but also the guardrails: for example, the AI assistant might come with an explanation panel (“Here’s why I prioritized these cases today…”) to satisfy transparency, or a mechanism for the worker to give feedback (“This suggestion wasn’t helpful”) to ensure learning and trust. Essentially, when brainstorming AI features, include the surrounding human workflow and feedback loops in the concept.

It’s wise to consider multiple levels of AI involvement in solutions. Brainstorm a spectrum: from low-tech or human-only solutions to moderately intelligent aids to fully automated ones. A framework from the People+AI Guidebook suggests asking “When and how is it appropriate to use AI?” and ensuring user control and feedback are part of every concept. For example, for a problem like heavy paperwork, ideas might range from “a better paper checklist” to “a simple form auto-fill” to “an AI that completes entire cases automatically.” Discussing the pros/cons and ethical implications of each helps identify the right level of AI – perhaps the sweet spot is semi-automation where AI prepares drafts but humans approve them, balancing efficiency with accountability.

In summary, Ideation is a playground where AI can both inspire and be the subject of ideas. Embracing AI tools for creativity can yield rich concept sets, but designers must filter these through the lens of user-centric value and feasibility. By doing so, teams generate solutions that are not only innovative but grounded – leveraging AI where it makes sense and ensuring human needs lead the way.

AI in Prototyping and Iteration

Once promising concepts are identified, the next step is prototyping – turning ideas into tangible forms to test and improve them. Prototyping AI-based systems can be challenging, because the “intelligence” aspect may be hard to simulate without a fully built model. However, human-centered designers often use a mix of low-fidelity prototypes and Wizard-of-Oz techniques to mimic AI behaviors early on, and increasingly, specialized AI prototyping tools are emerging.

In government case management projects, a prototype might be a clickable interface mockup showing, say, how an AI recommendation panel would appear in a caseworker’s dashboard. The design team can manually fake the AI suggestions behind the scenes (Wizard-of-Oz) during user testing: e.g., they create some plausible recommendations for test scenarios rather than relying on a real algorithm. This allows gathering user reactions before investing in building the AI. For instance, a caseworker testing the prototype might see a pop-up: “The system suggests this case might need urgent review (Confidence: 70%).” The user’s feedback – Do they find it useful? Do they understand it? – is immensely valuable to refine the design. If users say the alert is unclear or not trustworthy, designers can tweak wording or presentation (maybe a different visual cue for confidence, or adding a “Why?” link for explanation) and test again. Iterative cycles like this ensure that by the time the AI is actually implemented, its integration into the UI/UX has been vetted by real users.

AI can help in prototyping as well. Generative design tools can create multiple UI layout variations quickly, or even generate synthetic data for testing. Suppose we need test case files to run through a prototype – AI can generate dummy case narratives or citizen profiles that appear realistic, which can save time over writing many manually. There are also prototyping platforms that allow designers to plug in basic machine learning models or use APIs to get some AI functionality into a prototype (like a prototype chatbot connected to a simple NLP service). These can approximate the feel of an AI-driven interaction, so users and stakeholders can experience it and provide feedback on the flow.

During the prototyping stage, it’s crucial to pay attention to usability and error states (as discussed under principles). Through user testing, designers should specifically probe situations when the AI might be wrong or uncertain. For example, in the prototype, simulate an incorrect AI suggestion and see how the user reacts. Are they able to notice it’s wrong and override it easily? Does it cause confusion or delay? This helps refine how the system should behave “when wrong” – maybe adding an easy “dismiss” button (as per guideline “Support efficient dismissal”) or designing the AI to gracefully step back when unsure (“Scope services when in doubt”– e.g., the AI asks the user to choose between options rather than auto-selecting when confidence is low). By prototyping these scenarios, designers incorporate resilience into the workflow.

Accessibility should also be tested with prototypes. If the AI feature involves, say, a lot of visual data (charts, predictions), test how that works with a screen reader or if there’s a text alternative. If it’s a voice assistant concept, test typing input and see if the design holds up. Early testing with diverse users can catch problems that, if left unaddressed, would undermine the inclusion principle later.

A noteworthy benefit: prototyping AI interactions often uncovers needed policy or process changes beyond the UI. For instance, testing an AI that prioritizes cases might reveal a question: “What if a caseworker disagrees with the AI’s priority? Is there a protocol?” This could lead to establishing a new process where a caseworker can mark a case as “do not auto-prioritize” or similar. Thus, iteration might involve not just UI tweaks but aligning the organization’s processes to effectively incorporate the AI. Because government systems operate in complex institutional contexts, prototyping can surface these socio-technical issues early, when they are easier to address.

In summary, prototyping and iteration with AI must be an active, user-centered process. Even if the AI isn’t fully functional, simulate it, test the human-AI interaction, and refine repeatedly. By the time development catches up with model training and integration, the design should have a clear blueprint of how the AI fits in, making the eventual deployment much more likely to succeed with users.

AI in Validation and Evaluation

The validation phase is where the solution is tested in real-world conditions or with realistic scenarios to ensure it meets user needs and performance goals. For AI-infused systems, validation needs to cover both traditional usability testing and evaluation of the AI’s outcomes and ethical aspects.

From a user experience standpoint, validation involves user testing of the nearly-final product (or high-fidelity prototype) to confirm it is effective, efficient, and satisfactory. Here, designers should validate that users understand the AI features, trust them appropriately, and can accomplish tasks with the AI’s help. Think of a pilot program in a social services department: a group of caseworkers uses the new AI-assisted case management software for a trial period. During this validation, designers and researchers would observe and gather feedback: Are the AI-generated summaries actually saving them time? Do they rely on the risk scores provided, or ignore them? Do any misunderstandings or workarounds emerge? This stage might involve surveys or interviews focusing on trust and perceptions (for example, “Do you feel the recommendations are usually correct?” or “Did the system ever surprise you in a bad way?”). Confidence calibration can be assessed by asking users to predict when the AI might be wrong and seeing if they guess correctly, which indicates healthy skepticism and understanding.

Crucially, validation for AI systems extends to measuring the AI’s actual performance and fairness on real data. This is often done by data scientists, but designers and stakeholders should be involved to interpret and act on results. Metrics such as accuracy, precision/recall, false positive/negative rates across different groups, and fairness metrics (discussed earlier) should be evaluated. For instance, after the pilot, the agency might analyze: Did the AI’s triage predictions correctly identify the urgent cases? Did it systematically over-prioritize or under-prioritize any demographic? If issues are found, this might lead to adjusting the model or adding safeguards. Designers, with their user-centric lens, should advocate that success isn’t just technical accuracy but also user outcomes like “no vulnerable group was adversely impacted” and “caseworkers reported improved efficiency without loss of confidence.” We might recall the NIST AI Risk Management Framework which recommends tracking metrics for various trustworthiness characteristics (fairness, transparency, privacy, etc.) to ensure a system is performing responsibly. In validation, one would check those: e.g., is the system’s explainability rating acceptable (maybe measured via a user quiz on understanding), is the privacy maintained (no data leaks or complaints), and so forth.

It’s also wise to conduct an ethical review or stress test in validation. One practice is scenario testing: deliberately create edge-case scenarios to see how the AI responds. For example, feed an anonymized case with very unusual data or a borderline situation to the system. Does it handle it gracefully or does it produce an obviously flawed result? Another practice is inviting an external auditor or an internal ethics board to examine the system at this stage – they might review the design for biases or test the system for any unintended consequences.

Feedback loops established in the design should be monitored as part of validation too. If the system has a user feedback mechanism (like flagging AI errors), check if users used it and what they reported. This can be an invaluable source of last-minute refinement and also set up the plan for post-launch monitoring.

Finally, validation should confirm that using the AI actually achieves the intended public service outcomes. If the goal was to streamline processing time, measure that in the pilot (Did average case resolution time drop?). If the goal was to improve citizen satisfaction, maybe run a small survey or gather anecdotal evidence from those who interacted with the new system. These tie back to the success metrics that matter to stakeholders – often a mix of efficiency gains and quality improvements.

In summary, validation is the phase where the rubber meets the road for AI solutions. A thorough validation not only tests usability with end-users but also evaluates the AI component against criteria of fairness, accountability, and effectiveness. It’s the last chance to catch issues before wider deployment. By validating in a multidisciplinary way (with designers, engineers, domain experts, and end-users all giving input), the team can be confident that the AI-enabled system is ready for responsible use at scale – or identify what needs to be fixed if it’s not.

AI in User Research: Synthesis, Personas, and Mapping

Beyond designing solutions, human-centered designers and researchers can leverage AI within their research process – turning the lens of AI inward to help understand users and problems better. In the context of case management and government services, design research often involves making sense of vast qualitative data, identifying opportunity areas in complex systems, and communicating insights (like personas or journey maps) to guide design. AI can assist in several of these research activities, augmenting human researchers’ ability to synthesize and analyze information.

AI for Research Synthesis and Theme Clustering

One of the toughest parts of user research is dealing with information overload – hundreds of interview transcripts, open-ended survey responses, or field notes. Traditionally, researchers code data and cluster insights through manual affinity diagramming. AI text analysis tools can expedite this by detecting patterns or frequent themes across documents. For example, suppose a team collected feedback from all 50 state offices on a federal case management system. An NLP model could quickly scan and output that “training difficulty” and “system speed” are the top mentioned issues, along with example quotes from each cluster. This gives researchers a starting point to validate and dig deeper.

It’s important to note that while AI can cluster semantically similar data, it doesn’t automatically know what’s meaningful or actionable – that’s the researcher’s job. So a good workflow is AI-assisted: use AI to do a first-pass grouping, then a human refines the clusters, perhaps merging some, discarding noise, and labeling them in human-centric terms. This hybrid approach speeds up synthesis but maintains researcher insight. Additionally, AI might surface unexpected patterns (for instance, a subtle correlation that offices with more staff complained more about complexity – perhaps indicating issues scale with staff size). Researchers can then formulate hypotheses and verify them through targeted follow-ups or cross-checking quantitative data. It’s a bit like having a tireless research assistant who combs through data, while the designer interprets and judges what it means.

Visual analytics (some powered by AI) can also help in sense-making. Topic modeling algorithms, for instance, might create a visual “map” of topics in interview data, showing how concepts connect. This can inform opportunity mapping (discussed later) by revealing relationships – e.g., complaints about “system speed” often co-occur with “data load”, hinting at a technical cause.

AI can assist in quantitative analysis of qualitative inputs as well. Sentiment analysis might be applied to open-ended feedback to gauge overall positive/negative tone for different features. Or anomaly detection could flag an unusual comment that doesn’t fit others – which might be a brilliant insight or a critical issue not seen elsewhere. Researchers should treat these outputs as clues, not conclusions, using them to ensure they don’t overlook anything significant.

Privacy and ethics apply to using AI in research too. If the data includes personal or sensitive information (like actual case notes or citizen feedback), researchers must ensure any AI tools comply with confidentiality requirements – ideally using secure, local tools rather than sending data to external cloud APIs without clearance.

In summary, AI can play a valuable role in digesting and summarizing research data, allowing human researchers to focus on interpreting meaning and empathizing with users. By handling tedious collation tasks, AI frees up designers to do what they do best – find human insights – and can broaden the scope of research by making sense of inputs that would be too vast to manually analyze in full.

AI-Assisted Persona Building and Empathy

Personas – archetypal user profiles – are a common tool in HCD to encapsulate key user groups’ needs and behaviors. Traditionally, personas are distilled from ethnographic research and data. AI can contribute by aggregating characteristics from large datasets to ensure personas are evidence-based. For instance, if designing a system for caseworkers, one might use data from HR systems, surveys, and interviews. An AI could identify patterns like “There seem to be three clusters of caseworker behavior: one is very tech-savvy and handles high volume, another is more old-school focusing on personal client interaction, and a third is specialized in certain case types.” These could seed persona definitions such as “Efficient Evelyn (the high-volume tech user)”, “Diligent Dan (the relationship-focused veteran)”, etc., backed by data stats (e.g., Evelyn handles 50% more cases than average and uses many shortcuts, Dan has 20 years experience and prefers phone calls to automated emails, etc.).

However, designers must be careful: personas need a human touch to be believable and empathetic. AI might give dry cluster outputs; the designer should weave them into a narrative that includes goals, pain points, and quotes. Interestingly, AI text generation can even help flesh out persona stories once the core traits are identified: a GPT model could draft a day-in-the-life of “Evelyn” or simulate her talking about her job. The designer can then refine this, ensuring it resonates with actual research observations. This can save time and yield creative details, but it requires curation – one must avoid fictitious details that aren’t supported by research. Transparency here is wise: mark which parts of a persona are data-derived versus hypothetical.

AI can also enhance empathy by providing simulations or role-play. For instance, conversational AI could let a designer “interview” a persona-like agent. Tools exist where if you feed the persona characteristics in, an AI chatbot can act as that persona, answering questions the way, say, “Diligent Dan” might. This is experimental, but could help teams internalize user perspectives by interactively exploring them. It’s like method acting with an AI partner. Still, one should verify that these AI-simulated responses align with real user research, or it risks reinforcing stereotypes or inaccuracies.

Another area is using AI to personalize the understanding of users. In government services, we often have segments (e.g., rural vs urban users, different language speakers). AI clustering might reveal sub-personas or underserved segments that designers weren’t initially aware of, ensuring inclusivity. For example, analysis might show a small but significant group of users who always access the system via mobile late at night – perhaps indicating gig workers or busy parents. This could lead to creating a persona or at least a consideration for that use case (ensuring mobile UX and after-hours support).

While AI can help draft personas, designers should ensure inclusion and avoidance of bias in these representations. If left unchecked, AI might generate persona profiles that inadvertently include biases (like assuming gender or other attributes from data patterns). Designers must correct and mindfully present personas in a way that challenges stereotypes rather than reinforcing them. For example, if most current caseworkers in data are women, an AI might assume a caseworker persona is female by default, but the designer can choose to present a mix to encourage thinking beyond current demographics (unless gender is a crucial factor in user needs, which usually it’s not).

In sum, AI can be a powerful aid in persona creation by crunching numbers and even generating preliminary narratives. Yet, the heart of a persona – empathy – comes from the design team’s understanding and humanization of the data. AI should serve to inform and inspire the persona development, not replace the nuanced judgment of researchers who ensure personas truly reflect and respect the people behind the data.

AI for Opportunity Mapping and Strategy

Design research often culminates in identifying opportunities – areas where interventions (like new designs or policies) could significantly improve outcomes. In complex systems like government case management, the ecosystem has many touchpoints and pain points, making opportunity mapping a valuable exercise. This typically involves mapping user journeys, stakeholder relationships, and system processes to find gaps or leverage points for innovation.

AI can contribute by analyzing large-scale system data to highlight where bottlenecks or unmet needs occur. For example, process mining algorithms can take event logs from a case management system (timestamps of each step in cases) to visualize the flow and where delays happen. The AI might show that “in 80% of cases, step X is a major bottleneck causing weeks of delay,” which becomes an opportunity area to streamline or support with automation. Similarly, AI might analyze social media or call center logs to find frequently asked questions or complaints – indicating areas where citizens struggle (opportunities for better self-service or clarification).

Predictive analytics can also suggest future opportunities or risks. In a child welfare context, an AI might predict that certain regions will see increased caseloads next year due to demographic trends. Designers and strategists could use that insight to propose proactive solutions (like training more staff or introducing an AI triage tool in that region) as opportunities to avert crisis. The key is to align these predictions with human insight and policy goals. AI might flag an issue, but deciding if it’s an opportunity and how to address it requires human judgment, especially in government where political and social considerations are at play.

Opportunity mapping can benefit from AI visualizations. Some AI tools generate system maps or influence diagrams by learning from data (for instance, showing connections between unemployment spikes and case application surges). These can help multidisciplinary teams see the bigger picture and brainstorm interventions. A word of caution: correlation is not causation. If AI suggests “variable A is linked to outcome B,” designers and policy folks should investigate further before jumping to solution mode. That said, such insights can broaden thinking – maybe revealing non-obvious factors affecting service quality that designers can then explore (e.g., “It looks like weather disasters correlate with benefit application spikes – how might we design our system to better handle disaster-related surges?”).

Another realm is scenario planning. AI can simulate different scenarios to see potential effects of changes. For instance, using a system dynamics model, one could ask, “What if we introduce an AI to auto-approve low-risk cases? How might it change workload and outcomes?” The simulation might show positive effects (reduced backlog) but also potential negatives (slightly higher error rates or new types of user inquiries). Designers could use this to refine the concept (maybe we add a random audit of auto-approvals to catch errors, mitigating that risk). This data-informed foresight is valuable for pitching and validating opportunities with leadership, who often want to know expected impact.

Finally, AI can help in evaluating which opportunities align with desired impact through multi-criteria analysis. Let’s say from research you have 10 potential projects. An AI prioritization tool could consider various factors (user impact score, cost, feasibility, urgency, etc.) and help rank them or cluster them (maybe some could be combined). While this doesn’t replace strategic decision-making, it gives a starting point that is more grounded than a sticky-note voting exercise. The team can then discuss the AI’s suggestion and adjust based on qualitative factors the AI doesn’t know (like political will or statutory constraints).

To summarize, AI augments the strategic phase of research by providing data-driven evidence for where design can make a difference, forecasting possible outcomes, and aiding in complex decision-making. Designers and strategists should pair this with their contextual understanding, creativity, and ethical compass to select and shape opportunities that will deliver public value. When done right, this results in a robust design strategy that is both visionary and credible, having been informed by real patterns and predictions rather than purely intuition.

Case Examples and Design Patterns for AI in Case Management

To ground the discussion, we examine real-world examples and emergent design patterns in AI-enabled case management systems. These examples illustrate what can go wrong and what good practice looks like, highlighting patterns that human-centered designers can apply or avoid. Case management in government often involves handling individual “cases” – whether that’s a benefits application, an investigation, a permit request, or a compliance review – through a structured process. Injecting AI into these processes has shown promise, but also pitfalls when not done responsibly.

Example 1: Automated Decision Pitfalls – The Robodebt Debacle

One of the starkest lessons comes from Australia’s Robodebt program (2015-2019). This initiative aimed to use automation and simple AI to identify welfare overpayments by comparing income data. It then automatically issued debt notices to citizens. Design flaw: the system operated with minimal human oversight and with a flawed assumption that discrepancies equaled debts. The result was tens of thousands of people receiving incorrect debt letters, causing confusion, financial distress, and in some cases severe personal trauma. The public outcry and subsequent legal challenges revealed that the algorithm overstepped ethical boundaries by effectively accusing individuals of wrongdoing without proper verification. From a design perspective, Robodebt lacked human-in-the-loop review, transparency, and empathy. A human-centered approach might have spotted that income data can be noisy or irregular (especially for gig workers) and required a caseworker to confirm debts or at least a clearer appeal process. The pattern here is over-automation of high-stakes decisions – a caution that in government services affecting livelihoods, AI should augment human decision-makers, not replace them entirely. Designers should pattern-match this as what not to do: never design a public-facing AI service that issues punitive actions (fines, denials, debts) with no human checkpoint or easy way for users to contest the outcome.

Example 2: Bias and Transparency Failures – Netherlands SyRI and UK Visa

In the Netherlands, the SyRI system (System Risk Indicator) was deployed to flag potential social security fraud by analyzing data like ethnic background, income, and housing. This algorithm became infamous for apparently using proxies like dual nationality as risk factors, leading to discriminatory targeting of immigrant families (the “child care benefits scandal”). Citizens had little insight into why they were flagged; the lack of transparency and clear bias violated principles of fairness and prompted a national scandal. A court eventually shut it down, citing human rights concerns. Similarly, the UK tried using an algorithm to assist visa application processing, but it was found to be opaque and allegedly biased (“entrenched racism” was mentioned) and got suspended in 2020. The design lesson: if an AI system produces decisions that correlate strongly with sensitive attributes like ethnicity, it’s likely to be unjust and will undermine trust. Public sector AI must be designed with bias audits and fairness constraints from the outset. Patterns to enforce include “fairness-by-design” (e.g., explicitly ensuring the model doesn’t use or proxy race, and testing outcomes across groups) and “explainable AI” (so authorities and affected persons can understand why a decision was made). In case management contexts, a best practice pattern is providing reason codes for any risk score or decision – akin to how credit scores come with factors affecting the score. Had SyRI been designed with transparency, it might have shown its criteria and allowed public debate and adjustment before causing harm.

Figure: “Human-in-the-loop” design pattern in action. When AI systems are uncertain or dealing with nuanced decisions, it’s a good pattern to involve human judgment rather than auto-commit. This screenshot from Microsoft Word’s spellchecker illustrates the idea: instead of automatically fixing a word when it’s not sure, the software underlines it and offers multiple suggestions for the user to choose. In government case management, similar disambiguation patterns can increase accuracy and trust – for example, if an AI can’t confidently match a citizen’s records, it could present options (“Did you mean person A or B?”) to a clerk, rather than guessing incorrectly. By designing AI to defer to humans at key moments, errors and unintended consequences are reduced.

Example 3: Augmentation Success – USPTO’s AI for Patents

On a more positive note, the United States Patent and Trademark Office (USPTO) successfully integrated AI to improve their patent classification and search process. Patent examiners must sift through massive databases to find relevant prior art. The AI tool used at USPTO doesn’t make final decisions; instead, it suggests possible classifications and relevant past patents to examiners, who then verify and use those suggestions. This speeded up application processing without controversy, largely because of how it was designed: as a support tool rather than a judge. The AI’s suggestions are presumably explainable (examiners can see the related patents, so the reasoning is evident), and the examiners retain control. The pattern demonstrated is human-AI collaboration where the AI handles grunt work (like a smart librarian fetching likely documents) and the human handles the nuanced analysis and final call. Designers of case management systems can emulate this pattern: identify tasks that are data-heavy but lower-risk for AI to handle, thereby freeing human workers to focus on complex, interpersonal, or high-stakes tasks. For example, an AI might draft a summary of a case file or pre-populate forms, which a human then reviews – accelerating work but keeping accountability with the human.

Example 4: AI-Assisted Triage – Benefits and Cautions

Several agencies have piloted AI for triaging cases – deciding which cases need urgent attention or which applications are likely eligible or ineligible. In a city government scenario, AI was used to triage housing assistance applications, scoring those likely to be in crisis for faster processing. This did help allocate resources more efficiently. However, designers noted the importance of a contestability pattern: applicants could ask for a review if they felt their case was wrongly deprioritized, and caseworkers could override the AI’s queue if they knew of special circumstances. This pattern ensures that the AI doesn’t become an unchallengeable gatekeeper. It builds a fail-safe: human discretion can always step in. The general design pattern here is “AI proposes, human disposes” – the AI can prioritize or recommend, but the human decision-maker has the final word and can adjust the AI’s outputs based on holistic context. When implemented, this often looks like an interface where AI-generated rankings or labels are clearly marked as such (e.g., “System Suggestion: High Priority”) and include an easy way for a human to change it (a dropdown to mark it “Normal Priority” if needed, with perhaps a required note). This not only prevents errors from cascading but also helps the AI improve if the system learns from those human overrides.

Example 5: Chatbots and Digital Assistants – Improving Accessibility

Many government agencies have launched AI-powered chatbots to handle common citizen inquiries (for instance, a virtual assistant on a welfare agency website that answers “How do I apply for X?”). A case study from a state unemployment insurance system showed that during the COVID-19 pandemic, an AI chatbot handled hundreds of thousands of queries, offloading call centers. The key to design here was making it a blended service: the chatbot answered FAQs, but if the question was complex or the user got frustrated (“I need to talk to a person!”), the system smoothly transitioned to a human agent or at least collected contact info for follow-up. This follows the pattern of graceful handoff – recognizing the limits of the AI. Another design point was tone and clarity: the chatbot was explicitly labeled as a virtual assistant and often provided links to authoritative information sources, maintaining transparency that its answers were drawn from a knowledge base. For designers, a takeaway pattern is ensuring user awareness of the AI’s identity (people should know they’re chatting with a bot, not a human) and providing escape hatches to human help. The latter could be a button or keyword that triggers “I can connect you to an agent” or gives a phone number. By designing these handoffs and disclosures, agencies kept citizen satisfaction reasonably high, as users felt the system was honest and got them to a solution one way or another. The risk if done poorly (which has happened in some cases) is when bots trap users in loops or hide the human contact option, which erodes trust quickly.

Emerging Pattern: Private AI and Data Protection

Case management often involves sensitive data (personal, health, criminal justice, etc.). An emerging pattern is using private or on-premises AI models to avoid sending data to third-party cloud services. For example, a county might deploy an NLP model locally to summarize case notes, rather than using a public API. The design consideration is that the system should clearly convey data is kept secure (maybe via a trust badge or a statement “Your data stays within our secure government servers during analysis”) to alleviate privacy concerns. Additionally, using smaller models fine-tuned on agency data might be part of the pattern. This was seen in an Appian case management solution for public sector, where they integrated AWS’s Bedrock in a way that models run in the agency’s cloud enclave. The design pattern isn’t user-facing per se, but it shows up in terms of policy banners or consent dialogues that reassure users how their data is being handled by AI. A citizen using an AI-assisted portal might see a note: “We use automated tools to process your information. These tools operate securely within our system and do not share your personal data externally.” For designers, collaborating with IT to implement and then communicate such safeguards is key. It marries the privacy principle with technical deployment.

In reviewing these examples, a common theme is that AI in case management should follow an augmentation over automation philosophy – empowering humans with AI suggestions, information, and efficiencies, but not removing humans from the loop on matters of judgment, rights, or accountability. Patterns like human-in-the-loop, explainability, contestability, and graceful handoff are safety nets ensuring that if (or when) the AI errs or encounters ambiguity, the system as a whole remains effective and fair. These patterns, when baked into design requirements, help avoid the missteps of early AI deployments and harness the technology to genuinely improve service delivery.

Guidelines on When Not to Use AI

With all the potential of AI, knowing when not to use it is just as important as knowing how to use it. An axiom for responsible innovation is: Just because we can automate something with AI doesn’t mean we should. Human-centered designers should be prepared to advise, or even push back, when an AI solution is inappropriate. Below are key considerations and red lines for deciding against AI deployment in government design:

• When it Violates Ethical or Legal Standards: If an AI application is likely to infringe on rights (like due process, privacy, non-discrimination), that’s a stop sign. For example, fully automating the rejection of welfare benefits without human review could violate due process rights. The U.S. White House’s AI Bill of Rights blueprint emphasizes algorithmic decisions should be fair and transparent, and users should have recourse. If an AI design can’t meet those, it shouldn’t be used. Similarly, laws like the EU’s GDPR or emerging AI regulations might outright prohibit certain AI uses (like surveillance AI that invades privacy, or AI in hiring that lacks bias controls). Designers must be aware of these constraints; if the concept is in a “red zone” of ethical AI (e.g. social scoring systems or predictive policing tools known to amplify bias), the responsible path might be choosing a non-AI solution or a heavily constrained approach.

• When Human Judgment is Essential and Irreplaceable: Some decisions inherently require human empathy, discretion, or contextual understanding that AI simply cannot replicate. In government contexts, think of a social worker deciding a child’s placement, or a judge determining sentencing – these involve moral reasoning and often intangible factors. An AI can provide data, but handing over the decision is not appropriate. A rule of thumb is the “Newspaper Test”: if the idea of an AI making a certain decision would cause public outrage if it were on the front page of the news, don’t use AI for that. For example, “AI denies disability claim for veteran” – that headline would be a trust disaster. So for any case where empathy or nuance is key to legitimacy, AI should not replace the human, only perhaps assist in minor ways (like organizing info for the human).

• When Data is Inadequate or Quality is Poor: AI’s judgment is only as good as the data and assumptions behind it. If you don’t have reliable, representative data for the task, using AI can be dangerous. Say an agency wants to predict which restaurant health inspections to prioritize with AI, but their historical data is spotty or biased (maybe only certain neighborhoods were heavily inspected in the past, skewing the model). Deploying AI in that scenario could perpetuate biases or be flat-out wrong – not to mention unfair. A responsible team might conclude that until better data is collected (or a simpler rule-based approach is sufficient), AI is not the right tool. This ties to the concept of evidence and AI fit: A 2025 practice guide by CDT urges agencies to evaluate evidence and data quality and not assume AI is always the best approach. If the AI can’t be trained well, don’t train it at all.

• When the Use Case is Too Small or Simple: Sometimes the problem doesn’t need AI. A basic script or improved user interface might solve it more transparently and cost-effectively. If a workflow has only a few cases a month or follows a straightforward rule, applying a complex AI could be overkill and add unnecessary complexity. Always consider Occam’s razor in design: the simplest solution that works is often best. Using AI can introduce maintenance burdens, explainability issues, and need for specialized expertise – which might not be justified for a small improvement. For example, if citizens are having trouble finding information on a website, a redesign of navigation might fix it better than an AI chatbot – which would require training, constant updates, and still could give wrong answers.

• When Risks of Error Are Unacceptably High: If a mistake by the AI could lead to irreversible harm or significant rights violations, you likely shouldn’t use AI (or should keep a human final check, effectively negating full automation). Think medical diagnoses or child abuse flagging – an AI error in those arenas could ruin lives. Unless the system is proven extremely accurate and has safety nets (and even then, typically it’s used to assist, not decide), one should not fully rely on AI. Design with a risk matrix: identify worst-case outcomes and their probabilities. If AI introduces a new catastrophic failure mode that you can’t mitigate, don’t go there. For instance, an autonomous AI decision to remove a child from a home is a no-go; only a human legal process can do that, and AI might at most be an advisory tool.

• When It Erodes Trust Needlessly: There may be scenarios where using AI, even if possible, would break the trust or acceptance of users. For example, if caseworkers strongly feel that an AI can’t understand the complexities of their job, forcing an AI tool on them might face backlash and non-use. In such cases, it might be better to opt for designs that give users more control or simpler tools. Another angle: the public might accept AI in some government tasks but not others. Being sensitive to context is important. If deploying an AI would create a chilling effect (like citizens fearing an algorithm is watching their every move in a public service), it may do more harm than good. It could be wiser to improve human service or use simpler analytics quietly in the background rather than a flashy AI that public perceives as Big Brother.

To operationalize these guidelines, agencies and design teams can use frameworks like CDT’s “To AI or Not to AI” checklist, which explicitly has steps to question appropriateness and weigh alternatives. This includes documenting decisions – if you decide not to use AI, that’s a valid outcome and can be explained to stakeholders (e.g., “We considered an AI solution here but due to lack of high-quality data and the need for empathy in this process, we are choosing a human-driven approach augmented by simpler automation.”). Such transparency ensures that saying “no” to AI is seen as an informed, responsible choice rather than a missed opportunity.

In essence, designers should feel empowered to act as the voice of caution. By understanding AI’s limits and the context of government services, they can spot when applying AI would violate the HCD principles we outlined (transparency, inclusion, etc.) or simply not yield a safe, effective outcome. Responsible innovation sometimes means pulling back and picking a different tool – or focusing on organizational/process changes – instead of AI. Knowing when not to use AI is part of ethical design leadership in the age of AI.

Frameworks and Toolkits for Responsible AI Integration

To help operationalize responsible AI use, designers and organizations can rely on established frameworks, checklists, and toolkits. These resources encapsulate best practices and provide structured methods to ensure nothing critical is overlooked. Let’s explore some of the prominent frameworks and how designers can employ them in the context of AI for government case management systems:

People + AI Guidebook (Google PAIR)

Google’s People + AI Research group (PAIR) has developed the People + AI Guidebook, which is a collection of guidelines and methods specifically for human-centered AI product design. It covers the entire product lifecycle and is very practical. Key topics from the guidebook include: deciding when (and when not) to use AI, designing for user trust and control, handling failure cases, and user feedback loops. For example, one guidebook principle is to “start with user needs, not AI capabilities” – meaning you should only introduce AI if it actually helps solve a user problem that other methods can’t. Another principle is providing the “right level of user control”: some AI features might need a on/off switch or settings for users, while others should work automatically in the background.

Designers can use the Guidebook as a reference during ideation and design reviews. It contains example case studies (some even government-related) and pitfalls. Suppose a team is designing an AI assistant for caseworkers; the guidebook’s sections on mental models might remind them to clarify what the AI knows and doesn’t know to the user. The Guidebook even has workshop templates, so a team can run an internal workshop to brainstorm, say, failure modes of their AI feature (“what could go wrong and how will we mitigate it?”). By methodically applying these best practices, designers embed human-centric thinking into the AI features.

A second edition of the Guidebook in 2023 expanded to cover generative AI and more examples, reflecting the latest challenges. It’s available publicly, and organizations can adapt it into their own design playbooks.

“To AI or Not To AI” Decision Framework (CDT)

As mentioned earlier, the Center for Democracy & Technology (CDT) published a framework in 2025 for public agencies evaluating AI projects. It is essentially a checklist and process to assess appropriateness. The four steps include:

1. Define the problem and goals clearly.

2. Brainstorm a range of solutions (AI and non-AI).

3. Assess the “AI fit” – which is a multidimensional check including data suitability, impact on users, readiness of the organization, and risk factors.

4. Document and communicate the decision transparently.

Designers can champion this process by ensuring during project kickoff that these steps are followed. For instance, in step 3, the “AI Fit Assessment” might involve asking: Do we have evidence that AI would be better than a simpler approach? Do we have the talent to maintain this AI? What are the possible harms? and Can we mitigate them? If the answer to many is negative, that’s a signal to reconsider. The framework explicitly emphasizes not assuming AI is always the right choice and protecting civil rights and building trust. This is a powerful ally for designers who need to make the case to enthusiastic stakeholders that sometimes a low-tech solution is preferable.

This framework is available as a report and checklist. A design team could integrate it into their project gating: for example, before starting development, fill out a one-page summary from this framework to ensure due diligence. It also talks about communicating decisions to the public – so if an agency decides to use AI, they should be transparent about how and why (which aligns with building public trust).

Microsoft’s Guidelines for Human-AI Interaction

We delved into some of these earlier. Microsoft’s research-based 18 guidelines serve as a checklist specifically for interaction design of AI features. They cover things like initial interaction (setting expectations), during interaction (contextual timing, matching social norms, avoiding bias in behavior), when the AI is wrong (easy correction, explanation), and over time (learning from user, updating carefully, notification of changes).

Designers can use these as a heuristic evaluation tool. For instance, at various design milestones, one could review: Does our design “Make clear why the system did what it did” (Guideline 11)? If not, maybe we need to add an explanation view or logs. Or, Do we allow users to correct the AI easily (Guideline 9)? If our prototype doesn’t have an edit or undo for an AI action, that’s a gap to fix. This acts like a quality control, ensuring the product adheres to known best practices before it ships.

Microsoft also released a “Responsible Bots” guideline for conversational AI, which could be relevant if designing a chatbot – it includes tips like clearly disclosing the bot is not human, ensuring fallback to humans, and so forth.

IBM’s Everyday Ethics and Other Toolkits

IBM has an “Everyday Ethics for AI” toolkit (a framework described in a substack/UX article) focusing on five areas: accountability, value alignment, explainability, fairness, and user data rights. It provides reflection questions and methods for each area. For example, under fairness, it might ask “How have you tested for biases in your data and model? Are impacted communities part of this evaluation?” Under accountability, “Is it clear who is responsible if the AI makes a bad decision?”.

Design teams can do an ethics workshop using such a toolkit for their project. It’s sometimes in the form of cards or canvases where you fill in answers. For instance, an Ethics Canvas is a tool (like a Business Model Canvas) that some use: it prompts teams to write down the system’s stakeholders, potential harms, benefits, and risk mitigations in a one-page grid. This process ensures the multidisciplinary team (designers, developers, policy folks, lawyers) have a shared understanding of the ethical considerations and agree on how to address them.

There are also open-source toolkits like AIF360 (AI Fairness 360) and Fairlearn that provide technical guidance and code to check fairness metrics and mitigate bias. While those are more for data scientists, designers should be aware of them – they can prompt that such analysis be done and then incorporate results (e.g., “We ran Fairlearn, discovered our model was less accurate for older users, so we adjusted the model and our interface will now also display a notice when high uncertainty is detected, etc.”).

Government and Industry Guidelines

Many governments have published AI ethics or governance guidelines that can be interpreted into design requirements. For example, the US AI Bill of Rights (Blueprint) outlines principles (safe and effective systems, algorithmic discrimination protections, data privacy, notice and explanation, human alternatives) which align with what we’ve discussed. Designers can use these as a North Star to ensure their designs provide notice & explanation, etc. The UK, EU, and others have similar documents. Using these can also help when presenting to agency leadership, as you can tie your design decisions to official policy (e.g., “We included an explanation sidebar because the AI Bill of Rights calls for users to receive explanations of automated decisions”).

Additionally, NIST’s AI Risk Management Framework (RMF) offers a comprehensive approach. It outlines functions like Map, Measure, Manage, and Govern in AI deployment. While a bit high-level, it suggests having risk registers, metrics for trustworthiness (which we saw earlier), and governance structures. Designers might not implement all that, but they should know if their organization is following NIST RMF and contribute by providing the user perspective in risk assessments.

Finally, some design firms and academic labs have their own checklists (e.g., “RAI (Responsible AI) checklist 2025” as seen in search results). These often distill similar points: inclusive team, define intended and unintended use, plan for failure, consider accessibility, etc. Incorporating one of these checklists into design peer-reviews can systematically improve outcomes. For example, before finalizing a design, have the team go through a 10-point responsible AI checklist: “1) Did we involve diverse users? 2) Did we mitigate bias? 3) Is the AI decision process explainable to users? …” etc., and require evidence or notes on each.

The overarching message is that designers are not alone in figuring out responsible AI – a lot of collective wisdom is already codified in these frameworks. Using them not only ensures better designs but also provides backing for your decisions. If anyone questions, “Why are we spending time on X?”, you can point to these respected guidelines and say, for instance, “Cross-disciplinary collaboration and oversight are explicitly recommended by international standards”. It adds weight and prevents reinventing the wheel. Adopting a toolkit or framework can become part of the organization’s design process, creating a repeatable approach to integrating AI ethically and effectively.

Measuring Success: Metrics for Trust, Fairness, and Impact

Designing and deploying an AI-enabled system is not the end – we need to ensure it actually works as intended and continues to do so responsibly. This requires establishing metrics for success that go beyond the usual project KPIs. In human-centered AI for government, success is multidimensional: it’s not just efficiency or cost savings, but also user trust, fairness, and societal impact. Let’s break down how one might measure and validate these facets:

User Adoption and Satisfaction

A basic measure of success is whether the end-users (caseworkers, citizens, etc.) actually use the AI features and find them helpful. Traditional UX metrics like System Usability Scale (SUS) scores, task completion rates, or user satisfaction ratings still apply. After introducing an AI tool, one can conduct surveys: Do case managers feel the tool saves them time? What is their satisfaction on a 5-point scale? If these metrics don’t improve (or worse, decline), that’s a red flag – maybe the AI made the system more complicated or less reliable, which is a design failure needing attention.

Beyond general satisfaction, measure trust and confidence specifically. This can be done through targeted questionnaires or interviews. For instance, ask users if they trust the AI’s recommendations and under what circumstances they choose to follow or ignore them. A well-regarded research approach is to measure calibrated trust: ideally, users should trust the system in proportion to its actual accuracy. One way to gauge this is to test users’ understanding (e.g., ask them how accurate they think the AI is, or present scenarios where the AI is wrong and see if they detect it). If users over-trust (thinking it’s perfect) or under-trust (never using it), the design needs adjustment (maybe more transparency or training). High calibrated trust means users rely on the AI when it’s correct and are cautious when it might be wrong – indicating the system has achieved an equilibrium of trustworthiness and understanding.

Qualitative feedback is also key: quotes from users like “I was skeptical at first but now I see it catches things I might miss” or “The AI’s explanations make me feel in control” are evidence of success in trust-building. Conversely, “I always double-check because I’m not sure why it suggests what it does” indicates more work needed on explainability.

Fairness and Equity Metrics

To validate that the AI system is fair, one must gather data on outcomes across different groups. This might require working with data analysts to log decisions or suggestions made by the AI and the demographics of cases. Metrics might include:

• Disparate Impact: Are there statistically significant differences in outcomes (approvals, flags, etc.) for different demographic groups (race, gender, region)? Ideally, after deployment, an analysis should show no undue disparity that isn’t justified by legitimate factors. For example, if an AI for fraud detection flags 30% of applications from one community and only 5% from another without a valid reason, that’s problematic.

• True/False Positive Rates by Group: This is aligned with Equality of Odds. If possible (where ground truth can be obtained later), compare error rates per group. If error rates differ significantly, investigate why. The goal would be parity or to explicitly correct the model.

• User Perception of Fairness: In user surveys, include questions like “Do you feel the system treats everyone fairly?” or if interviewing citizens, “Did you feel any bias or unfairness in the process?”. Perceptions matter for trust, even beyond the actual algorithmic fairness.

There are frameworks like FRIES (Fairness, Robustness, Integrity, Explainability, Safety) trust score mentioned in some literature, which try to combine multiple dimensions. An organization might adopt a composite score approach: for example, assign scores 1-5 on fairness (based on disparities), explainability (based on user quiz results or satisfaction with explanations), etc., and track that over time aiming to improve.

Using tools: as noted, IBM’s AI Fairness 360 or Microsoft’s Fairlearn can be run on decision data to compute fairness metrics regularly. This could be integrated into monitoring pipelines. If metrics like Statistical Parity or Predictive Parity fall outside acceptable ranges, it triggers an alert to either retrain the model or adjust policies.

The design team’s role in fairness metrics is collaborating to define what thresholds are acceptable and ensuring the data needed for these checks is collected (design might need to capture user race voluntarily for internal audit, or ensure the system logs decisions with needed metadata).

Transparency and Explainability Checks

While harder to quantify, one can attempt to measure how transparent or explainable the system is to users. One method is explainability satisfaction: ask users if they understand why the AI made a recommendation. Or give them a specific decision and ask them to explain it back – if they can do so correctly, the system’s explanation was effective. Another metric could be usage of explanation features: if the system has a “Why?” button next to AI outputs, monitor how often users click it. If they click it frequently and then still override the AI, maybe the explanations aren’t clear enough or not addressing their needs. If they rarely click it, perhaps they either trust blindly (not good) or find the system so clear they don’t need it (good, but unlikely without heavy domain knowledge).

NIST’s RMF suggests including “traceability and transparency” in metrics. One could measure transparency in terms of documentation and communication: for instance, ensure 100% of AI decisions are logged for audit, and that a plain-language description of the AI logic is available to all users (could be measured by presence and updates of documentation). While more of a checklist than metric, compliance with transparency measures (like an Algorithmic Impact Assessment being published) is a goal to track.

Operational Performance and Public Impact

Of course, the success metrics also include the original performance goals: e.g., reduction in processing time, increase in cases handled per staff, lower backlog, cost savings, etc. If the AI was meant to improve efficiency, gather data to see if those improvements happened and without negative side effects. Did citizen wait times drop? Did throughput increase? These are traditional metrics that validate the AI provided value. If not, the project might be reevaluated.

But pair these with quality metrics: e.g., Accuracy of AI predictions if applicable, and Error rates. If, say, the AI triage prioritized correctly 90% of the time (accuracy), that might be acceptable, but maybe it missed 10 critical cases (false negatives) – one must judge if that trade-off was worth it or if changes are needed. Perhaps success means reaching 95% accuracy with no critical false negatives, and the system isn’t fully successful until that’s tuned.

Another aspect is user behavior changes: sometimes introducing AI changes how people do their work. Measure outcomes like how often do caseworkers follow AI recommendations versus override them. If overrides are extremely high, either users don’t trust it (bad) or the AI is often wrong (also bad); this indicates it’s not adding value yet. Monitoring these rates over time helps see if adoption improves as the AI improves or as training/experience with the system grows.

For public-facing systems, complaints and appeals rates can be telling. If after an AI was introduced the agency sees a spike in appeals or complaints about decisions, that’s a sign something’s off – maybe the AI is making more contentious calls, or people are more wary of an automated process. Ideally, a successful responsible AI deployment might even reduce complaints if it speeds things up and is perceived as fair.

Continuous Monitoring and Governance

Success metrics shouldn’t be one-and-done at launch. A plan for ongoing monitoring should be in place. This could include periodic audits (quarterly or annually) where a committee reviews key metrics like those above. For instance, check fairness metrics quarterly, and user trust survey yearly. NIST RMF’s Measure function essentially advocates this continuous tracking to manage risks.

It’s prudent to set up a dashboard if possible – something that tracks the AI’s performance (accuracy, throughput) and ethical indicators (fairness, override frequency, etc.) in near real-time. That way, if something drifts – e.g., suddenly the AI’s error rate goes up due to data drift or a policy change – it can be caught and addressed quickly.

Furthermore, incorporate feedback loops as metrics themselves: how many user feedback items were received about the AI (e.g., through an in-app feedback form)? And were they addressed? A low number might mean smooth operation or it might mean people don’t know how to report issues – context needed. But tracking them shows responsiveness. A responsible AI governance approach might require documenting any incidents (like a known case of AI error causing a problem) and what was done about it.

In summary, measuring success in human-centered AI is about balancing the traditional quantitative service metrics (speed, volume, cost) with qualitative and ethical metrics (trust, fairness, transparency). It requires gathering data from both the system and the people interacting with it. By defining these metrics early (during design) and tracking them through pilot and full deployment, a team can validate that the system is meeting its objectives without unintended harm. If it’s not, those metrics will hopefully provide early warning signs so designers and policymakers can adjust course – whether that means refining the model, improving the UI, retraining users, or in extreme cases pulling back the AI until issues are resolved. This vigilant approach to validation and monitoring is how we ensure AI in government delivers positive outcomes and maintains public trust and accountability.

Conclusion: The Evolving Role of Designers in AI Governance

The integration of AI into government case management and services is not a one-time project – it’s an ongoing journey. As AI capabilities advance and policies evolve, so too must the practices of human-centered design. Designers stand to play a pivotal role in AI governance and the future of public sector innovation, bridging the gap between technological possibilities and human values.

Looking ahead, we can anticipate that cross-disciplinary collaboration will become even more crucial. Designers will regularly find themselves in teams with data scientists, ethicists, lawyers, social workers, and community representatives. In these settings, designers bring the lens of empathy and usability, ensuring that high-level principles (like those in ethical AI guidelines) translate into concrete user interface elements and interaction flows. They might lead workshops to surface values and concerns from diverse stakeholders (perhaps using participatory design methods) and then work with data scientists to implement technical measures addressing those concerns. A likely trend is the formation of AI ethics committees or review boards within agencies – designers should seek a seat at that table. Their input on how real users might experience an AI system, and how to communicate about it, is vital to responsible governance.

Designers will also help shape policy through prototyping and experimentation. As new laws or internal policies around AI come up (e.g., rules on explainability or bias testing), designers can create prototype solutions to meet those requirements, effectively demonstrating to policymakers what’s feasible and what users respond to. Conversely, when policy is lagging technology, designers can highlight issues users face that indicate a need for policy – for example, if users are confused about AI decisions, designers might advocate for a policy that requires agencies to provide plain-language explanations for AI. In this way, the design function informs governance, not just follows it.

Another expanding role is in training and change management. Government workforce and the public will need to be educated about AI systems – how to use them, their limits, and rights around them. Designers often create instructional content, onboarding experiences, and even public-facing communication. They can ensure these materials are clear and not overly technical. This transparency and education piece is actually a part of AI governance (people can only hold a system accountable if they know it exists and roughly how it works). We might see designers collaborating on public dashboards that show how an AI is performing – something New York City did with their algorithm management and that others might emulate for openness. Designing these dashboards or reports in an accessible way is a design task aligned with governance.

In terms of future directions, technologies like explainable AI and interactive machine learning will evolve – designers will need to keep up and weave those into interfaces. For instance, if tomorrow’s AI can generate visual explanations or allow users to tweak model assumptions, designers should be ready to incorporate such features to give users more agency. The concept of “model cards” and “datasheets for datasets” are emerging transparency tools – a designer might turn those into user-friendly summaries (like a nutrition label for AI).

We can also expect that the definitions of metrics like fairness and trust will mature, possibly requiring standardized reporting (similar to how privacy policies are standardized today). Designers may contribute to creating standard symbols or indicators (imagine a “Trust Seal” or fairness gauge) in interfaces that quickly convey to users the trust level or certification of an AI service. That’s a likely evolution in making ethical attributes of AI visible and understandable.

Finally, the designer’s role includes being an advocate for the user in AI policy discussions. This might involve testing AI systems with real users (as we do) and sharing stories and evidence with policymakers. For example, if a legislature is debating guidelines for AI in welfare, a designer could present findings from user research about what recipients need to trust the system (like maybe they strongly want a human caseworker option). These insights ensure that governance frameworks remain grounded in the reality of human experience, not just abstract principles.

In conclusion, human-centered designers are essential to ensure that as government agencies embrace AI, they do so in a way that serves people first. By adhering to principles of transparency, inclusion, privacy, trust, and usability, integrating AI thoughtfully into design processes, leveraging frameworks and metrics for responsible oversight, and staying engaged in cross-disciplinary governance, designers help steer AI development onto a course that can truly enhance public services. The impact sought is not just efficiency, but equity, accessibility, and public trust – outcomes that matter deeply in the public sector context. AI will undoubtedly change the way government operates; with human-centered design and responsible practices, that change can be positive – simplifying processes, extending reach, and improving outcomes for society’s most vulnerable, all while upholding the values that define public service.

The evolving role of designers in this landscape is both exciting and demanding. They must be technologists, ethicists, communicators, and empathizers all at once. Embracing this role, designers become key players in AI governance – the champions who ensure that as we innovate with algorithms, we never lose sight of the humans at the center. The future of government AI is human-centered, and it will be designers, working hand-in-hand with other professionals, who continuously align these powerful technologies with the public good.

This playbook outlines a practical, human-centered approach for Salesforce teams working on case management and similar workflows. It follows Salesforce’s design playbook style – structured, actionable, and approachable – guiding teams through the full HCD (Human-Centered Design) lifecycle. The guidance is organized into phases (Discover, Define, Design, Deliver, Evolve), with modular Plays in each phase. Each Play includes Purpose, When to Use, How to Run It, Tools, and Success Signals. The advice is platform-agnostic but inspired by Salesforce values. Key emphases include co-design with stakeholders, inclusive and trauma-informed practices, strong design governance and QA, and measurable outcomes (usability, equity, trust, adoption).

Discover

In the Discover phase, the team gathers insights on users’ needs, context, and pain points, and sets up project governance. This is about understanding the current situation deeply before proposing solutions. It also involves preparing the project to be human-centered.

Stakeholder & User Mapping

Purpose: Identify all relevant stakeholders and users, and establish project governance. List every group affected by or influencing the solution (case managers, clients, admins, IT, executives, etc.) so none are overlooked. At this stage, set up a design authority or governance committee with clear roles and decision processes to oversee the HCD approach.

When to Use: At project kickoff or early discovery. Use this Play to assemble the project team, get executive buy-in for HCD, and include user representatives in governance. It ensures the project is aligned with real user needs from the start.

How to Run It:

• Map Stakeholders: Brainstorm and list all stakeholder groups (internal teams, end-users, partners, etc.). Identify key user segments, including vulnerable or marginalized groups, and supporters (trainers, helpdesk).

• Identify Co-Design Participants: Choose representatives from each user group (case workers, clients, etc.) to participate in future design activities. Ensure diversity so multiple perspectives are included.

• Set Governance Structure: Create a design authority or steering group (project leaders plus some user advocates). Define roles (e.g. UX lead, stakeholder reps) and a process for decisions (e.g. require sign-off for major UX changes).

• Plan Communication: Schedule regular reviews (e.g. weekly updates) where the team shares discoveries and decisions with stakeholders. Maintain open channels (Slack/Chatter) so users feel their input is valued.

Tools: Use stakeholder mapping templates (like power-interest grids), RACI charts for governance roles, and collaboration tools (Slack, Salesforce Chatter). Document the governance plan in Salesforce’s Experience Cloud or a project wiki.

Success Signals:

• A comprehensive stakeholder map exists and is agreed by the team.

• A governance committee/design authority is established with clear membership and roles.

• Stakeholders (including end-users) understand and support the HCD process.

• No key user group is missed in research planning (e.g. front-line caseworkers and clients are included).

Participatory User Research Planning

Purpose: Plan and conduct inclusive user research to uncover real needs, pain points, and ideas. Use participatory methods that involve users (co-design, interviews, workshops) so they shape the insights. Ensure research ethics (consent, privacy) and stakeholder oversight are in place for responsible co-design.

When to Use: At the start of the project (or before any new feature design), before defining requirements. Use this to gain a deep understanding of current workflows (e.g. how case managers work, what clients experience) when you don’t yet have clear solution ideas. Repeat when entering new domains or adding user groups.

How to Run It:

• Define Research Goals: Clarify what you want to learn (e.g. “How do case officers track client progress?”). Align these goals with stakeholders so they see the value.

• Choose Participatory Methods: Select inclusive research methods such as user interviews, contextual inquiries (observing users at work), co-design workshops (users sketching solutions), and diary studies. Consider participants’ comfort and accessibility needs.

• Governance & Ethics: Establish consent and privacy protocols. Have an ethics checklist (voluntary participation, confidentiality) and get necessary approvals (e.g. IRB for healthcare contexts).

• Recruit Diverse Users: From the stakeholder map, recruit participants across roles, skill levels, and backgrounds. This surfacing of varied needs ensures equity (avoiding design for the “average” user).

• Conduct Sessions: Pair a facilitator and note-taker. In workshops, give participants simple tools (sticky notes, sketch templates, whiteboard or Miro) to express ideas. Create a respectful, safe atmosphere so participants share freely.

• Capture Findings: Document user quotes, current pain points, and any ideas users suggest. Collect sketches and notes from co-design sessions. Pay attention to emotional cues – frustrations may indicate broken trust or stressful steps in the workflow.

Tools: Use interview guides and empathy maps; record sessions (with consent); use whiteboard software (Miro, Lucidchart) for remote co-design. Salesforce Surveys or Forms can gather quick polls. Keep a shared research log or repository.

Success Signals:

• Research sessions involve a representative cross-section of end-users and stakeholders.

• Participants feel the process was inclusive and respectful (users give feedback that they appreciated being heard).

• The team identifies clear pain points or unmet needs (e.g. “Users struggle with step X” or “Clients currently workaround by using Excel”).

• The team collects user ideas or sketches that generate potential solutions.

• The research is ethically conducted: all participants gave informed consent, and no sensitive data was mishandled.

Journey Mapping & Insight Synthesis

Purpose: Turn raw discovery data into concrete design guidance: personas, journey maps, and insight statements. Journey maps chart each step of the user experience and highlight pain points and emotions; personas summarize major user types. This builds empathy and reveals key improvement opportunities.

When to Use: After completing discovery research. Once you have interview and observation findings, summarize them into personas and a current-state journey map. It’s also valuable to repeat if new user groups are added.

How to Run It:

• Create Personas: Identify patterns and draft 2–5 personas for major user types (e.g. “Frontline Case Worker Alice”, “Program Manager Bob”, “Client Carlos”). For each, list goals, needs, pain points, context. Base them on real data (use quotes or metrics) to keep them grounded.

• Map the Journey: Choose a key workflow (e.g. “Submitting a new case”, or a client’s service journey). Map it step by step from the user’s perspective. For each step, note what the user does, thinks, and feels, and mark any friction or questions. Use icons or colors to highlight pain points. Also note where trust is built or lost (e.g. does a security request make the user feel uneasy?).

• Identify Moments of Truth: Mark critical moments that strongly influence satisfaction or outcomes. These are steps where failure derails the process (e.g. onboarding or case closure). They become priorities for improvement.

• Involve Stakeholders: Conduct a synthesis workshop with the team and some user reps. Review the journey map and personas together to validate findings and ensure everyone shares the user perspective.

• Extract Insights: Write key insight statements or “How Might We” (HMW) questions from the map. For example: “Clients often feel lost during onboarding – HMW create more transparency to build trust?” These link directly to user needs identified.

Tools: Journey mapping and persona templates (paper or virtual tools like Miro/Mural). Sticky notes and affinity mapping for clustering observations.
Success Signals:

• 2–5 personas are created and actively used by the team (stakeholders recognize them as real users).

• A current-state journey map is documented with clear pain points and emotions; the team refers to it when prioritizing features.

• The team has a list of validated pain points and opportunity areas drawn from research (e.g. “Users need easier status tracking; the current workaround is too slow”).

• Team members across roles (developers, PMs, etc.) can articulate who the user is and what they need, showing empathy alignment.

• The user is clearly “at the center” of thinking, evidenced by discussions that focus on user experience as much as technology.

Define

In the Define phase, the team formalizes what they learned: they nail down the core user problem and set criteria for success. This means focusing on the right problem, defining scope, and establishing metrics and guiding principles.

Problem Framing Workshop

Purpose: Formulate a clear, user-centered problem statement (or a concise set of them) that everyone agrees on. This aligns the team and stakeholders on what exactly needs solving, and includes any equity or inclusion concerns so the problem isn’t one-sided.

When to Use: After Discover (or whenever scope feels unclear). Use this to prevent solution-jumping and ensure everyone agrees on the problem before ideation.

How to Run It:

• Review Insights: Start the workshop by revisiting personas and top pain points. Remind everyone of user quotes or stories to keep the user’s voice present.

• Draft Problem Statements: Each participant writes a one-sentence problem (e.g. “Case managers need a way to track case updates in real-time because delays are causing frustration”). Use the format User–Need–Insight.

• Share & Combine: Share all drafts and look for common themes. Merge similar statements into 1–3 consolidated problem statements. Make sure any equity issues are mentioned (e.g. if a specific group is underserved).

• Formulate HMW Questions: For each problem, create one or more “How Might We…” questions to spark ideas (e.g. “How might we enable secure real-time case collaboration?”). Focus these questions on the user’s challenge, not on technical solutions.

• Define Scope: Discuss what is in scope vs. out of scope. Note constraints (budget, policy) but encourage creative thinking initially.

• Alignment: Obtain agreement from stakeholders (verbal or written) that this is the problem to solve. This becomes the project’s north star.

Tools: Whiteboard (physical or virtual) for brainstorming. Dot-voting or priority charts to pick top problems. Templates or slides for the User–Need–Insight format. Document the final problem statements in a design brief or Confluence page.
Success Signals:

• The team can articulate the problem concisely in user-centric language (not as a technical spec).

• Stakeholders (everyone involved) agree on the problem and show no confusion about project direction.

• The problem statement addresses root causes (not just symptoms) of the issues found.

• A set of clear “How Might We” questions is ready to guide ideation.

• The team remains solution-agnostic (no one is pushing a fix before the problem is clearly defined).

Define Success Metrics (Usability, Equity, Adoption, Trust)

Purpose: Decide how you will measure the solution’s success from a human-centered viewpoint. This includes standard usability metrics and broader indicators like equity, trust, and adoption. Defining metrics early ensures accountability (“you can’t change what you don’t measure”).

When to Use: During Define phase, after problem framing but before finalizing designs. Revisit when project goals shift or new priorities emerge.

How to Run It:

• Identify Key UX Metrics: Consider Google’s HEART framework (Happiness, Engagement, Adoption, Retention, Task success). For example, measure Task Success (accuracy or time to complete case entry), Adoption (% of caseworkers using the system daily), Engagement (frequency of key actions, like updates per week), and Happiness (user satisfaction or CSAT scores).

• Include Equity Metrics: Ensure no user group is left behind. Track usage and outcomes by segment (role, region, demographics). For example, measure if any group has significantly slower task times. If you spot disparities (e.g. new hires slower than veterans), that signals a need to improve training or design for that group.

• Trust and Safety Metrics: Plan how to gauge user trust. Use surveys (e.g. “I trust the system to protect client data” on a 5-point scale) and quantitative indicators (number of privacy/security incidents, support tickets about data concerns). Consider how comfortable users feel submitting sensitive data (e.g. % opting into optional fields).

• Adoption & Training Metrics: Set goals for onboarding (e.g. % of users completing training, time to proficiency). Track feature adoption rates (which parts of the system are used or ignored).

• Set Targets/Baselines: Define initial targets or improvements. E.g. increase task success to 95% (from 80%), have ≥90% of staff logging in weekly, keep any user group’s task success within 10% of the best group (equity target), and aim for trust scores of 4/5 or higher. These targets guide design decisions.

• Validate with Stakeholders: Confirm these metrics align with business goals (they may add ROI or compliance KPIs). Ensure all metrics link back to user outcomes (e.g. adoption drives ROI).

Tools: HEART framework reference materials. Analytics planning tools (Salesforce dashboards, Google Analytics, or in-app telemetry). A table or spreadsheet listing each metric, how to collect it, and the target. Salesforce’s built-in adoption/usage reports can be leveraged if available.
Success Signals:

• A documented list of success metrics covering usability (effectiveness, efficiency), user satisfaction, adoption, equity, and trust is finalized.

• Team members can describe success in concrete user terms (e.g. “Filing a new case will take under 2 minutes on average”).

• There is a clear plan for collecting each metric (e.g. scheduled surveys for satisfaction, automated logs for usage).

• These metrics will serve as success criteria to monitor during and after rollout, demonstrating commitment to outcomes beyond just delivery.

Define Experience Principles (Accessibility & Ethics)

Purpose: Establish overarching design principles, with special focus on accessibility, inclusivity, and ethical concerns. These principles serve as “north stars” for design quality. For example, a principle could be “No user left behind,” meaning the design must work for users of all abilities and tech skills.

When to Use: At the end of Define phase, once the problem and metrics are clear. Use it to lock in key quality standards before design begins. This makes guidelines like WCAG compliance or trauma-informed language non-negotiable from the start.

How to Run It:

• Brainstorm Principles: In a short workshop, draft 3–5 design principles. They should be brief, inspiring statements. Draw from Salesforce’s values (Trust, Innovation, Equality) and what users need. Also consider any commitments (e.g. “Users should feel safe and in control at all times”).

• Address Accessibility: Include a principle like “Accessible by design.” State that the product will meet standards (WCAG 2.1 AA or legal requirements). Emphasize features like text alternatives for images, sufficient color contrast, and full keyboard navigation. Note that accessibility benefits all users, not just compliance.

• Trauma-Informed Ethos: Add principles based on trauma-informed design, such as “Design for emotional safety.” This means using gentle, clear language, offering undo/exit options, and avoiding blame (e.g. “Oops, let’s try that again” instead of scolding error messages). Ensure content warnings or safe words for sensitive information.

• Ethics and Privacy: If relevant, include “Ethical by design” or “Privacy first.” Commit to collecting only needed data and explaining its use. If AI or data analysis is involved, promise transparency (“We explain how automated decisions are made”).

• Finalize & Communicate: Narrow to 3–5 principles (too many dilutes them). Have the team agree these are mandatory guidelines. Publish them visibly (project wiki, posters). Refer to them during design reviews: ask “Does this design uphold our principles?”

Tools: Examples of principle lists (e.g. Microsoft’s Inclusive Design principles, WCAG checklists, trauma-informed guidelines from content design sites). A collaborative doc to draft and refine the wording.
Success Signals:

• The team has a concise set of principles explicitly mentioning accessibility and inclusion (not just generic platitudes).

• Team members reference the principles during design reviews (e.g. “This complies with our ‘no blame’ principle by using a helpful error message”).

• Early design iterations are refined based on these principles (e.g. simplifying an interface to give users more control).

• As development proceeds, there are fewer surprise fixes for accessibility or tone issues because the principles were applied from the start.

Design

In the Design phase, the team generates and refines solutions with continuous user feedback. This is a creative, collaborative phase – co-designing with users, building prototypes, and testing early. The following Plays ensure inclusivity and alignment with user needs.

Co-Design Ideation Sessions

Purpose: Involve users and stakeholders in generating solution ideas through hands-on workshops. Co-design taps into the creativity of end-users and front-line staff, ensuring concepts are grounded in real needs and diverse viewpoints. It also builds buy-in, since people are invested in ideas they helped create.

When to Use: At the start of Design, once you have clear problem statements and principles. Run co-design when brainstorming features or workflows (e.g. new case intake process). Also use it whenever design is stuck – new user input can spark fresh approaches.

How to Run It:

• Plan the Workshop: Gather 6–10 participants (designers, a few actual end-users like caseworkers or clients, SMEs, perhaps a developer or admin). Block 1–2 hours. Define a clear focus (e.g. “Improve the case intake experience”).

• Warm-up & Mindsets: Start with a quick creative exercise (e.g. “worst idea” challenge) to get people thinking outside the box. Remind everyone of the HMW questions and design principles. Encourage an atmosphere of empathy and courage (in Salesforce’s Relationship Design terms, bringing compassion to others’ perspectives).

• Divergent Ideation: Have everyone generate ideas individually first – for example, use “Crazy 8s” (sketch 8 ideas in 8 minutes) or brainwriting with sticky notes. If remote, use Miro/Mural. The goal is to produce many ideas without group pressure.

• Share & Build: Each person presents their top ideas. As a group, discuss and expand on them. The facilitator ensures non-designers’ voices are heard (often users hesitate to speak up, so validate their contributions). Combine similar ideas and note the most promising ones.

• Prioritize: Use dot voting or a simple matrix (impact vs. effort) to pick a few ideas to prototype. Ensure at least one selected idea directly came from users’ suggestions.

• Document Outcomes: Capture photos or screenshots of sketches/boards. List the top ideas with brief notes. Record the rationale (e.g. “Idea X was chosen because users said it would save them an hour per day”).

Tools: Sticky notes, markers, sketch templates for low-fi drawing. Digital: Miro/Mural, Google Jamboard, or Slides. Dots or digital dot-voting tools for prioritization. A timer to keep exercises focused.

Success Signals:

• Several solution ideas are produced collaboratively, and at least one user-generated idea is chosen for prototyping (showing true participation).

• Participants report feeling energized or positive (e.g. a caseworker says, “I loved being included; it’s exciting to see our ideas”).

• The ideas align with the earlier problem and principles (ensuring continuity).

• A diversity of ideas emerges (not just the designers’ thoughts – users brought new perspectives).

• Stakeholders gain confidence in HCD when they see engaged users driving the process.

Rapid Prototyping & Usability Testing

Purpose: Quickly turn top ideas into tangible prototypes and test them with real users. The goal is to iterate rapidly based on feedback, making sure the design works in practice before heavy development. Prototypes can be paper sketches or interactive mocks. Usability testing with these prototypes validates design decisions through actual user behavior.

When to Use: Immediately after ideation, with initial concepts. Continue to cycle: each time the design evolves or a major feature is added, prototype and test again. Also use usability testing whenever the team is undecided on a design choice – testing provides evidence.

How to Run It:

• Prototype Quickly: Choose an appropriate fidelity. Early on, hand-drawn storyboards or wireframes are fine. Later, build clickable prototypes in Figma, Adobe XD, etc. The prototype should allow users to attempt key tasks (e.g. creating a new case or a client logging in).

• Plan the Test: Write realistic scenarios (e.g. “You are a case manager assigning a follow-up task”). Plan tasks covering essential use cases. Sessions ~30–60 minutes. Recruit 5–8 test users (actual case managers or knowledgeable staff).

• Conduct Testing: Have a facilitator and note-taker. Ask participants to “think aloud” while using the prototype. Do not help them unless necessary. Observe where they hesitate or express confusion. Record their comments (e.g. “I expected this button to do that”). Also note emotional reactions (frustration or satisfaction).

• Include Accessibility: If possible, test with at least one user using assistive technology (screen reader, keyboard only). Even a non-interactive prototype can hint at accessibility issues (like focus order). This ensures early that the design is on track for users with disabilities.

• Debrief & Iterate: After each test, review findings with the team. Identify and prioritize usability problems (e.g. unclear navigation, confusing labels). Link issues to design principles (e.g. violating consistency or control). Make revisions to the prototype. Also note what worked well.

• Repeat: Run another test round with the updated prototype. Each cycle should reduce issues, improving task success and user satisfaction.

Tools: Prototyping: Figma/Sketch/InVision or even paper. Testing: screen-sharing software (Zoom, etc.) or a usability lab. Recording (with consent) for later review. Note-taking spreadsheets or tools (Airtable). Accessibility checkers (axe, Wave) for quick automated issues, combined with manual testing.

Success Signals:

• Usability testing uncovers issues the team hadn’t noticed, and these are fixed before development (e.g. a confusing form layout is improved after users got lost). This prevents costly rework.

• Over successive tests, users’ task success rates and completion times improve, showing the design is becoming intuitive.

• The team has confidence going into build because the design was validated by real users (“We’ve seen users complete these tasks successfully”).

• Feedback from diverse users (including one with accessibility needs) has shaped a more universally usable design.

• Stakeholders who observe tests see positive user reactions, reinforcing trust in the HCD approach.

Inclusive Design QA (Accessibility & Trauma-Informed Review)

Purpose: Conduct a thorough design review for accessibility and trauma-informed principles before development. This final design QA step catches any issues that might exclude or harm users. Fixing these in design is much easier than after coding. This play ensures the design is inclusive, respectful, and meets the established principles.

When to Use: At the end of Design phase, when high-fidelity designs or a design system is ready but before full development. Also run this QA at key points (e.g. a feature’s design is approved for build). Essentially, any time design is “ready for handoff,” do this check.

How to Run It:

• Accessibility Audit: Check the design against WCAG 2.1 AA standards (or your organization’s standard). Review color contrasts (>=4.5:1 for text), font sizes, and avoid conveying info by color alone. Ensure all interactive elements are visible and labeled. Verify that users could navigate via keyboard. Check that copy is plain language. Use tools (contrast checkers, screen reader simulators) to assist. Aim for perceivable, operable, understandable, robust design.

• Assistive Tech Simulation: If possible, have a team member try the design with a screen reader (or use a Figma plugin). This can reveal issues like missing alt text or confusing element order.

• Trauma-Informed Review: Revisit trauma-informed principles (safety, choice, transparency, empowerment). Critique the UI and content: Are any words potentially triggering or blaming? (Use supportive language: e.g. “Oops, let’s try again.”) Do users have control (undo/cancel)? Are privacy/security cues clear to build trust? Do users know what to expect (consistency)? For any sensitive info, provide warnings. Check cultural sensitivity in imagery and wording (avoid stereotypes, be inclusive).

• Diverse Reviewers: Involve an accessibility expert or someone not on the design team for a fresh look. If possible, have a representative user (or someone acting as one) preview the design and give feedback on any discomfort.

• Document and Fix: List any issues (e.g. “Contrast on main button is 3:1 – needs >=4.5:1”; “Confirmation dialog is abrupt – add reassurance or allow cancel”). Prioritize fixes. Adjust the design and note any fixes to pass to developers (like adding ARIA labels).

• Sign-off: Have the design authority or UX lead formally sign off on these checks. A checklist (accessibility, style guide, etc.) should be all green before saying “design is complete.”

Tools: WCAG quick reference or checklist. Automated contrast checkers (WebAIM, Stark). The trauma-informed principles list as a review guide. Bug tracker or task list to record any changes needed. Possibly run parts of design by a content designer or psychologist for trauma sensitivity.

Success Signals:

• The final design meets accessibility standards (e.g. text contrasts fixed, screen reader navigation flows logically). All critical accessibility issues are resolved pre-build.

• The UI and content conform to trauma-informed guidelines (supportive language, undo options present, no unexpected triggers). No last-minute “we forgot to fix X” surprises.

• Stakeholders or auditors sign off on the design’s accessibility and ethics.

• In later testing/pilot, there are minimal complaints about inaccessibility or insensitive content (we addressed them in design).

• Overall risk is reduced – the product is far less likely to exclude or distress users after launch.

Deliver

In the Deliver phase, the project moves through development, QA, and launch. The focus is on building the solution in line with the design and ensuring quality. These Plays emphasize inclusive testing, user training, and setting up feedback for go-live.

User Story Validation & Inclusive QA Testing

Purpose: As features are developed, verify that each meets user needs and quality standards. Embed HCD into Agile: testers and team members should confirm not only functionality but also usability and accessibility. Involving real users (or proxies) in acceptance testing catches practical issues automated tests might miss (e.g. a workflow that works but confuses a new user).

When to Use: Throughout the development sprints and especially in the official QA/UAT phase before launch. Whenever a feature is marked “done,” it should undergo this validation. Also use in any early user pilot or beta.

How to Run It:

• HCD Acceptance Criteria: For each user story, write acceptance criteria covering UX and quality, not just functionality. E.g.: “Case assignment feature – (a) User can assign a case (functional), (b) The assign action is easily found (usability – e.g. within 3 clicks), (c) Screen reader announces the assignment confirmation (accessibility).” This ensures developers know what “done” means.

• Pair QA with UX: Have QA testers or product owners test scenarios based on personas (realistic user stories). If possible, include a few actual end-users in UAT; their feedback is invaluable.

• Inclusive Testing: Include diverse conditions: test with different devices/browsers, assistive tech (keyboard-only navigation, screen reader). For example, ensure no element is unreachable via keyboard. If your user base is multilingual or multinational, check language and cultural appropriateness.

• Stress-test for Empathy: Simulate error scenarios: input mistakes, time-outs. Verify the system’s response is helpful and non-threatening. Error messages should guide users calmly (trauma-informed QA).

• Log Issues from User Perspective: When logging defects, describe impact on the user (“Keyboard user got trapped on popup, major accessibility issue”) rather than just “doesn’t match spec.”

• Regression Check: After fixes, re-test critical user journeys end-to-end. Ensure no new complexity was added and performance is still good (slow performance can hurt adoption as much as design flaws).

• Acceptance Sign-off: Use a UAT checklist with human-centered checks (e.g. “✅ New user completed onboarding without help,” “✅ All pages passed accessibility scan,” “✅ Content reviewed for tone”). The product owner or user rep signs off once it’s all green.

Tools: Test case management (Jira, Zephyr) with space for UX notes. Automated accessibility checkers (axe, Wave) and manual keyboard tests. Salesforce’s Lightning Experience Accessibility Checker for standard components. Session recordings for UAT observations. Feedback survey forms for pilot users.

Success Signals:

• QA/UAT uncovers UX or accessibility issues (e.g. confusing label) which are fixed pre-launch.

• All critical accessibility issues are resolved (no blockers left). Accessibility is treated as essential.

• Actual end-users in UAT sign off on usability (e.g. case managers in a pilot complete tasks with minimal questions).

• Each user story has evidence (notes or tester sign-off) that it meets user-focused criteria.

• After launch, there are very few usability-related support tickets, indicating the thorough validation was effective.

Training and Onboarding for Adoption

Purpose: Prepare and support users for the new system with empathetic training and onboarding. Even the best design needs proper introduction. This play focuses on enabling users with knowledge and trust, reinforcing why the change is beneficial, and using empathy in all communications.

When to Use: In the weeks leading up to launch and immediately after. Begin planning during development and execute right before users go live. Also apply this for new user groups or major updates (continuous onboarding).

How to Run It:

• Create Empathetic Content: Develop training that speaks users’ language and acknowledges their concerns. For example, start sessions by saying, “We know the old system frustrated you with duplicate work – here’s how the new one solves that.” This shows the solution was built from their feedback. Use scenario-based learning: teach features through actual tasks (e.g. “Let’s create a new case step by step”) rather than abstract demos.

• Multi-Modal Delivery: Combine live sessions (webinars or in-person demos), short video tutorials, one-page quick-reference guides, and hands-on practice labs. Ensure all content is accessible (caption videos, easy-reading handouts). Apply trauma-informed pacing: don’t overload users with too much at once. Use staged rollout or in-app tours (e.g. Salesforce guided tours) so users can explore at their own speed.

• Champions and Peer Support: Identify enthusiastic early adopters or pilot users as “champions.” They can help colleagues and share success stories (“This new workflow cuts my processing time in half!”). Set up a help channel (a Chatter or Slack group) where users can ask questions. Peer support builds community and trust.

• In-App Guidance: Use Salesforce tools (like In-App Guidance) to show tips or checklists inside the app. For example, display a welcome screen on first login highlighting key features and help links. Include feedback buttons (e.g. “Was this tip helpful?”) to gather instant input.

• Gather Feedback During Training: Encourage questions and feedback during training. Conduct quick surveys after sessions to gauge confidence (“Do you feel ready to use the new system?”). Use this input to tweak both the product (if possible) and support materials.

• Reinforce Over Time: Plan follow-up support. Send “tips and tricks” emails, hold a Q&A session a few weeks after launch to address common issues, and update training docs as needed. Learning is ongoing.

Tools: Leverage Salesforce’s myTrailhead or Trailhead Live to create interactive modules. Use video conferencing for live training (record them for later viewing). Maintain a knowledge base or FAQ. Optionally use gamification (badges for completion, leaderboards). Use surveys (Google Forms, Salesforce Surveys) to collect training feedback.

Success Signals:

• High training engagement (attendance or completion rates are strong), indicating users are invested in learning.

• Positive feedback: trainees report that the training prepared them well. Comments like “This was exactly about our daily work” show relevance.

• At launch, fewer frantic support calls or panicked reactions – users find help resources on their own or already understand basics.

• Adoption metrics in the first weeks meet targets (e.g. 80% of staff logging in weekly). If not, the team uses feedback to iterate (maybe scheduling extra sessions for lagging groups).

• Anecdotes like: a skeptical user says, “Actually, once I tried it, it’s not bad – thanks for the training!” (shows a convert to the new system).

Go-Live Feedback Loop Setup

Purpose: Establish mechanisms to collect user feedback and monitor metrics immediately upon launch and in the early use period. This ensures issues are identified and resolved quickly, and that insights feed into the next iteration. In other words, we don’t just launch and disappear – we continue the human-centered cycle by listening and adapting.

When to Use: In the days just before go-live (to set up) and for the first several weeks after launch. Also repeat for any major release or update.

How to Run It:

• Launch Support Team: Form a “war room” or dedicated support channel staffed by the project team (admins, a developer, designer/researcher, and support reps). Define how to collect feedback (a special email alias, a chat channel, a feedback form) and how often the team will review it (daily stand-ups or daily summary emails). Make sure all users know how to report issues or suggestions (“Here’s how to get help”).

• Proactive Check-ins: Don’t wait for complaints – reach out to users early. For example, call or message a few users in week 1 to ask, “How’s it going? Any questions?” Use in-app prompts after a user’s first session (e.g. “Rate your experience 1–5 and tell us what could be better”). This shows customers that their voices are important from day one.

• Monitor Metrics Live: Use the success metrics dashboard in real time if possible. Track usage (login rates, number of cases processed vs old system), performance (page load times), and any satisfaction measures (quick CSAT survey). Also monitor qualitative signals: volume/type of helpdesk tickets, Slack/Chatter feedback. If a metric dips (say supervisors aren’t using a new feature), investigate immediately (“Are they missing training, or is the UI unclear?”).

• Triage Feedback: As feedback comes in, categorize it: critical bugs to fix immediately, usability tweaks (quick changes), nice-to-have suggestions, and positive comments. Assign critical issues for hotfixes. Implement quick usability fixes (like text edits) to show responsiveness. Communicate changes: e.g. “We heard you – we’ve added a shortcut button to the dashboard.”

• Share Early Wins and Learnings: With the team and stakeholders, highlight successes (e.g. “We’ve had 100 cases created in 2 days, and users love the new navigation”). Also be transparent about issues (“We noticed some confusion with the report feature; here’s our plan to improve it”). Sharing feedback builds trust with all parties.

• Plan Next Iteration: Use collected feedback to prioritize the backlog for the next version. Re-evaluate success metrics: if some targets aren’t met (e.g. trust scores low), make concrete plans (maybe a design tweak or more training). This sets up the Evolve phase of continuous improvement.

Tools: Use Salesforce feedback tools (Chatter groups, Surveys). Set up a real-time dashboard (Salesforce or Google Analytics) for key metrics. Use Service Cloud or a ticketing system to flag “new system” issues. For internal coordination, use Slack or a spreadsheet to log anecdotal feedback. Schedule daily/weekly check-ins for the team.

Success Signals:

• A steady stream of user feedback is coming in (users feel comfortable reporting issues/suggestions).

• Early metrics look positive: user satisfaction is meeting goals and adoption is growing. Any areas lagging are identified and addressed quickly.

• The team fixes top user-reported issues rapidly, and communicates that back (“Thanks for reporting that; here’s the fix” – building trust).

• The project doesn’t just end at launch: there is a clear plan for continuous improvements, reflecting the customer-centric mindset. For instance, ongoing governance meetings still happen to review feedback and plan updates.

Evolve (Post-Launch)

In the Evolve phase, the product and processes are sustained and continuously improved. User needs and contexts change over time, so the team must keep learning and adapting. These Plays focus on ongoing metrics tracking, feedback loops, and knowledge sharing to ensure lasting success.

Measure Outcomes & Equity Regularly

Purpose: Continuously track the defined success metrics (usability, equity, adoption, trust, etc.) and evaluate whether the solution is delivering its intended results for all users. This keeps the team data-driven and accountable. Importantly, it helps ensure no user group is unintentionally disadvantaged over time.

When to Use: Start after a stabilization period post-launch (e.g. 1–2 months in) and then on a regular cadence (monthly or quarterly). Also do it after major feature releases.

How to Run It:

• Dashboard & Reports: Maintain a live dashboard of key metrics (e.g. average case resolution time, weekly active users, task completion rates, satisfaction scores). Break down metrics by segment (role, region, demographic) to spot inequities. For example, if one department’s usage lags, or if one user group has much lower satisfaction, flag it.

• Regular Reviews: Hold periodic reviews with the core team and stakeholders. Ask: Are we meeting targets? If not, why not? For any metrics off-track, drill down. For instance, if case completion time improved overall but got slower for a new user group, investigate that group’s workflow.

• User Feedback Channels: Keep feedback channels open beyond launch (ongoing surveys, user forums, or focus groups). Combine this qualitative feedback with the quantitative metrics for insights (e.g. low usage of a feature coupled with user complaints about it).

• Equity Checks: Periodically audit equity. Analyze if usage or success differs across groups (role, location, ability). If disparities persist, take action (maybe extra training, UI adjustments, or outreach to that group).

• Share Results: Report results to stakeholders. Celebrate successes (e.g. “We hit 95% task success – great job!”) and be transparent about areas to improve (e.g. “We still see lower adoption in Dept B; here’s our plan”).

• Adjust Targets: If certain goals are consistently exceeded, raise the bar. If some were too ambitious, recalibrate. Ensure metrics stay aligned with evolving business and user goals.

Tools: Continued use of analytics tools and surveys. Visualization dashboards (Salesforce, Tableau, or similar). Documentation of metric reviews and action items (Confluence or shared docs).
Success Signals:

• The team can clearly report current UX performance (e.g. “Current CSAT is 4.2/5, and 92% of staff use the system weekly – both above targets”).

• No user group is left behind unnoticed: any usage or success gaps are identified and closed over time. For instance, a lagging regional office sees usage improve after targeted support.

• Trust/satisfaction metrics remain stable or improve. Few data/privacy complaints occur.

• The team uses these measurements to drive changes (e.g. a dip in a metric leads to a prioritized fix), showing the feedback loop works.

Continuous Improvement & Iteration Planning

Purpose: Treat the product as an evolving system. Use all collected feedback and metrics to plan enhancements and fixes. Continue using HCD processes (mini–Discover/Design) for significant new work. Maintain governance and quality as the solution grows.

When to Use: Post-launch, on an ongoing basis (e.g. in each sprint or quarterly release). Whenever planning next features or improvements.

How to Run It:

• Maintain a Backlog: Continuously add user feedback, bugs, and improvement ideas into the product backlog. Include context (e.g. user quotes or segments affected) so future work stays user-focused.

• Co-Design New Features: For major new features or changes, re-engage users. Hold smaller-scale co-design or user review sessions to ensure enhancements meet their needs (e.g. if adding a reporting dashboard, involve end-users in its design).

• Sustain Governance: Keep the design authority or HCD steering group active (perhaps monthly post-launch). They should review proposed changes for alignment with experience principles and equity.

• Ongoing Quality Checks: Apply the same QA rigor to new work (accessibility audits, usability tests, trauma-informed reviews) as was done initially. Update training and help materials for each new feature.

• Knowledge Transfer: Document key design decisions, research findings, and rationale so new team members (or admins) understand why things are done a certain way. This preserves HCD knowledge over time.

• Celebrate & Communicate: When rolling out updates, highlight user-suggested improvements (e.g. “You asked for a shortcut here, we added it!”). Share usage successes to encourage continued feedback.

Tools: Same backlog/issue tracking (Jira, Trello) with tags for UX tasks. A UX research repository (Confluence, Airtable). Regular design reviews. Release notes or internal emails announcing user-driven changes.
Success Signals:

• The product continues to meet user needs; satisfaction remains high or improves as updates roll out.

• Users stay engaged and feel heard, continuing to provide input. Many new requests come from users who see their feedback implemented.

• No regressions: updates do not break accessibility or confuse users because HCD practices are maintained.

• The governance group actively guides improvements, and stakeholders note the consistent quality.

• In the long term, this project is seen as a model for human-centered success within the organization.

Lifecycle Retrospective & Knowledge Sharing

Purpose: Reflect on the HCD process itself: what worked well, what challenges arose, and how the process can improve. Share these lessons to grow the organization’s HCD maturity.

When to Use: At major milestones (e.g. 6–12 months post-launch) or at project end. Also after big releases or when the core team changes.

How to Run It:

• HCD Retrospective: Convene the core team and possibly key stakeholders. Ask: Which HCD activities were most valuable? (Users might point to co-design or testing.) What difficulties did we face? (Maybe recruiting users took too long.) What would we change next time? Record honest feedback.

• Gather User Voice: If possible, collect a few user testimonials about the process (e.g. “I felt really listened to by the team,” or “At first I was unsure, but the usability test convinced me this tool is great”). These highlight the human impact.

• Update the Playbook: Incorporate any new practices or insights into this playbook. For example, if remote workshops worked well, note them. If a specific tool was helpful, add it.

• Share with Peers: Present the project’s HCD journey (maybe a lunch-and-learn or an internal blog post). Highlight key outcomes and how HCD contributed (with data if possible). Be open about lessons learned (“Next time, budget more time for interviews”). This helps other teams.

• Recognize Contributors: Acknowledge team members and user collaborators who championed HCD (public shout-outs, awards, or case study features). Celebrating success reinforces a culture of design.

• Plan Future HCD Integration: Use insights to improve how future projects start (e.g. mandate early user research, allocate budget for accessibility review). Feed these improvements into project methodology documents or standards.

Tools: Retrospective formats (Start/Stop/Continue, etc.) on a board or Mural. Internal communication channels (wiki, Chatter, newsletter). Design community meetings (forums for UX designers to share stories).
Success Signals:

• The team can clearly articulate how HCD drove positive outcomes (e.g. increased adoption, fewer errors) and what could be done better.

• Lessons learned are documented and applied: future projects use these practices without reinventing the wheel.

• Team members report growth: those new to HCD gained skills they’ll use again; veterans feel validated by the results.

• The playbook and process documentation are updated with improvements, setting up the next team for success.

• Human-centered design becomes recognized as the default approach in the organization, with this project cited as an example of its value.

By following this Human-Centered Design Playbook through Discover, Define, Design, Deliver, and Evolve, Salesforce project teams can ensure their case management solutions (and similar workflows) are not only technically sound but truly effective, inclusive, and trusted by users.

The modular Plays provide structure but are meant to be adapted – teams should iterate on the process just as they iterate on the product. Remember: at the heart of HCD is a simple principle – keep the people (users, stakeholders, and our broader community) at the center of every decision. When done right, this leads to solutions that are adopted and loved, not just deployed, driving success for both the project and the mission it serves.