UI / UX Design
System-wide UI design and end-to-end UX — from consent flows and sign-in journeys to dashboard surfaces, grounded in privacy-first principles.
Case study
ConsentKeys
Privacy-first authentication
A platform for pseudonymous sign-in and delegated consent — so users can authenticate and transact without oversharing personal data.
Product designFrontend engineeringSystems thinkingPrivacy-first
0%
Attack surface reduction
0+
Auth flows prototyped
0
Core product surfaces
0
Cross-functional reviews
01 — Overview
What is ConsentKeys?
ConsentKeys is an authentication layer that brokers trust between people and services using consent-aware, pseudonymous flows. Users prove who they are without shipping unnecessary PII to every integration — keeping identity data closer to its source.
Auth flow
02 — Problem
The PII problem
Classic authentication optimises for convenience, not data minimisation. Email-first sign-in, rich profile payloads, and long-lived tokens create large PII surfaces.
01
PII is duplicated across every integration — each new app creates a new breach surface.
02
Users have no meaningful, revocable consent primitives after sign-up.
03
Compliance pressure grows while user trust erodes from repeat data incidents.
03 — Solution
Pseudonymous auth
Share the minimum proof required for the interaction. Delegate consent where appropriate. Keep sensitive identifiers out of application databases by default.
| Traditional auth | ConsentKeys |
|---|---|
| PII collected at sign-in | Pseudonymous identifiers only |
| Central honeypot of user data | Minimised data exposure |
| Hard to revoke consent | Delegated, revocable consent |
| Breach = full identity profiles | Breach = limited correlation |
04 — My work
Contributions
Frontend Development
Built responsive product surfaces across auth, consent, and recovery — including the dev portal and public-facing marketing site.
DevOps
Managed CI/CD pipelines, environment configuration, and deployment infrastructure to keep the platform reliable across releases.
System Architecture
Shaped trust boundaries between clients, the identity broker, and relying parties — keeping PII out of application databases by design.
OIDC Integrations
Led OIDC integration work with prospective partners and customers — scoping flows, mapping scopes, and validating token exchange patterns.
Integration Docs
Authored developer documentation covering integration guides for multiple stacks — making it straightforward to adopt ConsentKeys in existing apps.
Developer Portal
Designed and built the developer portal — API reference, quickstart guides, and sandbox tooling for teams evaluating the platform.
High Availability
Architected for resilience under high demand — load balancing, failover strategies, and uptime guarantees across critical auth paths.
Database Management
Managed schema design, migrations, and query optimisation — ensuring identity and consent data is stored securely with minimal exposure.
05 — Challenges
What was hard
01
Privacy vs. conversion
Balancing frictionless onboarding with strict data minimisation — every affordance had to earn its place in the flow.
02
Explaining the invisible
Making trust legible without exposing implementation details users should not need to understand.
03
Ecosystem fit
Designing for partners and developers as first-class users alongside end-customers.
06 — Outcome
Results
01
Cohesive narrative
A story from landing to dashboard that reads "privacy-first", not "privacy bolt-on".
02
Shippable surfaces
Production-ready UI for auth, consent, and recovery — scaling across breakpoints and states.
03
Shared vocabulary
Design and engineering aligned on threat- and user-centric language for sensitive states.
07 — Learnings
What I took away
01
Privacy UX is a product discipline — the hardest problems are communicating trust, not implementing cryptography.
02
Owning the full stack — design, frontend, infra, and docs — forces you to make decisions that actually hold together under real usage.
03
OIDC is deceptively simple on paper. Real-world integrations surface edge cases around scope negotiation, token lifetime, and partner expectations that no spec fully anticipates.
04
Good developer documentation is a product in itself. Friction in a quickstart guide costs more in adoption than a missing feature.
05
High availability is a design constraint, not an afterthought — it shapes schema choices, API contracts, and deployment topology from day one.
06
Building a developer portal sharpens your empathy for the people integrating your product. If you struggle to explain it, the abstraction is probably wrong.
07
Database design for identity systems is unforgiving — schema decisions made early become load-bearing walls you cannot easily move later.
Get in touch
Interested in privacy tech
or want to collaborate?
See the live product or reach out directly for collaboration and speaking opportunities.