Trinity Pocket

Background

Trinity Custom Apparel's field sales reps were using a third-party mobile app called Skiffle to manage clients, browse fabrics, and reference orders on the go. The app was not built by or for Trinity — it was a licensed product with a generic identity, limited feature coverage, and no path to native mobile capabilities like biometric login, push notifications, or camera access.

Trinity needed to own the mobile experience. My job was to define what that meant, scope what to build, and lead the design and architecture of the replacement from the ground up.

The audit — reading the existing app

Before wireframing anything, I did a full structural analysis of Skiffle: mapping every screen, its route in the codebase, and how it compared to Trinity's own dealer web app. The goal was to understand exactly what existed, what was missing, and what Trinity's own backend already supported that Skiffle never exposed.

I documented the gap analysis screen-by-screen: 22 screens in Trinity's dealer web app had no equivalent in Skiffle at all. Three Skiffle-only screens were mobile-native patterns worth carrying forward. Payment management, Styleflow, and the dashboard were entirely absent.

Skiffle 1.0 in full — every screen documented during the audit. Each was classified: carry forward natively, bridge via WebView, omit entirely, or replace with a better mobile pattern.

Kickoff board detail — screen specs, user stories, and flow decisions mapped during the initial planning session with the team.

Turning the audit into a scope

The audit produced a classification system for everything in Trinity's existing web app: features that should become native screens, features that could bridge through a WebView temporarily, features that should be permanently omitted from mobile, and net-new capabilities that only make sense on a phone.

From scope to functional requirements

Every native screen carried its scope decision into a numbered functional requirement — FR-1 through FR-29, plus a parallel set of fix tickets (FIX-1, FIX-2…) for behaviors Skiffle got wrong. Grouping the board by screen area kept Auth, Home, Orders, Clients, Fabrics, Search, the inclinometer, Tools, Push, Support, and Account each auditable on their own, instead of one flat backlog.

The full functional requirements grid — every screen area broken into individually numbered requirements and fix tickets, so each one could be scoped, estimated, and checked off independently during sprint planning.

Research & personas

Understanding who actually uses the app — and how their workflows differ — shaped every navigation and scope decision. Three distinct personas emerged: the field rep managing clients on-the-go, the senior dealer who lives in orders and rankings, and the relationship-led rep who uses Styleflow as a sales presentation tool.

User personas defined during the kickoff session. Each persona surfaces different priority screens and informs where in the sprint sequence each feature belongs.

Key design decisions

Backend scoping & sprint execution

Styleflow's Custom Model Creation flow needed backend work Trinity's API didn't have yet — new endpoints for custom copy, mounting, and model visibility, plus a "quick win" fallback using existing dealer upload storage until the real ones shipped. Mapping the frontend flow (Home → Model Library → "Create My Model" → Confirmation) against exactly which backend pieces existed vs. needed to be built kept the Rack Builder sprint from stalling on an API that wasn't ready.

The planning surface behind the scenes: the full app screen-flow diagram, Custom Model Creation's backend requirements and frontend flow side by side, the API endpoint inventory, QA verification checklists for auth and orders, and the five-sprint execution timeline that sequenced all of it.

Design process

The kickoff board was a live working document — not a presentation deck. Every screen decision was made against real flow diagrams and real API availability, not against hypothetical requirements.

Dashboard concept — dealer rank pill, order pulse card, bulletin feed, and quick action row mapped before any wireframe was drawn.

Orders tab spec — search bar, status pill tabs, and 56px minimum row height locked before the production UI was built.

Orders flow in depth — mapped from a walkthrough session with the team. This diagram drove the screen hierarchy in the Orders tab and clarified which states needed native treatment vs. a desktop deep-link.

The interface

Early builds used a placeholder violet as a stand-in accent while the brand team finished Trinity's actual identity system. Once that landed, the interface was rebuilt against the real palette — Heritage Sky #4F8FEB for every interactive state, active tab, and CTA, with Midnight Blue and Deep Navy carrying headers and text. It's a small thing on paper, but it's the difference between a prototype that looks like a demo and one a dealer mistakes for Trinity's own software. The tab bar never disappears during normal browsing, and Styleflow keeps a deeper navy chip treatment so it still reads as a distinct creative tool rather than a reference screen.

Six core screens from the production UI spec — Login, Dashboard with order pulse, Orders list with status tabs, Fabrics explorer, Clients directory, and the Tools hub with Styleflow as the featured creation tool.

The working build

Trinity Pocket now exists as a running Expo build, navigable end-to-end across all 27 screens against mocked data ahead of backend integration. A few screens from the current build:

Login

Orders

Clients

Rank Report

Outcomes

Trinity Pocket has moved from spec to a working build. All 27 screens are built and running end-to-end in Expo Router — Auth, Home, Orders with a 4-step New Order wizard, Clients, the AR-based Shoulder Slope measurement tool, Styleflow, Rankings, and Payments — currently against mocked data. The scope, tech stack, navigation architecture, and nine Architecture Decision Records are locked; the next milestone is wiring the build to Trinity's live backend in place of the mock data layer.

Reflections