Challenge
Engineering teams booked physical test devices across spreadsheets, Slack threads and legacy tools — leading to conflicts and lost time.
Method study / Enterprise product design
Snap Automation
Designing a clearer device-booking system for engineering teams working across a complex test environment.
- Role
- UX/UI Product Designer
- Focus
- Device booking · Design systems
- Tools
- Figma · Figjam · Jira
01 — Project overview
A product-system problem, not just a booking screen.
My role
UX/UI Product Designer
Scope
Booking, scheduling, inventory and shared UI patterns.
Outcome
A consistent booking experience with a reusable component library.
02 — Method overview
Reduce uncertainty at each product decision.
01
Research
Understand the existing product and the people using it.
02
Product thinking
Connect device access to the wider engineering workflow.
03
Information architecture
Give devices, bookings and support a clear home.
04
Interaction
Make discovery, evaluation and booking feel predictable.
05
Exploration
Compare directions before committing to a system.
06
System
Turn repeated patterns into reusable product infrastructure.
07
Final design
Bring the chosen direction together across the portal.
08
Validation
Test the highest-risk decisions and iterate.
03 — Research
Understand the product before changing it.
The starting point was a fragmented workflow: engineering teams booked physical test devices across spreadsheets, Slack threads and legacy tools.
Synthesis cluster
Navigation
- Device access was spread across several tools.
- There was no central availability view.
Synthesis cluster
Device booking
- Scheduling depended on manual coordination.
- Conflicts were difficult to spot before booking.
Synthesis cluster
Design system
- Each tool had an inconsistent interface.
- Repeated patterns needed a shared foundation.
Synthesis cluster
Support
- When access broke down, teams had to move between tools.
- [ADD SUPPORT EVIDENCE]
04 — Key insights
Evidence became a set of product decisions.
01
Booking was a coordination problem
The experience needed to bring availability and action into one place.
Design implication: make the booking path central, visible and easy to scan.
02
Device context shaped confidence
Teams needed enough information to choose the right device before committing time.
Design implication: keep device details close to availability and booking actions.
03
Operational states were part of the product
Available, booked and unavailable states directly affect planning.
Design implication: make status visible before a user starts a booking.
04
Repeated patterns needed consistency
Inconsistent UI across tools increased the cost of learning and maintaining the product.
Design implication: use shared components and tokens across surfaces.
05 — Product thinking
Connect navigation to the job users are trying to finish.
The product experience was framed as a connected journey rather than a set of isolated portal pages.
01
Home
02
Booking Device
03
Testing
04
Debug
05
Cloud
06
Support
Current workflow
01
Need a device
02
Search across tools
03
Coordinate access
04
Confirm a slot
05
Start testing
06 — Pain points
Make the friction specific enough to design against.
Fragmented access
ImpactEngineers moved between spreadsheets, Slack and legacy tools.
OpportunityProvide one place to discover and manage device access.
Unclear availability
ImpactThe current experience made conflicts harder to see early.
OpportunitySurface availability before the booking decision.
Inconsistent interfaces
ImpactDifferent tools used different patterns for similar actions.
OpportunityCreate reusable patterns that can scale across device classes.
07 — Information architecture
Give each product job a clear place to start.
Navigation model
Home
Booking Device
Testing
Debug
Administration
Cloud
Support
08 — Interaction
Discover → evaluate → book.
The primary flow keeps the decision points visible and brings availability into the moment when it matters.
- 01Start
- 02Devices
- 03Search / filter
- 04Select device
- 05Review details
- 06Check availability
- 07Select period
- 08Confirm booking
- 09Booking created
09 — Wireframes
Test structure before styling the interface.
The early work focused on navigation placement, device discovery, filtering, availability and confirmation.
10 — Exploration
Compare the trade-offs before choosing a direction.
01
Information-first
Prioritise device context and availability.
- Strength
- Supports careful evaluation.
- Trade-off
- Can slow down repeat actions.
02
Action-first
Put booking actions immediately within reach.
- Strength
- Makes the primary job fast.
- Trade-off
- Can hide important context.
03
Balanced
Keep context and action in the same visual field.
- Strength
- Supports confidence without adding steps.
- Trade-off
- Requires disciplined hierarchy.
What changed
The final direction balanced quick booking with enough context to make the choice defensible. The design system then made that balance repeatable.
11 — Design system
Product infrastructure for repeated decisions.
The system was designed to support many device classes and the surfaces around them, not just one polished screen.
Tokens
- TypographyProxima Nova
- Spacing8px, 16px, 24px,
- Radius8px, 12px. 16px, 24px
- Borders1px, 2px
States
12 — Snap AI
Support should meet the existing intent.
The brief calls for Snap AI to sit inside Support rather than become a disconnected destination. The supplied case-study evidence for this flow is not available yet.
13 — Final design
A clearer system for finding, booking and managing devices.
The final screens are organised by the workflow they support, not as a random gallery.
01 — Navigation
SNAP Automation — System Admin prototype
Decision: keep the product surface focused on a clear next action and visible device context.
02 — Device discovery
SNAP Automation — Web Portal
Decision: keep the product surface focused on a clear next action and visible device context.
03 — Booking
SNAP Automation — Web Portal
Decision: keep the product surface focused on a clear next action and visible device context.
14 — Validation
Test the highest-risk decisions, then iterate.
The existing study records five usability tests and a confidence rating of 4.5 / 5. Further evidence can be added as the work is documented.
Usability testing
5
Confidence rating
4.5 / 5
Tasks
Discover → Evaluate → Book
Method
Usability testing
Iteration loop
PrototypeTestObserve behaviourIdentify frictionChange interactionRetest
15 — Outcome
A stronger foundation for the product to grow.
Navigation
A unified booking surface replaced a fragmented starting point.
Device booking
Availability became part of the booking decision.
Design system
Shared patterns created consistency across internal products.
Support
The support entry point is defined as part of the experience:
16 — What I learned
The work was as much about system thinking as screen design.
What worked
Investing early in tokens and primitives paid back across every feature shipped after.
What I would improve
Tighter loop with platform engineering would have caught permission edge cases sooner.
Future opportunity
Open the system to partner teams as a shared internal product surface.
Next learning
Snap Automation taught me how to design a complete device-booking workflow and simplify navigation across different user levels. I learned that good enterprise UX is not about adding more information—it is about giving users the right context, at the right moment, so they can confidently complete their task.
17 — Method summary
Research → Product thinking → Information architecture → Interaction → Exploration → System → Final → Validation
“The method was not about following a fixed process. It was about reducing uncertainty at each stage of the product decision.”
Next steps
Want to talk through the system?
Happy to walk through the decisions, trade-offs and product-design method behind Snap Automation.
Next Method study
Orbit