Overview
TRACE is a connected physical–digital access concept designed to make permission, identity, and service interactions clearer across personal and organizational touchpoints. The experience connects a tactile physical object with individual and staff-facing digital interfaces, creating a coordinated system for access, handoff, recovery, and support.
Rather than treating identity verification as the end of the experience, TRACE separates recognition from authorization and creates a shared permission state across every touchpoint.
One system, multiple touchpoints
TRACE connects a tactile physical object with individual and organizational digital interfaces into one coordinated access system, spanning physical, digital, and service context.
Individual Experience
Personal App
Visibility and permission control.
Physical Credential
Personal, tactile access interface.
Shared Permission
Identity · Access · Session · Control
Organization Dashboard
Operational context and request visibility.
Human Support
Assistance and exception recovery.
Service / Organization
Individual Experience
Personal App
Visibility and permission control.
Physical Credential
Personal, tactile access interface.
Shared Permission
Identity · Access · Session · Control
Organization Dashboard
Operational context and request visibility.
Human Support
Assistance and exception recovery.
Service / Organization
Access breaks down when physical, digital, and service touchpoints are designed separately.
The problem is not simply that existing products are inconvenient or inaccessible. Access depends on identity, authorization, permission, state, timing, and context — conditions that are not always equally visible or understandable to everyone involved, and accessibility has to be part of that system logic rather than a separate feature.
01 — Fragmented Touchpoints
Physical, personal digital, organizational, and service interactions may operate as disconnected moments. Users should not have to coordinate the system themselves.
02 — Invisible Permissions
Access depends on identity, authorization, permission, state, timing, and context — conditions that are not always equally visible or understandable to everyone involved.
03 — Fragile Handoffs & Recovery
The experience becomes most vulnerable when something changes, a permission becomes unavailable, a handoff is incomplete, or an interaction cannot continue normally without assistance.
Design the system around continuity, not individual touchpoints.
Ecosystem
TRACE is defined around roles rather than individual personas — the people and systems that participate in an access interaction, and what each of them needs from it.
Ecosystem roles
Individual
Needs visibility, control, confirmation, and understandable feedback, along with a way to recover when something goes wrong.
Organization / Staff
Needs authorization visibility, oversight, and shared context, along with the ability to assist or handle exceptions.
Shared Access System
Connects both roles through identity, permission, status, handoff, and recovery.
End-to-end journey
The experience is described as a lifecycle rather than an app flow — the stages an access interaction moves through regardless of which touchpoint is in front of someone.
01Prepare
Understand context
02Approach
Enter environment
03Identify
Recognition begins
Recognition ≠ Authorization
04Access
Review + control
05Confirm
Verify outcome
06Recover
Resolve exception
Context established
Presence detected
Recognition created
Permission active
Session recorded
Recovery context
01Prepare
UserUnderstand context
SystemContext established
02Approach
UserEnter environment
SystemPresence detected
03Identify
UserRecognition begins
SystemRecognition created
Recognition ≠ Authorization
04Access
UserReview + control
SystemPermission active
05Confirm
UserVerify outcome
SystemSession recorded
06Recover
UserResolve exception
SystemRecovery context
Key insights
01 — Shared Visibility
Access works better when permission and state are legible to everyone involved — the response is one shared permission model across personal and organizational touchpoints.
02 — Multimodal Feedback
Critical states should not depend on a single sensory or interaction channel, so feedback is supported across physical, visual, digital, and assisted interactions.
03 — Recovery Is Part of Access
The quality of the experience depends on what happens when access does not proceed normally, so recovery and human support are designed as part of the primary experience.
Design principles
01 — Make Permission Visible
Permission remains visible while access is active, instead of disappearing after approval.
02 — Support More Than One Mode
Critical states are communicated in more than one way, so understanding does not depend on a single channel.
03 — Design the Handoff
Physical and digital touchpoints are designed to reflect the same state, so moving between them feels continuous.
04 — Plan for Recovery
Failure and alternate paths are designed as part of the product from the start, not added afterward.
One permission model, multiple touchpoints.
TRACE is designed as one permission system expressed through multiple interfaces. The individual and the organization interact with different tools, but every touchpoint references the same underlying shared access state.
Individual Experience
Personal App
- Visibility
- Permission control
- Session context
Physical Credential
- Tactile action
- Ambient feedback
- Local confirmation
Shared Permission State
Organization Dashboard
- Requests
- Shared visibility
- Operational status
Human Support
- Assistance
- Exception handling
- Recovery
Organization / Service Experience
Individual Experience
Personal App
- Visibility
- Permission control
- Session context
Physical Credential
- Tactile action
- Ambient feedback
- Local confirmation
Shared Permission State
Organization Dashboard
- Requests
- Shared visibility
- Operational status
Human Support
- Assistance
- Exception handling
- Recovery
Organization / Service Experience
Permission is treated as an explicit state that can be reviewed, paused, resumed, revoked, or closed—not as a one-time access event.
- Individual LayerPhysical Access Interface · Personal App
- Shared Access StateIdentity · Permission · Session · Status · Handoff · Recovery
- Organization LayerOrganization Access Dashboard
- Service / Human LayerStaff / Assisted Support
The role of each touchpoint
Physical Access Interface
Tangible interaction, orientation, confirmation, and multimodal feedback.
Personal App
Permission visibility, status, context, control, and recovery.
Organization Access Dashboard
Authorization visibility, requests, active states, assistance, and organizational context.
Assisted Service
Human support, exception handling, handoff, and recovery.
Recognition
Who are you?
Authorization
What may be accessed, by whom, why, and for how long?
Translating system principles into physical interaction.
The physical product was not designed only as an identity object. Its form and interaction were developed to make permission feel deliberate, legible, and controllable.
Interaction requirements
Recognizable
The physical interaction communicates orientation and use without relying entirely on a screen.
Tactile
Important interactions provide physical cues rather than depending exclusively on visual information.
Confirmable
State changes provide understandable feedback.
Recoverable
The physical interaction remains understandable when something changes or assistance is required.
Exploring Form Through Interaction
Loop, slide, and fold concepts explored different ways to express continuity, direction, and protection. Rotation provided the strongest balance of compact form, tactile feedback, and multi-state control, and became the clearest physical metaphor for changing state.
Physical interaction logic
The Credential was sized and shaped for comfortable one-handed handling, visible orientation, and easy placement into the Dock — front grip, side thickness, in-palm scale, and Dock placement.
Rotation itself creates a deliberate physical action that can communicate transition without requiring a screen.
- 01Physical ActionThe user deliberately rotates the Credential.
- 02State TransitionThe shared permission state changes.
- 03System ConfirmationPhysical and digital touchpoints reflect the update.
Prototype & feasibility
The physical concept was explored through form, component, and interaction studies to understand how the device might move from visual concept toward a buildable system.
- Form Study
- Interaction Study
- Component Architecture
- CMF Refinement
- Prototype Direction
Material & production considerations
Material direction and component packaging were considered alongside the rotational mechanism and LED feedback, together with Dock relationship and physical scale. This remains a proposed development direction rather than a manufacturing-validated design.
Personal control, organizational visibility.
TRACE extends the physical interaction into a role-based digital system. The personal app and organization dashboard provide different levels of visibility and control while sharing the same underlying permission and session states.
Personal app
The interface prioritizes making state visible — what is active, what is changing, what requires attention, and what can happen next. The screens below show the conceptual state progression; interface times and durations are illustrative rather than one exact recorded session.
- 01
Request
The user receives a contextual request showing the requester, purpose, requested information, and duration.
Context before consent.
- 02
Review
The user selects what they are comfortable sharing.
Permission has scope.
- 03
Active
Once approved, access remains visible with requester, status, shared items, remaining time, and controls.
Permission should never disappear after approval.
- 04
Pause
The user can temporarily suspend access without restarting the entire session.
Control continues after approval.
- 05
End
The user can explicitly stop access and close the shared session state.
Ending access closes the shared session state.
- 06
Record
The user can review the requester, scope, session timing, and events after the interaction.
Permission remains accountable after the interaction ends.
Beyond the core flow
The root navigation connects Home, Access, Activity, People, and Profile. Within Access, Assets brings together connected services, systems, devices, credentials, and related permissions.
Experience in context
The same permission state is carried from the core interface into everyday use, helping active access and connected areas remain visible in context.
Organization access dashboard
The dashboard is the organizational side of the same access system, not a separate admin backend. While the individual controls what may be shared, staff need a clear operational view of requests, active sessions, exceptions, and access history.
Requests
Create and review access requests.
Active Sessions
See Pending, Active, Paused, and Closed states.
Session Context
Understand requester, purpose, duration, and requested information.
Assistance
Support users when the normal interaction fails.
History
Review the conceptual session record after access ends.
Policy Management
Manage proposed organization-side permissions and service rules.
Individual
Visibility, control, confirmation, and recovery.
Organization / Staff
Authorization, oversight, assistance, and history.
Same system, different responsibilities
Three interactions carry most of the role-based experience: making permission visible at a glance, handing off session state between physical and digital touchpoints without losing context, and supporting assisted recovery when self-service is not enough.
Visual & Interaction System
The digital system uses a shared visual and interaction language to keep permission, session state, and feedback consistent across personal and organizational interfaces.
Shared Status Language
States such as pending, active, paused, or closed use consistent badges and color so they remain understandable wherever they appear.
Component Consistency
Recurring patterns — status cards, permission modules, session information, and actions like Pause or End Session — repeat across the experience rather than being redesigned per screen.
Role-Based Adaptation
The Personal App and Organization Dashboard draw on the same underlying state logic while presenting the information and controls appropriate to each role.
Access should not depend on a single mode of interaction.
A permission system cannot depend on one interaction path or one ideal condition. TRACE explores alternate presentation modes, recovery states, and failure scenarios so control remains understandable across different users and contexts — accessibility is treated as part of the system logic, not as an added feature.
One state, multiple forms of feedback
Physical
Rotation and tactile cues communicate a state change without requiring a screen.
Visual
High-contrast and reduced-visual-load presentations keep state legible when standard visuals are not enough.
Digital
The app and dashboard reflect the same state through consistent status language.
Human Support
Staff can assist when self-service interaction is not sufficient.
Accessibility states
Standard · High Contrast / Reduced Visual Load · Guided State
These presentations support conditions such as reduced visual dependence and assisted interaction, without depending on a single ideal interaction path.
Key edge cases
Each edge case is presented as a trigger, the resulting state change, the system's response, and the path back to a normal or closed state.
Connection Lost
When connectivity drops, the interface marks the affected state as disconnected and offers reconnection or an alternate path rather than failing silently.
Access Denied
When a request falls outside current permission, the system explains the denial and directs the user toward requesting or reviewing access rather than a generic error.
Credential Expired
When the physical Credential's session lapses, the system marks it as expired and guides the user toward re-recognition rather than treating it as still active.
New Device Detected
When an unfamiliar device appears, the system flags it for review instead of silently extending existing trust.
TRACE across service touchpoints.
TRACE is designed to operate within a service ecosystem rather than as an isolated device. The same permission model connects the individual, service staff, organization interface, physical environment, and service workflow.
Private financial consultation
A client arrives for a private consultation. TRACE recognizes the client, but recognition does not grant access.
The advisor creates an access request. The client reviews the requester, purpose, requested information, and duration, then chooses what to share. Once approved, the session becomes Active across the Credential, Dock, mobile app, and organization dashboard. The client can Pause, Resume, or Revoke access while the advisor sees the same updated state.
When the session ends, access closes and the client receives an Access Record.
Arrive
Recognize
RequestRecognition does not grant access
Review
Access
Control
Close
01 Individual
ArriveReview requestApprovePause / ResumeEnd session02 Physical Credential / Dock
Presence detectedRecognition feedbackPhysical confirmationActive feedbackState feedbackSession ended03 Personal App
Context shownRequest surfacedReviewConfirmControl accessAccess record04 Shared Permission State
RecognizedPendingPendingActiveActive ⇄ PausedClosed05 Staff / Human Support
Prepare interactionObserveInitiate requestAssist if neededSupportRespond to exceptionsConfirm closure06 Organization Dashboard
ContextRecognition contextPending requestPending requestActive sessionPaused / RevokedHistory / recordArrive
Recognize
Request
Recognition does not grant access.
Review
Access
Control
Close
Secondary context explorations
Healthcare
Sensitive information and temporary service access.
Workplace
Role- and task-based permission conditions.
Hospitality
Time-bounded access across a service stay.
Events
Temporary credentials across changing environments.
Designing the way back is part of designing access.
Recovery is part of the permission experience, not a separate support layer. When something changes, the ecosystem needs to coordinate a way back without silently restoring access.
Who's involved
A recovery scenario spans the individual, the physical product, the shared digital state, and organization or staff support — each seeing the same breakdown and recovery path rather than resolving it in isolation.
Recovery principles
Preserve Context
Recovery keeps the individual and staff aligned around the same state and history, instead of restarting from zero.
Make State Explicit
The system clearly explains what changed and what happens next, reducing ambiguity.
Provide a Clear Exit
A safe, clear closure is a valid outcome — recovery does not have to end in restored access to be successful.
One connected experience across physical, digital, and human touchpoints.
TRACE brings physical interaction, personal control, organizational visibility, and human support into one continuous access experience.
Designing access as a system, not a single touchpoint.
TRACE developed into a connected access concept spanning physical interaction, personal control, organizational visibility, and human support. By treating permission, state, handoff, accessibility, and recovery as shared system concerns, the project explores how physical and digital touchpoints can work together as one continuous experience.
The final system coordinates physical interaction, personal digital control, organizational visibility, assisted service, and edge cases and recovery.
Further development would focus on validating multimodal interaction, assisted recovery, and permission-state clarity across a broader range of real-world access scenarios.