Most hearing people don’t sign - and no app covered all three jobs.
Existing apps cover slivers: one sign language, no real-time mode, no emergency path. Users stitch together three or more tools.
Sign Speak
Real-time sign language translation, built DGS-first.
An AI translation app that lets a Deaf student in Berlin order coffee, talk to a doctor and ask for help — without writing it down first.
Case study · Master’s project≈ 5 min read
Project at a glance
A complete product, not a concept screen.
0190+
Screens in a component-driven design system
025
Tabs, each doing one clear job
031.8
Final grade from a jury of three
Master’s project · UCA × BSBI 2025 ✦Academic project · no live usage data
The short version
01 · Problem 02 · What I did 03 · Result
Designed a DGS-first, 5-tab app: translate, emergency, community.
A research-first foundation, UX laws mapped to decisions, and an AI layer that always shows its confidence.
90+ screens, a full design system and a working prototype.
Graded 1.8 by a jury of three professors. An academic project, so there are no live usage metrics.
My role
Solo designer, research to prototype.
A Master’s project, defended in front of a jury of three. I used Claude for literature synthesis and audit structuring and Figma AI for faster variants — every design decision stayed mine.
- 1
Research synthesis
Literature, population data, EU reports and a competitive audit.
- 2
Information architecture
Five tabs, defined before any screen.
- 3
AI interaction design
Confidence, latency and failure states, designed on purpose.
- 4
Design system
Tokens, type ramps and components for 90+ screens.
- 5
Prototype
End to end in Figma, from onboarding to SOS.
01The problem
Communication is still gated by who else happens to sign.
470 million Deaf and hard-of-hearing people — a projected 900 million by 2050. Most hearing people don’t sign, and most public spaces have no interpreter.
Four problem dimensions, four design responses
- 01470M people, 900M by 2050
WHO: roughly 1 in 10 people will live with disabling hearing loss. Existing apps treat them as a niche.
DGS-first strategy, designed for the German Deaf community first
- 02Zero apps do all three jobs
Hand Talk, ProDeaf, Signily, Google Interpreter Mode — none combine real-time DGS, an emergency SOS and a learning community.
One 5-tab app, each tab doing one job clearly
- 03Emergencies leave no voice option
Typing a name, condition and location while in distress is a failure mode that maps to real harm.
One-tap SOS: pre-written status, confirm-and-send
- 04DGS ≠ ASL
German Sign Language has its own grammar and regional variation. ASL-default tools strip out nuance.
DGS by default, ASL opt-in, confidence on every translation
02My research approach
A research-first foundation, openly limited.
Four research threads shaped the product before a single screen was drawn.
Disclosure
I couldn’t recruit Deaf participants for primary interviews within the project window. Findings and personas are synthesised from peer-reviewed research, public Deaf-community forums and published reports — all cited. Personas are composites, not real interviewees.
R.01
Secondary literature
Mis-triage of Deaf patients, interpreter shortages in EU emergency services, lip-reading fatigue.
R.02
Population data
WHO and WFD reports — 470M today, ~900M by 2050, and a persistent education gap.
R.03
EU communication gaps
The EUD barriers report informed the DGS-first decision and the emergency flow.
R.04
Competitive audit
Four apps audited. None combined real-time DGS, emergency support and a learning hub.
From “another translator” to a three-job product.
The research reframed the project into translate, emergency and community — built AI-translation-first. Everything that follows is downstream of that reframing.
SourcesWHO 2023WFD 2021EUD 2022McKee 2015Sharma & Gupta 2022
03Personas
Three users. Three risks. One product.
Composites synthesised from the research. Each one maps to a distinct top risk — and a distinct design response.
Klaus
A doctor talking past him.
Big tap targets, high contrast, one-tap SOS, a speech-to-text card to hand a doctor.
Gideon
Typing his name to a paramedic.
Pre-written status, one-tap SOS and an offline fallback for the SOS path.
Emma
Mis-triage in lectures.
DGS as default, real-time captions in lectures, chat that preserves signing tone.
“Give me a tool that respects DGS as a real language - and doesn’t make me prove I deserve to be understood.”
Shared job-to-be-done across all three personas. Quotes are illustrative — paraphrased from cited sources, not transcribed from interviews.
04Information architecture
Five tabs. One clear job each.
The IA was defined before any screen design and held through every iteration. DGS is the default; ASL, BSL, ISL and others are opt-in.
- 1Translate
Sign↔Text in real time, with confidence shown. About 70% of session time.
- 2Learn
Practice cards, saved translations and community-sourced signs.
- 3Connect
Chat that preserves signing tone; group chat for Deaf-led communities.
- 4SOS
One-tap emergency, for the moment speech is not an option.
- 5Profile
Trusted contacts, pre-written status and accessibility preferences.
Five UX laws → five concrete decisions
Listing UX laws on a portfolio is easy. Showing where each one made a decision is the hard part — and it made the choices defensible to a non-design jury.
Visual direction first, then paper
Three commitments locked the visual language early — teal as a trust signal, high contrast everywhere, no decorative complexity. Then paper wireframes, to lock hierarchy and navigation before any visual decision.
05AI capability design
Designing for AI, not around it.
Sign Speak runs on a real-time translation model. That model has confidence, latency and failure modes — and the UI surfaces all three on purpose.
- 01
Confidence is never hidden
The pill turns teal at 90%+, amber below it with a “Best guess:” prefix. Users always see what the model is sure about — and what it isn’t.
- 02
Name the model’s state
“Detecting…” instead of a spinner. The interface narrates what’s happening instead of asking users to trust a black box.
- 03
Design the failure path first
Camera blocked or hand out of frame → a named status and a retry CTA. The error state was wireframed before the success state.
- 04
Latency is a design constraint
A sub-400 ms render budget for text-to-sign, mapped from the Doherty Threshold. Model speed is a UX requirement.
Sign → Text, the core flow
Open the camera, sign, read the caption — one-handed, with the confidence score visible. The caption is the answer, not another step.
- 1
High confidence. Teal pill at 90%+; the caption renders directly.
- 2
Low confidence. Amber pill and a “Best guess:” prefix; re-sign or override.
- 3
Error state. Named status plus retry — never a silent failure.
06Screen-level decisions
Main flows, and the reasoning behind each.
01 · onboarding
It sets how the app treats the user - before any translation.
- Three identity options — Deaf, Mute or None — set accessibility defaults across the whole app.
- Sign language defaults to DGS with auto-detect, not a 10-language menu.
- Getting this screen right means fewer adjustments later.
02 · text → sign
For hearing speakers who don’t sign - without learning to.
- A hearing person types; the translation runs the other way.
- A DGS sign animation renders so the Deaf user reads it natively, not as text.
03 · speech → sign
For hearing people who’d rather speak than type.
- Hold to speak; the translation runs through voice instead of text.
- For contexts where typing isn’t practical — hands full, on the move.
04 · learning hub
Where the community teaches the app new signs.
- Daily practice cards keep vocabulary warm without a teacher.
- Saved translations build a personal phrasebook.
- Deaf users contribute regional variants the model wouldn’t know.
05 · SOS setup & profile
The work that has to be done in calm.
- Trusted contacts get the alert and location automatically.
- Status messages are written once, in calm — the live flow is confirm-and-send.
- Haptics, large type and reduced motion travel with the user.
07Emergency design
One tap, no words.
Designing for the moment speech is not an option.
- 01
A 1-second hold, not a tap
A tap risks accidental triggering. One second forces intent without slowing a real emergency.
- 02
Thumb-reachable on every screen
The SOS pill sits in the thumb arc — never blocked by the keyboard or system bar.
- 03
Pre-written status, written in calm
“I am Deaf — please face me when speaking” is written once. The live flow becomes confirm-and-send.
- 04
Location, opt-in by default
Coarse location attached for paramedic dispatch; easy to disable per contact.
- 05
High contrast + haptic confirm
WCAG AA on every state, and a long haptic pulse confirms the alert — feedback Deaf users can feel.
08Design system & accessibility
Tokens are vocabulary, components are sentences.
Like a sign language, a UI has rules. Defined once, reused everywhere — so the 91st screen costs the same as the 1st.
Rules that kept the system honest
- 01No decorative complexity
If it doesn’t carry meaning, it doesn’t ship.
- 02No ASL-default copy
DGS-first, ASL as opt-in.
- 03No compose-and-send in emergencies
Pre-written plus confirm, only.
- 04No animation without a WCAG pass
Motion is checked like colour is.
- 05No colour-only meaning
Colour is always paired with shape, label or pattern.
09Outcome
What the project delivered.
An academic project — so no live usage numbers. Here’s what was built, and how it was judged.
90+
Screens in a component-driven system
5
Tabs, one clear job each
3
Jobs in one app — translate, SOS, community
1.8
Final grade from a jury of three
Real-time DGS, emergency SOS and a community hub - in one app, where the market had none.
The component system kept 90+ screens consistent as a solo designer. Mapping UX laws to decisions made the work defensible to three professors. The 5-tab navigation mirrors familiar chat apps — zero relearn cost.
Master’s project · UCA × BSBI 2025 · prototyped end to end in Figma.
