Project Husky — Bridge Bot

“You can’t design a bot that feels human without first understanding the humans it’s for.”

---

SKILLS LEARNED ON THIS PROJECT

Voiceflow  ·  CDI Framework  ·  Notion  ·  Figma

---

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.

---

Impact

---

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:

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.

Why mapping — and not just reading

Approaching IEP forms, eligibility criteria, and federal education law from the perspective of a first-time observer — the experience was genuinely overwhelming. That disorientation became data. If a researcher with time 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 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 — it was to understand it well enough to translate it for someone scared, overwhelmed, and receiving life-changing information about their child for the first time.

“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.

What the research revealed was specific and troubling: the resources were there, but they were written for systems, not for people.

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 and a parent with direct lived experience. While the sample was small, the insight density was high — and the patterns were consistent with everything the desk research had already pointed toward.

What was expected vs. what was actually hard

The harder challenge came in determining the boundaries of what the chatbot could and could not do. It could not diagnose. It could not give medical advice. It could not offer false reassurance. Every boundary was a design and ethical decision, not just a technical one.

Three themes surfaced consistently

---

From Research to Bri — The Connection

The three themes 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.”

Research finding	Design decision
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.
Families span language, literacy, and cultural backgrounds	Plain language and inclusive design were the baseline — not an enhancement.

---

Developing the Bot Persona — Giving Bri a Personality

The development of Bri’s persona was the most critical phase. Every subsequent design decision derived from what the research revealed about user needs. The following CDI framework tools were applied:

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.

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.

Conversation Design Process (Required, Happy and Detailed Paths)

Structured how conversations would flow across three scenarios: the minimum viable path, the ideal frictionless experience, and the comprehensive path for users needing full guidance.

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.

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

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.

---

Testing and Iteration

Validation occurred through internal team walkthroughs and structured feedback from a special education teacher. Three key revisions resulted:

---

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.

Live app: bridge-app-dev.netlify.app  ·  Organization: opencivic.tech/projects/husky