David Yeo

A design system is not a component library. It is a decision-making framework. The purpose is not pre-built buttons. The purpose is that every design decision gets made once, documented, and applied consistently.

Three jobs ran in parallel: reasoning about structure, executing in Figma, and evaluating tools. Separating them is what made solo execution possible.

Skeleton first, then layer. Core atoms only: type, colour, spacing, buttons. No complex components. Stakeholders asked "where are the modals?" The line held. Premature components create maintenance debt.

Separate design tokens for design and code. Figma variables are design-side. JSON/TypeScript files are the code source of truth. Two representations create a sync obligation. Worth it for the handoff friction it removes.

Storybook as shared reference, not Notion. A Notion page goes stale. Storybook is a URL anyone can open that renders actual components.

Shared repo for handoff and exploration. Local prototypes live alongside production components in the same repository. Engineers pull the branch, run Storybook, and interact with the design — no Figma access required. Exploration and handoff happen in the same place.

Claude for thinking, Figma Make for prototyping. Not interchangeable. Claude handles reasoning and design strategy. Figma Make handles interactive prototypes.

I built a local prod repo that consumes the design system tokens directly. Every prototype is a real component using real spacing, type, and color — no Figma-only fidelity gap.

Vercel auto-deploys every commit. PMs and engineers review prototypes via share-link, not screenshots. This is now the team's default review surface.

Within two months, every product area pulled from the same tokens. No more colour drift. No more guessing at spacing. Engineers shipped faster because they stopped reverse-engineering Figma.

Building a design system solo is prioritization, not craft. The hard part is deciding what not to build yet.

The surprise: AI as thinking partner, not UI generator. Token structure and tradeoff analysis proved most valuable. Articulating a problem clearly enough for AI to engage forces more precise thinking.

Every gap created downstream trust damage. A missing insurance option lost a seller. A bad weather tag killed a live animal. A wrong fee display eroded buyer confidence mid-stream.

Fix these in isolation and they conflict. Fix them as a system and each piece reinforces the next.

Smart Shipping: $7.49 flat rate per 5lb USPS Ground Advantage box. One price. No decision fatigue. Modeled after Whatnot's approach because sellers already understood it.

Insurance: XCover via Shippo at 1.25% of insured value. One antique seller had stayed on PirateShip solely for this. Japan LA flagged it for high-value collectibles.

Every project connects. Weather Check could not exist without Shipment Management. Insurance could not ship without a solid label purchase flow. Hold Shipments only made sense once Weather Check created orders that needed holding.

Buyers historically distrusted live commerce shipping fees. Hidden markups eroded conversion. The redesign exposed every line item — weight-tier shipping, optional insurance, platform fee — so buyers could see what they were paying for.

Trust compounded: ship-confidence drove repeat purchases.

Execution was the strength. The growth edge was getting upstream earlier — initiating research before anyone asked. That shift started with the next project.

Individual friction compounds: a 2-hour packing run becomes 6+ hours when regressions chain.

Address changes, cancellations, refund requests, hold requests: they all share the same shape. A buyer initiates. A seller approves. The platform mediates.

Design the underlying grammar once and every future request type becomes a configuration, not a new project.

I wrote a full PRD from scratch. Flowcharts, edge case mapping, user stories for both sides, implementation order. Reviewed with three PMs before any design work.

Then I documented the pattern: Request → Pending → Seller Decision → Outcome. Every buyer-to-seller request follows this grammar. Four features share one model: Buyer Change Address, Cancel Order, Refund Order, Hold Shipments.

Approval-based, not auto-approve. Seller trust is more fragile than buyer trust on a marketplace. Tradeoff: more friction for buyers than Whatnot's model.

One rejection ends the flow. Prevents infinite resubmission loops. Abuse surface too high for a resubmit option in V1.

Label purchase auto-approves. If a seller buys a label using the new address, that action IS the approval. Adding a manual tap after is redundant friction.

Designed as a reusable framework. Engineers build the pattern once. PMs spec new request types without reinventing the model.

Sellers run shops between dayjobs. Approval needs to be one-handed, mid-commute, sub-30-second.

The mobile hub surfaces inbound requests as cards: diff highlighted, approve/decline as primary actions, full context one tap away.

This was fully self-initiated. I saw the ticket volume, built the competitive analysis, wrote the PRD, and presented it to three PMs before anyone asked me to.

The pattern abstraction came from writing the PRD, not from designing the UI. Deep problem framing before Figma made the reusable framework obvious.

The problem was not "build a calendar." WorkJam treated content management as seven separate workflows when admins needed one. A calendar was the interface. The real solution was a centralized hub that collapsed seven module workflows into a single operational view.

Daily digest: Answers "what is happening today?" with actionable cards on first load.

"View as" filter: Admins see content as different user roles see it: store manager, regional lead, frontline employee.

