Defined a Repeatable Shared-Device Trust Model for Global Luxury Retail
Client:
Confidential
Role:
Product Designer
Sector:
Luxury Retail
Year:
2026
Due to NDA constraints, I cannot share explicit product screens. This case focuses on project scale, decision model, and operational rollout.
An international luxury retail client was running CRM on shared iPads across 150+ boutiques worldwide, so advisors needed fast access to sensitive profiles without exposing customer data in front of clients. I designed a shared-device trust model with contextual step-up authentication, explicit session ownership, and reliable handover rules. The goal was to keep premium service flow smooth while making security behavior consistent, testable, and compliant across a global boutique network.
The Core Problem
The main risk was not only login friction. The deeper risk was trust failure in both directions: customers lose confidence if data appears on the wrong screen, and advisors lose confidence if security prompts interrupt every interaction. That risk was larger in an international retail operation, where many boutiques, advisors, and shared devices had to follow the same rules. Standard enterprise authentication patterns were too rigid for boutique service rhythm, while lighter patterns were not enough for audit requirements. The core problem was to secure shared devices without breaking in-store continuity or creating location-by-location security behavior.
Constraints
User constraint: advisors had to switch quickly between client interactions and keep context.
Service constraint: conversations could not pause for unnecessary verification.
Technical constraint: session state had to stay aligned across CRM, identity, and audit systems.
Security constraint: sensitive actions needed stronger verification at the right moment.
Operational constraint: multilingual continuity had to survive advisor handovers.
Scale constraint: the trust model had to stay consistent across the global boutique network without creating store-by-store security behavior.
Key Decisions and Trade-offs
I treated authentication as part of service flow, not as a separate login module.
I decided to trigger step-up checks only on risk-tier events, because blanket prompts damage service rhythm, resulting in lower runtime friction during normal interactions.
I decided to prioritize smartphone NFC as the primary step-up method, because it balanced security strength and store practicality, resulting in a deployable path across locations.
I decided to define fallback routes, including QR recovery, because real stores face device and network variability, resulting in higher continuity when preferred methods fail.
I decided to formalize session ownership and handover semantics early with engineering, because ambiguous state creates security and service defects, resulting in clearer implementation boundaries.
I decided to standardize risk tiers, session ownership, and handover rules across the service model, because local interpretation would weaken rollout consistency, resulting in a repeatable trust pattern for the global boutique network.
Authentication Decision Matrix
Approach | Pros | Cons | Decision |
|---|---|---|---|
QR Login | Reliable | Introduced friction during service | Fallback |
Biometrics | Fast and familiar | Shared-device ambiguity and GDPR concerns | Discarded |
Wearable NFC | Premium seamless interaction | Infrastructure complexity | Future opportunity |
Smartphone NFC | Familiar, scalable, secure | Requires onboarding | Selected |
Alternatives explicitly rejected:
Full re-authentication at every profile switch, because it over-protected low-risk actions and slowed service.
Biometric-first shared ownership on device, because policy accountability was weak in multi-user contexts.
Main trade-off: slightly higher advisor onboarding effort in exchange for smoother runtime behavior and stronger audit control.
What I Owned
I owned service-flow and authentication interaction decisions across the shared-device journey. I aligned product, engineering, and cybersecurity on risk tiers, verification triggers, and handover behavior. I also owned the policy-to-interface translation so security requirements became concrete interaction rules, test cases, and fallback behaviors instead of abstract policy statements.
What Changed in the Product/System
The product moved from ad hoc security handling to a repeatable trust framework for shared devices.
Sensitive profile actions now trigger contextual step-up verification instead of blanket prompts.
Session ownership and handover states became explicit and auditable.
Fallback authentication paths are available when primary verification fails.
Multilingual continuity is preserved across secure advisor handovers.
Security events now align with audit requirements without breaking front-stage service.
The trust model became a repeatable pattern that can scale across a global boutique network without redefining security behavior store by store.
This changed daily behavior: advisors know when verification appears, why it appears, and how to continue service if fallback is required.
Outcomes
Accidental exposure risk decreased because ownership and handover states became explicit.
Service rhythm improved because low-risk actions no longer triggered unnecessary checks.
The team gained a reusable trust pattern that can support more consistent rollout across the global boutique network (directional).
The team gained reusable trust patterns for future identity-sensitive retail workflows.
New Costumer
Update Customer Information
Before / After: Authentication in Service Context
Dimension | Before (QR-dominant flow) | After (Smartphone NFC primary flow) |
|---|---|---|
Advisor-customer interaction | Visible pause to scan and verify | Tap-and-continue interaction with lower visible friction |
Security trigger behavior | More procedural checks in front-stage moments | Contextual step-up only on sensitive actions |
Service continuity | More interruptions and recovery steps | Smoother continuity across handovers |
Direction | Functional but less elegant flow | Security-consistent and service-consistent flow |
What I'd Improve Next
Next iteration would add adaptive risk tuning by store profile and interaction type, plus deeper fallback analytics. I would also test whether frequent low-risk scenarios can use lighter verification without increasing exposure. That next iteration would further balance security strictness with in-store service continuity.