Skip to main content

Alberto Giorgi / Product Designer

Alberto Giorgi/ Product Designer

Selected work

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

Loro Piana boutique display with dressed mannequins in a warm, sand-toned interior; the Loro Piana crest and wordmark are centred in the image.

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

Shared iPadPersistent device
  • Advisor AStarts or consults a session
  • CustomerAdds details when needed
  • Advisor BResumes or starts again
The security model has to work independently of who is holding the device.

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.

TechnologyJourney roleExperience gainConstraint / riskScore
Recommended

NFC wearable

Micro-unlock across the journey

Elegant gesture · hands free · immediate

Requires a dedicated accessory and provisioning

10

Bluetooth LE proximity

Auto-switch between advisors

No gesture · invisible when it works

False activations can select the wrong advisor

9

Passkeys / FIDO2 via Okta

Start-of-day authentication

Secure · passwordless

Does not handle shared-tablet micro step-ups

7.5

Employee ID in Apple Wallet

Fallback for protected moments

Elegant · secured by Face ID

Introduces a second device and a less fluid gesture

7

Companion iPhone app

Daily tablet authorization

Simple daily login

Blocks the flow if the advisor has no phone

6

iPadOS Lockdown / Single App Mode

Device-risk reduction

Stable · no added advisor burden

Not an unlock method; adds no luxury-experience value

5

Okta Push

Fallback step-up

Secure confirmation

Network-dependent interruption and a cumbersome gesture

4

QR code

Last-resort fallback

Always available

Slow and visibly non-luxury

1
The NFC wearable was the preferred direction for its discreet, hands-free micro-unlock, with Wallet and Okta Push as fallbacks.

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

Create a client profileA branching proposal flow with a session recovery path that rejoins profile creation before customer review, protected commit, profile creation and session closure.EntryAdvisor enters theshared sessionDecisionSession available?RecoveryVerify onceSystemSession becomes readyAdvisor + customerBuild the clientprofile togetherCustomerCustomer reviews andconfirmsProtected momentStep up beforeprotected saveSystemProfile is createdEndShared session closes
  1. 01 · EntryAdvisor enters the shared session
  2. 02 · DecisionIs the session available?
    • Yes → build the profile
    • No → verify once → session becomes ready → rejoin the profile path
  3. 03 · Advisor + customerBuild the client profile together
  4. 04 · CustomerCustomer reviews and confirms
  5. 05 · Protected momentStep up before the protected save
  6. 06 · SystemProfile is created
  7. 07 · EndShared session closes
An unavailable session takes a one-time recovery branch and rejoins the main path before profile creation, customer review and protected commit.

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

Complete a protected changeA branching proposal flow in which ordinary service stays quiet while three protected actions converge on one verification, responsibility record and completion path.EntryAdvisor resumes theshared sessionDecisionSession available?RecoveryVerify onceSystemSession becomes readyQuiet pathContinue ordinaryserviceDecisionProtected actionselected?Protected triggerChange contact detailsProtected triggerUpdate customerconsentProtected triggerReview sensitivehistoryProtected momentStep up before theactionSystemRecord responsibilityEndAction completes
  1. 01 · EntryAdvisor resumes the shared session
  2. 02 · DecisionIs the session available?
    • Yes → continue ordinary service
    • No → verify once → session becomes ready → rejoin ordinary service
  3. 03 · Quiet pathContinue ordinary service
  4. 04 · DecisionIs a protected action selected?
    • Change contact details
    • Update customer consent
    • Review sensitive history
  5. 05 · Protected momentStep up before the action
  6. 06 · SystemRecord responsibility
  7. 07 · EndAction completes
Ordinary service stays quiet; three protected triggers converge on one deliberate step-up and a responsibility record.

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.