Location picker: Filter by store, region, or department.

Inline content creation: Create surveys, posts, and trainings without leaving the calendar.

Cross-module scheduling: One timeline for all seven content types.

Clients: TJX, Target, Woolworth's, Ulta Beauty, Ross — each managing 10,000+ frontline employees across hundreds of locations.

Two-audience challenge: Admins at HQ need powerful scheduling, role-based previews, and cross-module visibility. Frontline workers need glanceable content on shared devices between tasks. The calendar had to serve both without compromise.

89% voluntary adoption across WorkJam's customer base. The design earned engagement — enterprise software where usage can't be mandated.

Admins managing 400+ stores need to scope content to specific locations, departments, positions, and certification statuses without leaving the calendar.

The "View as" simulator was the breakthrough — admins could preview the calendar exactly as a Northeast morning-shift store associate would see it.

One week of structured collaboration eliminated months of potential misalignment. The Design Sprint taught me more about stakeholder alignment than any feature spec.

The first direction is rarely wrong about everything — it is usually right about one thing. The heatmap was wrong as a primary view but right as a signal that admins wanted density awareness. That insight survived three pivots.

Frontline communication is not Slack for retail. A store associate checking their phone during a break has 90 seconds, not 90 minutes. Every interaction must be completable in under three taps.

The admin who manages 400 stores needs granular targeting, not "post to #general." Speed for end users. Power for admins. Both on the same platform.

Eliminated the dependency on Canva and external content creation tools. Admins create branded posts with formatted text, inline media, and scheduled publishing directly inside WorkJam.

Reduced the creation-to-publish cycle for 80%+ of posts. No more context-switching between tools to produce a single announcement.

Target Audience filtering for mentions. A mention should only surface people who can see that channel. Searching the full directory exposes names outside the audience scope.

Scheduled posts retain @mentions. Mentions resolve at publish time, not creation time. If a mentioned user leaves before publish, the mention surfaces as invalid with clear feedback. Required for compliance with labour laws around terminated employee data.

Platform-native, not platform-identical. Same features everywhere, but interactions adapt to each OS. iOS swiping, Android back gestures, desktop hover states. Consistency of capability, not of pixels.

Frontline workers compose from their phones during shifts. The mobile RTE had to feel native — iOS share sheet, Android camera intent, gallery picker, and inline image preview without leaving the composer.

Multi-attach with reorder, crop, and delete — all gestures, no nested menus. Optimized for one-handed use on shared devices.

With core communication features shipped — @mentions, threading, rich text, and media — the next challenge was making Channels work at enterprise scale.

500,000+ frontline employees across TJX, Starbucks, Currys, and Ulta Beauty needed to find content fast, trust moderation, and move seamlessly between devices. The infrastructure had to match the interaction quality.

Designed cross-channel search that enabled 40% faster content discovery than the single-channel search in Channels 1.0.

Snippet display instead of full post cards — keeps search fast and pushes interaction to the channel context where it belongs. Recent search logic, live search vs. advanced search page distinctions, and content highlighting with deep linking.

These patterns became the global search design guidelines for the entire WorkJam platform, governing search across all modules.

Web + iOS + Android with dark and light mode. @mentions work identically everywhere. Dropdown positioning and dismiss gestures adapt to each platform's conventions.

The same person might post from a desktop in the morning and check replies on a shared tablet during lunch. The experience must feel continuous, not duplicated.

Frontline workers have 90 seconds between tasks. Every interaction must complete in under three taps. Shared devices. Variable connectivity. 50+ languages. The interface has to earn usage — it can't be mandated.

Enterprise admins manage 400+ stores. They need granular targeting, compliance controls, moderation at scale, and analytics. Power features that don't leak complexity to the frontline.

The defining challenge: instinct is to default to the admin (they're the buyer). But if frontline workers don't use it, the admin's investment fails. Both audiences designed for simultaneously, not sequentially.

Labour law compliance: Terminated employee data cleared from mention dropdowns. On-premise content restrictions. Mandatory acknowledgments with read receipts. HIPAA-ready for healthcare clients.

89% voluntary adoption across WorkJam's customer base. Enterprise software where design quality drives adoption, not mandate.

Clients at scale: TJX, Starbucks, Currys, Ulta Beauty — each with 10,000+ frontline employees across hundreds of locations, multiple time zones, and diverse regulatory environments.

Designing for frontline workers requires rethinking every interaction through a time-pressure lens. A desk worker explores a dropdown for 10 seconds; a store associate on break cannot.

Cross-platform design isn't "make it work on three screens." It's understanding the same person uses multiple devices throughout their day. The experience must feel continuous, not duplicated.

The search patterns I established for Channels became the standard across all WorkJam modules — the strongest signal that infrastructure-level design thinking outlasts any single feature.