Sirius — Next-Generation Data Collection Device
Integrated Hardware & Software Design for Enterprise Field Operations
Overview
Most enterprise device design works within fixed hardware specifications, the software adapts to a form factor that has already been decided. Sirius inverted that dynamic entirely. This was a project where the physical device and the digital interface were designed simultaneously, from the ground up, with neither allowed to constrain the other prematurely. The result is a data collection device where the hardware form and the software experience were built to the same standard and read as a single, intentional thing.
The scope was total: ergonomics and physical form factor, high-resolution touchscreen interface, performance architecture, and a voice command system powered by natural language processing that extended interaction beyond touch entirely.
The Challenge
Three constraints defined the design problem and had to be resolved in parallel.
Form factor was the most complex because Sirius was being designed from scratch, which meant the physical dimensions of the device were as much a design variable as the layout of the software. A device too large to hold during extended use fails regardless of how good the software is. A device too small to accommodate the required touchscreen area constrains the UX from the outside. Resolving this required iterating on physical proportions and digital wireframes simultaneously, with each discipline informing and constraining the other in real time.
Vertical space introduced a different problem. A data collection device operates in portrait orientation, often at arm's length, in environments where glanceability matters as much as information depth. Every screen state had to be designed with the assumption that the user had limited time and limited attention.
Data density was the third constraint. Transactions on a data collection device involve product codes, quantities, prices, locations, timestamps, and status fields, all of which a user may need to see, enter, or verify in a single workflow. Presenting that on a small touchscreen without overwhelming the user required a disciplined hierarchy of what was primary, what was secondary, and what lived behind demand.
Approach
The process moved through Assessment, Exploration, Design, Production, and Deployment with the critical difference that hardware and software decisions ran on the same track throughout.
Assessment mapped how data collection was being done across four industries: what devices were in use, where they were failing, and what users needed that existing products weren't providing. The consistent findings, hardware built for durability but uncomfortable for extended use, interfaces designed for function without attention to usability, and zero integration of voice interaction in a category where hands-free operation had real operational value became the design brief for Sirius.
Exploration tested hardware form factors and software interaction architectures in parallel. A front-end developer and software architect were present throughout this phase, making technical feasibility for hardware integration and software rendering a real-time conversation rather than a late-stage discovery. Decisions that would have been expensive to revisit after engineering committed were made collaboratively while the cost of change was still low.
The Work
Wireframes on a project like this had to resolve two overlapping sets of decisions simultaneously, the structural logic of the software experience across transaction and management workflows, and the spatial and proportional constraints the hardware had to satisfy to make that software work as intended. The wire phase produced dual specifications: a coherent software architecture and a hardware design envelope derived directly from it.
High-fidelity designs translated those structural decisions into the complete visual and interaction language of the device, touchscreen UI, visual treatment of voice command states across all interaction modes, and the hardware design language that gave the physical form its identity.
BuildKit delivered the full implementation specification to engineering: component states, animation behaviors, voice interaction flows, hardware integration specs, and asset exports organized for both software and hardware development teams. Not a handoff, a complete build package designed to protect design intent through production.
The Outcome
A product where the physical object and the digital interface reinforce each other rather than competing. Sirius delivered durability, ergonomics, interface sophistication, and voice interaction in a product category where trade-offs between those qualities had previously been accepted as inevitable.
Staying close through production and deployment was as critical as setting the direction during exploration because the gap between a well-designed spec and a well-built product is where quality is most often lost.
Role — Creative & Design Direction (UX/UI) Team — UX · UI · Research · Front-End Developer · Software Architect · Product Management Industries — Retail · Manufacturing · Healthcare · Hospitality
SaaS Product Design Strategy
Enterprise Platform Transformation — Legacy On-Premise to Modern Cloud SaaS
Overview
This project represents one of the most consequential design challenges in enterprise software: taking a mature, on-premise product suite and rebuilding the entire experience for the cloud. Not a visual refresh. Not a feature update. A complete rethinking of how a product serves real people across five industries, three distinct user types, and an organization that had spent years building around tools that technically worked but quietly exhausted everyone who used them.
The Challenge
The legacy platform had been built over many years by multiple teams solving problems in isolation. The result was a product that carried inconsistent patterns, redundant flows, and a visual language that reflected a different era of software. Moving to SaaS introduced an entirely new set of user expectations, the speed and responsiveness of a modern web product combined with the configurability that enterprise buyers had come to depend on.
The harder challenge was human. Aligning cross-functional teams around a shared design vision, when every product area had developed its own conventions and its own sense of ownership, required earning trust through process before earning buy-in through output.
Approach
The process moved through six structured phases. Assessment, Exploration, Research, Prototype, Iterations, and Deployment, designed to reduce risk while moving decisively through ambiguity.
Discovery started with a full audit of the legacy product: cataloging interaction patterns, mapping friction points, and aligning stakeholders on what success actually looked like before any design work began. Research followed not as a checkbox, but as an ongoing practice. User interviews and contextual inquiry sessions with managers, full-time employees, and hourly workers shaped every significant decision that came after.
Prototyping kept the cost of learning low. Low and mid-fidelity concepts were tested early, before commitment hardened. High-fidelity work came only after the core interactions had been validated. Each iteration closed the gap between what the product was and what it needed to become.
The Work
Rather than delivering screens, the output was infrastructure, a design foundation built to outlast the project itself.
A Design System became the shared language for every team building on the platform: not just what components looked like, but how they behaved, when to use them, and why. A system that teaches you how to think, not just what to copy.
Common Components were designed to be flexible across five industry contexts, retail, manufacturing, healthcare, HR, and hospitality, while remaining consistent enough to build genuine familiarity across the product.
Design Tokens defined the core visual values at the code level, allowing changes to propagate systemically rather than manually and making the platform extensible for themes, brand variations, and future products without breaking the underlying structure.
The Outcome
A platform that felt native to five industries without being built five separate times. A design system that gave distributed teams the tools to make good decisions independently. And a product experience that measurably reduced onboarding friction, shortened the learning curve for new users, and helped the business retain and grow within accounts, not just launch.
Strategy without execution drifts. Execution without strategy fragments. Holding both together was what made this work.
Role — Design Leadership & Execution Team — UX · UI · Research · Product Management Industries — Retail · Manufacturing · Healthcare · HR · Hospitality
Apple Watch App
Native Wearable Experience for Workforce Management
Overview
What does it mean to design for a screen the size of a postage stamp that lives on someone's wrist? This project explored that question within a workforce management context, and the answer required stepping back from conventional app design entirely. This was not about shrinking an existing mobile experience onto a smaller display. It was about identifying which moments in an hourly worker's shift genuinely benefit from a glance-and-go interaction, and then designing those moments with a level of precision that most software never demands.
The native Apple Watch app was purpose-built to complement the broader scheduling platform, functioning as a real-time assistant that surfaces the right information at the right moment without requiring the employee to stop what they are doing, reach for their phone, or navigate through multiple screens.
The Challenge
Two constraints defined every decision.
The first was the form factor. The Apple Watch screen is small by design, and that constraint is not just visual. It shapes how information can be organized, how interactions must be sequenced, and how much context a user can hold in a single view. Standard UI patterns from mobile and web simply do not translate. Navigation hierarchies that feel effortless on a phone become exhausting on a watch. Every design decision had to pass through a single filter: what is the one thing this person needs to know right now, and how do we show only that?
The second constraint was the dependency on the iPhone. The Apple Watch relies on a paired device for data connectivity, which means the experience is subject to Bluetooth reliability, background refresh limitations, and physical proximity. Designing for a device that is occasionally out of sync with its data source required building graceful states for stale content, clear last-updated indicators, and interaction patterns that did not frustrate users when connectivity was momentarily unavailable.
There was also the harder problem of information redundancy. The goal was not to duplicate what already lived on the mobile app but to identify the specific subset of information that gains real value by being on the wrist. Getting that distinction right required careful research and a willingness to cut features that seemed useful in theory but added noise in practice.
Approach
Assessment began with an audit of how hourly employees were actually using the existing mobile app. Usage data, support tickets, and direct interviews revealed a consistent pattern: the most accessed features were shift times, break schedules, and manager messages. Everything else was secondary. That finding became the foundation for the entire wearable strategy.
Exploration focused on what watchOS could do that mobile could not, rather than mapping mobile screens to watch screens. The team investigated how haptics, complications, and Siri integration could create genuinely new interaction moments, from ambient shift countdowns displayed as watch face complications to voice-activated status check-ins that required no visual attention at all.
Design translated the strongest concepts into structured flows. At this screen size, wireframes were as much about content priority as visual layout. Deciding what appeared on the primary card, what lived one swipe away, and what required a tap involved constant negotiation between completeness and clarity.
Production ran in close collaboration with the front-end developer and software architect throughout, because watchOS has its own layout engine and rendering behavior. Staying in sync with engineering from an early stage was the only way to ensure design intent survived the technical constraints of the platform.
The Work
Wireframes played a more critical role here than in most projects. Because screen real estate was so constrained, low-fidelity explorations were used to stress-test content hierarchy and interaction logic before any visual decisions were made. A wireframe that could not communicate the right thing in the right order at the right time was not going to be rescued by color or typography.
High-fidelity designs brought the visual language of the broader platform into the watchOS context, adapted to the constraints of a small, always-on display. This included detailed work on dark mode optimization, since the Apple Watch OLED makes dark interfaces not just visually appropriate but functionally superior for battery life and legibility. Typography choices, icon sizing, and layout density were all validated against real device previews rather than simulator estimates.
BuildKit and Design System documentation served as the connective layer between design and engineering, covering spacing, component behavior, interaction states, and animation timing in a format the development team could reference independently. Given the precision required by watchOS layout constraints, clear specs were a prerequisite for shipping a product that matched the design intent, not a formality.
The Outcome
A wearable experience that fits naturally into the rhythm of a shift without adding cognitive load. Retail associates, warehouse workers, and hospitality staff get shift times, break windows, task assignments, and real-time manager updates in under two seconds, on a device they never have to reach for. Haptic feedback replaces audio alerts in loud environments. Voice input replaces touch when hands are occupied.
The broader outcome was establishing the wearable as a legitimate productivity surface within the platform ecosystem, one that increased engagement with the scheduling system by lowering the barrier to access.
Role — Design Leadership and Execution Team — UX · UI · Research · Front-End Developer · Software Architect · Product Management Industries — Retail · Manufacturing · Hospitality
AI–Driven Rapid Prototyping
Acme Onboarding Sprint (5 Days)
Overview
Acme, a Series A B2B SaaS workforce management platform, had a measurable problem: 68% of new users were abandoning the product during Account Setup, and only 32% were reaching activation against an industry benchmark of 58%. The support team was fielding 15 or more tickets per week from users who could not get through the same three steps. The product worked. Getting people into it did not.
This was a 5-day sprint engagement to redesign the onboarding flow from Welcome through Account Setup, Team Invite, and First Task, and deliver a tested, handoff-ready prototype by end of day five.
The Challenge
The core friction was structural, not visual. Account Setup presented eight required fields before a new user had seen a single piece of product value. There was no progress indicator. Team Invite was treated as mandatory by the interface even though the back-end did not require it, which created a wall that 41% of users who made it past Account Setup still did not clear. On mobile, the drop-off rate climbed to 74%.
The real insight, confirmed through cohort data from the lead engineer, was that users who reached First Task showed three times higher 30-day retention than those who did not. The product had a defined activation moment. The onboarding flow was actively preventing users from reaching it.
The constraints were tight: no new back-end API changes, no new components outside the existing design system, and the redesigned flow had to work at 375px on mobile.
Approach
The sprint ran across four phases: Discovery, Lo-Fi Concepts, Interactive Prototype, and Iteration and Handoff.
Discovery locked the problem before any design work began. User interviews, support ticket analysis, and competitive benchmarking against Rippling and Lattice revealed the consistent pattern: too many fields too early, no sense of progress, and a forced step that served no functional purpose. Four decisions were locked and signed off by the PM and lead engineer on Day 1: reduce Account Setup to three fields, add a visible step counter, make Team Invite skippable, and redefine "done" as a user completing their first task rather than filling out a profile.
Exploration produced three structural wireframe options: a linear step flow, a single-page scroll, and a conversational interface. The team voted asynchronously using FigJam. Option A, the linear step flow, won decisively with five out of six team members choosing it, supported by clear reasoning: enterprise users trust predictable step flows, and the conversational approach read as too casual for B2B HR contexts. One piece of async feedback from the Customer Success lead, to show one field at a time rather than grouping all three, was incorporated before moving to prototype.
The Work
The redesigned flow reduced five screens to four by removing billing from the onboarding sequence entirely. Account Setup was rebuilt around one field at a time with Smart Animate transitions between steps, a progress bar labeled "Step 2 of 4," and a loading state on submit that had been missing from the original. Team Invite became skippable. First Task was framed as the activation moment, with a completion state to mark the transition from setup to actual use.
Every component used in the prototype was pulled from the existing design system with no new components built, keeping DS compliance at 100% and eliminating implementation risk for engineering.
The priority matrix run on Day 5 sorted all outstanding feedback into four quadrants. High-impact, low-effort fixes, including the progress bar thickness on mobile, the loading state, and the skip CTA, were completed within the sprint. Higher-effort items including the post-skip re-entry flow and full animation polish were documented and scoped for the next sprint cycle.
The engineering handoff package included Figma Dev Mode specs with full token mapping, component annotations linked to the DS library, a Figma Variables JSON export mapped to existing codebase variable names, annotated edge cases for error states and skip paths, and a 20-minute Loom walkthrough of every screen and interaction state.
The Outcome
Sign-off completed in one round. Handoff delivered by end of day five. Engineering fielded two post-handoff questions against a target of fewer than five. Fields per step reduced by 62%, from eight to three. The predicted activation improvement from the CS lead's estimate was 26%, with engineering build beginning in the following sprint.
The sprint retro surfaced one structural insight worth keeping: async FigJam review saved two hours of scheduled meetings, and the best design input of the sprint, the one-field-at-a-time change, came from an async comment rather than a live session.
Role — Fractional Design Lead Team — Product Manager · Lead Engineer · Customer Success Lead · Fractional Design Lead Platform Industries — B2B SaaS · Workforce Management · Series A
Additional Samples...
