Security that stays out of the way
A shared-device clienteling app needed real verification without turning a luxury conversation into a login screen — so I designed the security as part of the service, not a wall in front of it.
Client
Loro Piana (LVMH group)
Role
Service design
Year
2025
Status
Client proposal · not shipped

At a glance
- Problem
- Protect client data without disrupting the consultation
- Design decision
- Verify only at sensitive moments
- Delivery
- Service flows and technology evaluation
Design brief · shared-device security
The question
How do you make authentication reliable without making it visible?
In a boutique, the advisor and the customer share one screen carrying client profiles. Enterprise authentication — asking constantly — works in an office and fails here: every prompt interrupts the relationship the product exists to support.
Handoffs can happen in any order
- Advisor AStarts or consults a session
- CustomerAdds details when needed
- Advisor BResumes or starts again
Text alternative: A compact network shows one shared iPad in the centre, connected bidirectionally to Advisor A, the customer and Advisor B. The connections indicate that handoffs may happen in any order. Each person can start, consult or contribute to a store interaction; the device remains the persistent shared surface.
Design model · ordinary vs. sensitive moments
The approach
I treated authentication as part of the service flow rather than a login module in front of it. Most of an interaction carries no risk and should ask for nothing; verification concentrates on the few moments that genuinely warrant it, and the rest of the time it stays invisible.
That reframing is what made the model buildable: instead of one blanket rule, the service has ordinary moments and sensitive ones, and only the second kind pays a cost. I worked this out with the cybersecurity team — my side was the service design and the flows, theirs was the security architecture. Where the two met is where the design actually happened.
We also looked at the physical side of the problem: what an advisor carries or wears, and how a verification gesture can feel deliberate and elegant instead of bureaucratic. The resulting Technology Evaluation used a Luxury UX Score — elegance of gesture, boutique fit, and impact on speed, discretion and naturalness — as design research rather than product selection.
Service moments · conceptual reconstruction
Security is present in the service, not in front of it.
Three moments from the proposal — opening a shared session, building the profile together, and thedeliberate step-up before a protected action — show what the model looks like once it's actually running.
AI-generated conceptual reconstruction of a tender proposal. It illustrates service moments, not a shipped Loro Piana experience.
SERVICE BEAT
The shared session moves with the conversation.
The advisor introduces the device without turning it into the subject of the service.
SERVICE BEAT
The profile is built together, in context.
The customer can contribute directly while the advisor remains present in the consultation.
SERVICE BEAT
Verification appears only before a sensitive action.
The step-up remains a deliberate advisor gesture, not a recurring interruption for the customer.
Tender research · technology evaluation
The best security gesture was the one that felt like part of the service.
Luxury UX Score combined the elegance of the gesture, its fit with an assisted boutique interaction, and its effect on speed, discretion and naturalness. This was an evaluation of proposed technologies, not a product decision or a deployed system.
NFC wearable
Micro-unlock across the journey
Elegant gesture · hands free · immediate
Requires a dedicated accessory and provisioning
Bluetooth LE proximity
Auto-switch between advisors
No gesture · invisible when it works
False activations can select the wrong advisor
Passkeys / FIDO2 via Okta
Start-of-day authentication
Secure · passwordless
Does not handle shared-tablet micro step-ups
Employee ID in Apple Wallet
Fallback for protected moments
Elegant · secured by Face ID
Introduces a second device and a less fluid gesture
Companion iPhone app
Daily tablet authorization
Simple daily login
Blocks the flow if the advisor has no phone
iPadOS Lockdown / Single App Mode
Device-risk reduction
Stable · no added advisor burden
Not an unlock method; adds no luxury-experience value
Okta Push
Fallback step-up
Secure confirmation
Network-dependent interruption and a cumbersome gesture
QR code
Last-resort fallback
Always available
Slow and visibly non-luxury
Text alternative: Eight proposed technologies are compared on Luxury UX Score. NFC wearable scores 10 and is preferred; Bluetooth LE scores 9 as an extension; passkeys score 7.5; Apple Wallet scores 7 as fallback; companion app scores 6; single app mode scores 5; Okta Push scores 4 as fallback; QR code scores 1 as last-resort fallback.
Tender output · redrawn
Verification appears only where the service becomes sensitive.
These canvases preserve the proposal's decisions, bypasses, branches and recovery paths. They explain the service-design model; they do not describe a system Loro Piana adopted or shipped.
Create a client profile
FIG. LP.01
- Advisor enters the shared session
- Is the session available?
- Yes → build the profile
- No → verify once → session becomes ready → rejoin the profile path
- Build the client profile together
- Customer reviews and confirms
- Step up before the protected save
- Profile is created
- Shared session closes
Text alternative: The advisor enters a shared session. If unavailable, one verification restores it and rejoins the main path. Advisor and customer build and review the profile together, then a protected commit creates the profile and closes the session.
Complete a protected change
FIG. LP.02
- Advisor resumes the shared session
- Is the session available?
- Yes → continue ordinary service
- No → verify once → session becomes ready → rejoin ordinary service
- Continue ordinary service
- Is a protected action selected?
- Change contact details
- Update customer consent
- Review sensitive history
- Step up before the action
- Record responsibility
- Action completes
Text alternative: The advisor resumes ordinary service, using one recovery branch only if the session is unavailable. Contact details, customer consent and sensitive history form three protected branches that converge on verification, responsibility recording and completion.
Scope · tender proposal, unshipped
What I owned, and where it stands
I designed the service flows and the model — not the UI; there wasn't a screen system yet, which is precisely why it was interesting. The client validated the concept and development hadn't started when my involvement ended, so there is nothing shipped to show and no adoption data to quote.
The overview diagram distills the idea; the two redrawn proposal flows document the service-design output in greater depth. They preserve the decision and fallback logic while removing technical detail, and show what we proposed during the tender — not a solution Loro Piana adopted or shipped.