Case Study · WS Audiology · 2025
Privacy & Consent System
Sole Designer · iOS & Android · GDPR & EAA · Shipped to production
A global hearing care app needed a compliant, accessible consent architecture from scratch: four consent types, dependency logic, moving legal requirements, RTL support, and a European Accessibility Act mandate.
WS Audiology ships hearing-care apps in over 125 markets. Legal requirements vary by country, and consent decides which features run, where, and on which device. The system had to manage that without exposing the complexity to the user.
Sole designer
Owned the full design scope across all rounds, working with PM, legal, and engineering from requirements through post-launch QA.
What I owned
- Consent dependency map
- Screen design (iOS and Android)
- RTL and multilanguage layout
- Accessibility specs (VoiceOver and TalkBack)
- Engineering handoff
- Post-implementation QA
Who I worked with
- PM and legal (consent scope and requirements)
- Engineering (build, QA, and accessibility fixes)
How I approached it
Constraints shaped the design
The app ships as a companion to a certified hearing aid. That classification brings mandatory consent requirements that vary by market, legal framework, and data use case. GDPR applies across European markets. Medical device regulations layer on top. Some countries allow patient data to be used for audiological research; others prohibit it.
Which market applies is determined by the country where the hearing aids were fitted, fetched automatically from the device. If the fetch fails, the user selects manually. That choice is permanent and can't be changed, because the country determines which consents apply. A legal requirement, not a UX one.
Four consent types resulted from this, each with different skip behaviour, dependency rules, and market applicability. Operational Consent gates Data Sharing: decline one and the other locks, because those cloud features become unavailable. Data Collection only appears where local regulations permit research data use.
The design work started with mapping those relationships and understanding which constraints were fixed by legal, which varied by market, and which could be shaped.
Moving requirements and dependency complexity
Consent count reduction
The argumentThis wasn't a passive design decision. At multiple points in the project the consent count grew. Pushing back required a coherent argument about user behaviour and legal strategy. The final count of 4 types reflects what I argued for, not what was initially scoped.
From 5–7 planned consent types down to 4 shipped.
Four consent types
Before designing any screens, I mapped the four consent types and the relationships between them. The sequence is fixed: T&C and Privacy Notice first, then Operational, then Data Sharing and Data Collection. The dependency between Operational and Data Sharing is the critical design decision: decline Operational and you lock Data Sharing, because the cloud features Data Sharing relies on are no longer available.
Data Collection is country-conditional: it only appears if the country of fitting allows data collection for research purposes. France, for instance, shows it. Other markets don't.
Declining Operational consent triggers a confirmation dialog listing which features will stop working. Transparent about consequences, not coercive. The choice can be changed at any time in the Privacy tab.
Edge cases
The initial spec assumed a first-run, online user with a paired hearing aid. For a global app with an older user base, that's a narrow slice. I designed these as first-class flows.
Skip for now
Data Sharing and Data Collection can both be skipped at setup. The app works without them, so blocking setup for non-mandatory consents would only increase drop-off.
- User taps "Skip for now." Data Sharing or Data Collection is deferred. The user continues to the home screen. No progress bar. They're out of the setup flow.
- Feature access triggers re-prompt: When the user tries to access a feature that requires the consent, it re-appears as a bottom sheet. Skip is still available.
- Forcing all consent decisions at setup is the default pattern and the top source of drop-off: Contextual re-prompting keeps the app compliant while surfacing consents when they're relevant. Legal agreed.
Country not fetched from hearing aid
The user selects their country manually from a list. A warning makes clear the choice is permanent and can't be changed. The country determines which consents apply. That's a legal constraint, not a UX one.
Offline state
T&C loads from cache and can always be shown. Further consents need a connection. A banner explains why the user is blocked, with an option to return to privacy settings later.
Privacy tab
Consent doesn't end at setup. Users can review and change their consent preferences at any time through the Privacy tab in the app. I designed three key states for this view.
When Operational consent is accepted, all toggles are active and features are fully available. When Operational is declined, Data Sharing appears visually locked with an inline explanation (not hidden), so the user understands why it's unavailable and has a direct path to resolve it ("Go to Operational Consent"). A third state handles consents that were skipped: the toggle shows a pending state, and tapping it triggers the contextual re-prompt.
The reversibility rules are asymmetric: all optional consents can be changed at any time. T&C and Privacy Notice acceptance cannot be revoked: this is a legal requirement, not a UX choice, and the UI makes that distinction visible.
When Operational consent is declined, Data Sharing is visually locked with an inline explanation, not simply hidden. Users understand why a toggle is greyed out and what they need to do to unlock it. Hiding creates confusion; explaining builds trust.
Two consent flows
The first-setup flow walks a new user through all four consent screens in sequence, from T&C through to Data Collection. The reinstall flow is different: the app detects a server-side consent record and presents a review screen instead of forcing full re-acceptance. Returning users shouldn't be treated as strangers.
RTL and language switching support
RTL support was part of the original handoff, not a follow-up. Every consent screen was designed with a mirrored layout: right-aligned text, flipped structure, reversed button placement. LTR and RTL frames went to engineering at the same time.
Language switching sits in the top corner of every consent screen. Available languages reflect the official languages of the country of fitting, where the app supports them. T&C and Privacy Notice show all supported languages before country detection since they load first. Users can switch at any point before accepting. This is a legal requirement: consent must be in a language the user understands.
Designing for language switching also uncovered the screen reader bug later caught in QA: the consent text displayed correctly in the switched language, but the screen reader voice stayed in English. That edge lives at the intersection of localisation and assistive technology, and needed a dedicated engineering fix.
VoiceOver and TalkBack
The EAA required full screen reader support from day one. Hearing care users are the primary audience, and many rely on assistive technology. Accessibility had to be specced into every screen before engineering touched it.
I authored VoiceOver and TalkBack annotations for all consent screens in Figma, mapping reading order with numbered callouts tied to a legend. The system was later adopted across the wider WSA design team.
- Reading order: Numbered read order for every element on each consent screen, including state changes as consents unlock.
- Focus on entry: Focus lands on the screen headline on arrival. The back button is announced correctly, and the language selector is included in the focus sequence.
- Skip focus: Long-form consent text (T&C, Privacy Notice) is divided into sections so users can jump ahead rather than swipe through every line.
- Control roles: Native role assignments for toggles and checkboxes, including a locked-state announcement when a consent is gated by a dependency.
- Language switching: Screen reader voice must match the consent language after the user switches. This was specced, then verified and fixed in real-device QA.
QA
Legal timeline constraints ruled out pre-release user testing. Validation ran as a structured review with each stakeholder group instead: legal checked for compliance, engineering for implementability, and the PM for business risk. Each round fed changes back into the dependency map before the screens were revised.
The sharpest findings came from real-device accessibility QA after implementation. Two issues surfaced that no simulator or code review would have caught.
- Components and screen selections: Many components, including country and language list selection, had TalkBack and VoiceOver problems that only appeared on device. Fixed with engineering post-QA.
- Screen reader language mismatch: After switching consent language, the screen reader kept reading in English. The content was correct visually, but the voice wasn't. Only detectable on a real device with a real screen reader.
Delivered
- Full consent system, production-ready: 4 types, dependency logic, edge case handling, RTL, and multilanguage switching on every consent screen.
- EAA accessible, validated on real devices. VoiceOver and TalkBack specifications authored and QA'd with real assistive technology, not simulators.
- Two critical screen reader bugs caught before release: Identified and resolved in post-implementation QA.
- Consent count reduced from 5–7 to 4: Through design rationale and stakeholder advocacy, not scope creep acceptance.
- Dependency map adopted as the primary engineering artifact: Used throughout the project as the main communication tool between design and engineering.
What I'd do differently
Freeze requirements before committing to screens
If I started again, I'd push for a frozen requirement baseline before beginning screen design, agreeing with the PM and legal on stable scope before committing to any UI. The multiple redesign rounds were manageable, but each was partly avoidable with more structured upfront alignment.
Test the skip for now moment with real users
I'd push for at least one round of task-based testing at the "Skip for now" moment: to verify that users understood skip is temporary, not a decline. That distinction is central to the pattern, validated through design logic rather than user testing. It's the one thing I'd want to test before shipping.