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.

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

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 Figma Make prototype 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

The production design uses violet #7C3AED as the locked brand color — a deliberate break from the navy-and-grey world of Skiffle. Every interactive state, active tab, and CTA uses violet. The tab bar never disappears during normal browsing. Styleflow uses navy filter chips to feel visually distinct from the rest of the app — a creative tool, not a reference screen.

Six screens from the Figma Make prototype — 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.

Outcomes

Trinity Pocket is currently in active development with Sprint 1 (authentication) in progress. The scope, tech stack, navigation architecture, and nine Architecture Decision Records are locked. The Figma Make prototype covers all twelve Sprint 2 screens and the full Styleflow configurator flow.

Reflections