Yale Smart
Doorbell

How might we reduce 5 unlock steps to 1, using facial recognition, without compromising security or privacy?

My contribution

User Research
Journey Mapping
Interaction Design
Accessibility Review

Tools

Figma
Protopie

Duration & Status

3 weeks · Solo · 2026
Conceptual (not affiliated with Yale)

Yale Smart Video Doorbell
01Design Review
02User Research
03User Journey
04Design Decisions
05Accessibility
06Validation

Design review

Why: To understand how the current product works and where the friction lives

Yale’s smart doorbell needs 5 steps to unlock: press doorbell, wait for notification, open app, check video, tap unlock. The flow was built for visitors — not residents at their own door.


User research

Why: To understand real behaviour, not just assumed pain points

I spoke with 8 smart lock users. Informal conversations, directional insights.

Finding 1: Most people bypass their smart lock

6 out of 8 use a physical key or PIN more than the app. The smart feature is too slow at the door.

Finding 2: Security anxiety is about letting others in

Nobody worried about their own entry. The stress was remote-unlocking for others.

Finding 3: Nobody wants fully automatic unlock

Every person rejected auto-unlock — even if perfect, it felt "wrong." The confirmation step isn't a compromise. It's the feature.

Key Takeaway

People want the door to know who they are. They don't want it to decide for them. The design must preserve the feeling of choice.


User journey

Why: To map the current flow against the proposed flow and quantify the improvement

Current flow mapped against the proposed redesign.

Current Flow
5 Steps
Press doorbell
Wait for notification
Someone opens app
Checks video feed
Taps unlock
30-90 sec
Proposed Flow
1 Step
Approach door
Camera recognises face
Tap unlock on doorbell
< 5 sec

Two paths: known vs unknown

Recognised · Household
Camera detects face
On-device match confirmed
"Hi Yalcin" + unlock button
Tap to enter
Unrecognised · Visitor
Camera detects face
No match found
Standard ring + notification
Video call → owner decides
Owner decides remotely

Design decisions

Why: To explain the reasoning behind each choice, backed by research findings
Decision 01: Based on Research Finding 3

Confirmation tap, not auto-unlock

Every participant rejected auto-unlock. One tap preserves agency: "I chose to open the door."

→ Outcome: 1 step instead of 5. Faster and users feel in control.
ApproachFace matchTap unlockOpenUnder 5 seconds
Decision 02: GDPR & Privacy Requirement

On-device processing, no cloud

All face matching on-device using embeddings, not stored photos. Nothing leaves the hardware.

→ Outcome: Privacy-first architecture. Trade-off: only household members can enroll.
Doorbell hardwareCameraCaptures faceProcessorMatches embeddingsNo data sentCloud server
Decision 03: Security Requirement

Liveness detection required

Without liveness detection, a photo could trigger unlock. Depth sensing adds 1-2 seconds — users read this as "thorough," not slow.

→ Outcome: Perceived thoroughness, not delay. The pause built trust.
Real face3D depthDepth check+1-2 secVerified ✓Photo2D flatNo depthRejectedBlocked ✗

Accessibility & inclusive design

Why: A biometric system must work for everyone, not just the ideal user

Facial recognition creates real exclusion risks. I designed fallback methods for every scenario where the primary flow might fail or be inappropriate. No user should be locked out because they can't or won't use face recognition.

Children under 13

GDPR restricts biometric processing for minors. Face + mandatory PIN. Parents set time-based entry rules.

Elderly members

Face recognition is opt-in only. PIN pad and physical key remain as parallel entry methods.

Temporary guests

Time-limited access codes via app. Auto-expire and are logged. No biometric enrollment needed.

Delivery workers

Never trigger facial recognition flow. Standard video call to homeowner for remote decision.

Low light & weather

IR LEDs for night. Below confidence threshold → automatic fallback to PIN entry.

Emergency / duress

Silent alarm PIN: opens door normally while silently alerting emergency contacts.


What I'd validate next

Why: Honest about what's unproven. This is a concept, not a shipped product.

Would people actually enroll their faces? Even with on-device processing and full transparency, biometric enrollment is a big ask. I don't have real opt-in data.

Does one-tap feel secure enough in context? Prototype testing in a controlled environment isn't the same as standing at your front door at night. Physical context changes how security feels.

Can current doorbell hardware support this? On-device face matching with liveness detection requires significant processing power. I haven't verified chipset capabilities or battery impact.


Reflections

The hardest UX problems are emotional. Everyone understood auto-unlock could work. They still didn't want it. Designing for the feeling of control mattered more than speed.

GDPR as a constraint pushed better decisions. On-device processing, explicit consent, instant deletion — regulations forced privacy-first architecture that also builds trust.

Let's talk

I'm looking for interesting design challenges.