Click to Try The Demo
01
Research & Discovery
ISS Connect is a conversational AI assistant built for international students at the University of Washington. It helps them navigate U.S. immigration regulations — F-1/J-1 visa compliance, OPT/CPT work authorization, SEVIS records, and international travel — through natural, accessible language, available 24 hours a day.
Powered by the ChatGPT API and grounded in official UW ISS and USCIS.gov sources, the assistant bridges the gap between overwhelmed students and overstretched advising staff — reducing anxiety and preventing legal missteps.
My role on this project was closest to a Product Designer: I defined the problem space through research, shaped the solution through design decisions, and owned the ethical framework that governs the system's behavior.
8,000+
UW international students
24 / 7
Instant availability
5
Ethical design principles
02
Problem Statement
"I just want to know if I can travel while on OPT... but there are so many open tabs and no one can give me a straight answer."
— Student storyboard — the moment ISS Connect was designed to intercept
International students at UW face a structural information gap. Immigration rules are high-stakes, highly situational, and written in legal language — yet ISS advisor appointments take 3–5 business days, and government websites are dense and hard to navigate quickly.
In the absence of reliable real-time help, students default to peer advice and Reddit. This is not just inconvenient — a misunderstood visa rule can result in status violation, deportation, or denial of re-entry.
The framing that drove every decision
Before designing anything, I had to answer one question: what role should this product play?
Not a lawyer. Not an advisor replacement. Not a knowledge base.
The role I settled on was a knowledgeable peer — someone who knows the rules, is honest about limits, and always knows when to say 'go ask the advisor.' Every decision in this project flows from that definition.
03
Research & Problem Understanding
Sources
UW ISS Website — primary policy and procedure documentation
USCIS.gov — federal immigration law and regulations
NAFSA International Student Advising Guidelines — industry standards
Key Findings
Two compounding problems emerged.
First, the subject matter is genuinely complex: visa rules are situational, overlapping, and frequently updated. 'Can I travel?' has different answers depending on visa type, OPT status, and whether the EAD card has arrived.
Second, the existing help infrastructure is structurally misaligned with the pace of student decision-making. Students need answers in hours, not days. When the official channel is unavailable, they do not wait — they find an unofficial one.
Design Thinking
Why research shaped the ethics, not just the features
Understanding the real-world consequences of wrong answers in this domain raised the bar for what 'helpful' means.
A helpful answer is not just one that addresses the question — it is reliably accurate, calibrated in its confidence, and honest about its limits. This recognition became the foundation of the ethical framework I built alongside the product design.
04
User Persona
Design Thinking
Building empathy means modeling the emotional state, not just the demographic
Aisha represents a specific emotional state: high-stakes anxiety paired with self-consciousness about asking for help. This dual vulnerability — legal risk and the social risk of appearing uninformed — shaped the entire tone of ISS Connect. Non-judgmental, jargon-free, always closing with a clear next step. Designing for her emotional state was not a soft concern alongside the functional requirements. It was a functional requirement.
05
Design Challenges & Trade-offs
Designing an AI assistant for legally sensitive information surfaced five fundamental tensions. None of them have clean resolutions. What follows is an account of how I identified each tension, what I considered, and what I decided — and why.
1
Helpful vs. safe — where to draw the line
The fundamental tension is that users come because they need answers, but in this domain, giving a confident wrong answer is more dangerous than giving no answer. AI systems naturally incline toward responses that feel complete and authoritative. In a legal context, that inclination is a liability.
The mistake to avoid was drawing a single universal line. The right threshold varies by the irreversibility of the consequence if the answer is wrong. 'How long does OPT processing take?' — getting this wrong costs inconvenience. 'Can I leave the country right now?' — getting this wrong could mean denied re-entry.
The approach I settled on: consequence-based risk tiering. Low-risk questions get direct answers. Medium-risk questions get answers with source citations and a note to verify before acting. High-risk questions get directional guidance only, with a clear recommendation to confirm with an ISS advisor. The harder follow-on question — who maintains this tiering as policy changes? — I documented as an explicit operational responsibility in the system specification.
2
Users do not ask questions the way you expect
You can build a well-structured intent library and still fail if you have designed for how you think users should ask rather than how they actually do. Real users say: 'I have to go home next month but my stuff isn't sorted yet, what should I do?' — no visa terminology, no recognizable keywords, but a genuine urgent immigration question underneath.
The core trade-off: coverage vs. accuracy. A system designed to handle anything will give vague or incorrect answers in edge cases. A system designed to only handle what it can handle well will decline more — but what it does answer, it answers correctly. For this user group, I chose accuracy over coverage. The consequence of a wrong answer is too high.
When the system cannot confidently match intent, it asks one clarifying question — presented as a choice, not an open field. 'Are you asking about travel before OPT starts, or during OPT while waiting for your EAD?' is far more useful than 'Can you describe your situation in more detail?' The one-question limit was deliberate: a multi-step clarification flow feels like an interrogation to an already-anxious user.
3
Trust calibration, not just trust building
Getting users to trust the product is relatively straightforward — friendly tone, official citations, clean design. The harder problem is calibrating that trust: ensuring users trust the AI exactly as much as its actual capabilities warrant, no more. Over-trust is the more dangerous failure mode. A user who treats the AI's answer as definitive without checking sources is exposed to real harm.
The approach: embed trust calibration into the language of every response, not as a disclaimer layer. Concretely — never say 'you need to' (say 'according to UW ISS policy, students are generally required to'); never state policy as fact without attribution; use hedge language proportional to actual uncertainty; always name the source so the user can verify independently.
The trade-off with fluency: heavily hedged language makes responses feel less natural. I resolved this by reserving strong hedge language for genuinely high-stakes situations, not applying it uniformly. Used selectively, it signals real uncertainty rather than becoming background noise that users learn to ignore.
4
Designing for users in an anxious state
Most product design implicitly assumes a user who is calm, has time, and will read what you put in front of them. ISS Connect's users are often none of these things. They are stressed, under time pressure, and dealing with a topic where they feel cognitively outmatched. Standard UX assumptions break down.
The key implication: information hierarchy has to do real work. The first sentence of every response must stand alone as a useful answer — a user who reads only the first sentence should be better informed than before they asked. The rest — source link, nuance, caveats, booking suggestion — is for users who have the cognitive space to continue.
This inverted pyramid creates a trade-off with accuracy: the first sentence must be simple, so it cannot capture every exception. My resolution: the first sentence states the general rule, the second immediately flags the most common exception. The user is never misled by the simplification — it is always visibly qualified. The deeper limitation: you cannot reliably test for this in a standard usability session. You cannot recreate genuine anxiety in a research environment. The persona and storyboard were proxies, not the real thing.
5
The system's knowledge will become outdated
Immigration policy changes. Processing times fluctuate. A response accurate in March may be wrong in September. For a static FAQ, this is a manageable content maintenance problem. For a conversational AI that users interact with as if it has current knowledge, it is a trust and safety problem. The specific danger: the system will give outdated information with the same apparent confidence as current information.
Two parallel strategies. First: for high-volatility information — OPT processing times, fee amounts, specific deadlines — the response never states the number directly. It links to the authoritative source where the current number lives, with a note that this figure changes regularly. The AI provides context and interpretation; the live source provides the fact.
Second: I separated the content layer from the conversation layer. The prompt does not hardcode time-sensitive facts — it references external content sources. When those sources update, the system's responses update with them. But the most important decision: acknowledging that neither strategy removes the need for a human to own content maintenance. No architecture solves this. I documented it as an explicit operational requirement: someone must review the content layer against current policy on a defined schedule.
The three questions I asked before every trade-off
Across all five challenges, I found myself returning to the same three questions before making a decision.
Queation
What to Consider
What is the asymmetry of the error?
If this decision is wrong, who bears the cost — user or product? Is it reversible? Decisions where a wrong call causes irreversible harm to the user should default to the more conservative option.
Who maintains this decision over time?
A design choice that requires ongoing human attention to remain valid is only as good as the operational structure behind it. Make the dependency explicit, not assumed.
What does this look like for the most vulnerable user?
Not the average user — the most anxious, least domain-familiar, most likely to take the AI's output at face value. If that user would be misled, the decision is wrong regardless of how it performs for everyone else.
06
Design Decision
Decision 1 — The product's role
The single most important decision was defining what ISS Connect is and is not. Not a lawyer, not an advisor replacement, not a knowledge base. A knowledgeable peer: knows the rules, is honest about limits, always knows when to send you to a human. This role definiti
Decision 2 — Dawg: mascot over digital human
Three options evaluated: photorealistic digital human, plain chat interface, branded mascot. The digital human scored high on warmth but risked users mistaking it for a real person — a serious trust miscalibration. A plain interface avoided this but sacrificed the emotional connection that makes students comfortable asking embarrassing questions.
Dawg — a cartoon husky in UW school colors — is clearly non-human, which makes the AI nature of the interaction transparent. It borrows institutional credibility from the UW brand. And it provides emotional warmth without the ethical risks of a photorealistic avatar. The transparency was not just ethical hygiene — it directly supports trust calibration.
Decision 3 — Intent mapping before prompt writing
Before writing a single line of system prompt, I built a structured utterance-intent library: mapping real student questions to the underlying informational need. Prompt engineering, for a product designed for a specific user group, is a form of interaction design. The precision with which you define the system's identity, scope, tone, and escalation logic determines the quality of every response. A vague prompt produces a vague product.
Decision 4 — The fallback as a trust mechanism
The fallback response — 'This situation is complex; I recommend scheduling an appointment with an ISS advisor' — was not a failure state. It was a deliberate trust-building mechanism. A system that claims to answer everything erodes trust the first time it gets something wrong. A system honest about what it cannot handle builds a different kind of trust: users learn that when it does give an answer, they can rely on it.
