Project Husky — Bridge Bot
“You can’t design a bot that feels human without first understanding the humans it’s for.”
Project Husky is a civic technology initiative developed through Femmecubator and Open Civic Tech, for UC San Diego, to address a critical access gap: the inability of families of children with autism to navigate free educational resources due to procedural complexity, fragmented information, and language barriers.
This case study documents the research foundation, conversational design process, and Voiceflow implementation behind Bri — an AI chatbot designed to guide families through the special education system with clarity, empathy, and cultural accessibility.
The Problem
2M+
children in the US have autism (CDC)
Yet most of their families cannot access the resources they are entitled to — not because those resources do not exist, but because nobody made them navigable. Parents navigating diagnosis, IEP timelines, school district meetings, and legal rights are doing so alone, in jargon, with no guide. The question that surfaces again and again is the same:
“Why can’t someone just tell me what to do next?”
Project Husky was built to answer that.
My Role
As the Conversational AI Architect and UX Researcher on this project, my responsibility was the research foundation and conversational infrastructure that made the chatbot functional and human-centered. A clear distinction existed between team responsibilities:
Design team
Visual interface and wireframes
Voiceflow architecture and UI
Landing page design
My scope
User research and domain mapping
Bot persona and tone-of-voice guidelines
Dialogue flow writing
CDI framework application
Full Voiceflow build
HIPAA-aligned content decisions
The design team built the interface. My work determined who Bri is, how she communicates, and what she knows.
The Research
The research phase was not a clean, linear process. It was iterative, uncertain at times, and required constant recalibration. What follows is not just what was found, but how it was found, why certain paths were taken, and where the process had to pivot.
01 — The System
Understanding a world most people don’t know exists
The starting point was straightforward: verified government websites, federal education terms searched one at a time, and conversations with teammates — including a team lead with a direct connection to someone inside the special education system. That connection became an invaluable grounding point throughout the research.
Why mapping — and not just reading
Approaching IEP forms, eligibility criteria, and federal education law from the perspective of a first-time observer — someone who had never encountered this system before — the experience was genuinely overwhelming. That disorientation became data. If a researcher with time, focus, and no emotional stakes found this difficult to parse, a parent receiving unexpected news about their child’s future would find it nearly impossible. Mapping the system was not a methodological preference. It was a response to lived confusion.
What almost went wrong
The early risk was going too deep into legal and clinical language — IDEA, FAPE, LRE, eligibility thresholds — without stepping back to ask what a parent actually needed to understand on day one. The pivot was recognizing that the goal was not to become an expert in special education law. The goal was to understand it well enough to translate it for someone who is scared, overwhelmed, and receiving life-changing information about their child for the first time. That reframe changed the depth and tone of everything that followed.
“Along with not fully understanding the system myself, it made sense that parents wouldn’t either — and unlike me, they are also processing unexpected news and worrying about their child’s future at the same time.”
02 — The Resources
Everything existed. Nothing was usable.
Going into this phase, the assumption was that autism resources existed and were reasonably accessible. What the research revealed was more specific and more troubling: the resources were there, but they were written for systems, not for people.
What the resources had
Accurate information
Legal detail
Comprehensive coverage
What the resources were missing
A human entry point
Plain language
Emotional acknowledgment
A clear next step
This finding shaped the entire design of Bri’s knowledge base — not just what she knew, but how she said it and in what order.
03 — The Users
Finding patterns in real experience
User research came from two sources: a special education teacher who provided the institutional perspective, and a parent with direct lived experience navigating the system for their child. While the sample was small, the insight density was high — and the patterns that emerged were consistent with everything the desk research had already pointed toward.
What was expected vs. what was actually hard
Building the initial persona and conducting desk research was manageable. The harder challenge came in a less expected place: determining the boundaries of what the chatbot could and could not do. It was not enough to design a chatbot — it had to be the right chatbot, for a specific population, with specific constraints. It could not diagnose. It could not give medical advice. It could not offer false reassurance or overpromise outcomes. Every boundary was a design and ethical decision, not just a technical one.
Three themes surfaced consistently
01
Cognitive overwhelm
Too much information, organized for the wrong audience, with no clear entry point
02
Emotional isolation
Parents navigating a complex system while processing difficult personal news — alone
03
Need for guidance
Not more resources — a clear, trustworthy voice that could say: here is your next step
From Research to Bri — The Connection
The three themes did not simply describe user pain points. They revealed something deeper: the emotional reality of a parent who has just learned their child has autism is not confusion about a bureaucratic system. It is the overwhelming, instinctive drive to do everything possible for their child — and the terror of not knowing where to start.
“Bri was not designed for someone filling out a form. She was designed for a parent who would move mountains for their child but does not know which mountain to climb first.”
That parental instinct — the urgency, the love, the fear of failing their child — is the emotional core of every design decision made about Bri. Here is how each research finding translated directly into a design choice:
Parents felt cognitively overwhelmed by the volume and complexity of information
→
Bri delivers one step at a time. Never a wall of information. Always a clear, singular next action.
Parents felt emotionally isolated — processing fear and uncertainty alone
→
Bri leads with empathy before information. Every response validates before it informs.
Parents needed someone to tell them exactly what to do next
→
Bri ends every response with a clear action step and a follow-up question to keep moving forward.
Parents were receiving life-changing news about their child’s future
→
Bri never overpromises, never gives false hope, and never goes beyond her educational scope. Trust is the foundation.
Families span language, literacy, and cultural backgrounds
→
Plain language and inclusive design were the baseline — not an enhancement. Every utterance was written for the most vulnerable reader first.
Developing the Bot Persona — Giving Bri a Personality
The development of Bri’s persona was the most critical phase of the research process. Every subsequent design decision derived from what the research revealed about user needs. The following CDI framework tools were applied — each shown alongside how it was applied specifically to this project.
CDI Bot Persona Worksheet — template
Bot Persona Worksheet
Defined Bri’s core identity, personality traits, communication style, and behavioral constraints. Established her as empathetic, clear, and supportive — a care companion, not a clinical tool. Education-only scope and HIPAA-aligned boundaries were set here.
CDI Conversation Design Canvas — template
Conversation Design Canvas
Mapped the overall conversational experience at a systems level — identifying key user scenarios, emotional states, and decision points the dialogue would need to address across the full user journey.
CDI Conversation Design Process — template
Conversation Design Process
Applied the required, happy, and detailed path framework to structure how conversations would flow across three scenarios: the minimum viable path, the ideal frictionless experience, and the comprehensive path for users needing full guidance.
CDI Conversation Design Worksheet — template
Conversation Design Worksheet
Structured each conversation node with intent, user utterances, bot responses, button options, and flow direction — creating a scalable, reviewable record of every dialogue decision made.
CDI Sample Dialogue Sheet — template
Sample Dialogue Sheet and Sample Dialogue
Drafted and pressure-tested actual conversation exchanges prior to building in Voiceflow. Ensured tone, pacing, and response length were appropriate for the target audience before any technical build began.
Bri’s response architecture — applied to every dialogue node
Empathy first
→
Information
→
Clear action step
→
Follow-up question
The Voiceflow Build
Once the dialogue framework was established, the full conversational system was constructed in Voiceflow — encompassing intent taxonomy, utterance variation mapping, dialogue flow logic, fallback handling, and knowledge base integration across all flows.
The knowledge base was developed from autism toolkits, government publications, IEP guides, and subject matter expert input — all rewritten in plain language and restructured for conversational delivery prior to integration.
Voiceflow — dialogue flow architecture
Bri — welcome screen and intent taxonomy
Testing and Iteration
Validation occurred through internal team walkthroughs and structured feedback from a special education teacher. Three key revisions resulted:
Response length
High-information flows were shortened to reduce cognitive load during emotionally difficult moments.
Legal clarity
IEP timeline language was clarified to accurately reflect procedural steps and legal rights.
Emotional validation
Explicit validation language was added at key decision points throughout the conversation flow.
Bri — empathy response to diagnosis
Bri — guided next step selection
Bri — IEP information flow
Bri — detailed IEP breakdown with action steps
Reflections and What’s Next
This project underscored that designing for emotional complexity demands the same level of methodological rigor as designing for technical complexity. The majority of the work resided in content definition — mapping emotional states, ensuring utterance coverage, and calibrating tone — which is precisely where the research process proved most essential.
Complete Spanish support
Foundational infrastructure was established but not fully implemented. Given the equity mission of the project, bilingual functionality is the most immediate development priority.
Partner with school districts
Direct integration with school district communication systems would position Bri at the point of need, significantly expanding reach and institutional credibility.
State-specific IEP architecture
National expansion to serve 2M+ families requires a knowledge base that accounts for procedural and legal variation across state systems.
Swati Singh 