PeakPOSDesigning the merchant portal and design system for a specialty-retail POS

Role
First Product Designer
Timeline
1 month
Type
Marketing Site, Design System, Merchant Portal
Tools
Figma, HTML/CSS, Claude Code

Overview

PeakPOS is a point-of-sale platform for specialty retailers like smoke shops, liquor stores, and beauty supply. Merchants use its portal to manage inventory, invoices, and compliance.

I joined as the first and only designer, working with backend engineers who owned the data.

Problem

They asked for “distinct.” The real need: merchants should find what they need fast, trust what they see, and feel one product from the website to the dashboard.

The portal worked, but it had no hierarchy, a sidebar nav stakeholders kept complaining about, and nothing tying it together as one product. And two stakeholders disagreed on direction: bold vs. calm.

The sidebar was the top stakeholder complaint: long and always open. And the page had no hierarchy, so nothing told a merchant what needed attention first.

Merchant portal before the redesign

Process

What great POS products do

Before opening Figma, I studied Stripe, Square, Toast, and Clover. The best ones show one idea at a time and let the real product do the selling. PeakPOS put everything on one screen, with no clear moment for its users.

V1: Bold & editorial

Dark backgrounds, large type, motion. The primary stakeholder loved it. Shipped internally as v1.

V1, bold and editorial: screen 01V1, bold and editorial: screen 02V1, bold and editorial: screen 03

A second stakeholder pushed back: dark read as developer-facing. But our users are retail operators, not developers. They needed something light, readable, and easy to trust.

V2: Built for operators

Light UI, one accent for status. Dark section only for compliance. Inter for dense dashboards. Live portal up front, not a pitch.

V2, built for operators: iteration v1V2, built for operators: iteration v2V2, built for operators: iteration v3

Light UI over dark

Operators aren’t developers. A light UI with one accent keeps numbers readable and makes the few things that need attention stand out.

Inter over Plus Jakarta Sans

Plus Jakarta had more personality, but Inter stays legible in dense tables and KPI numbers, where merchants actually work.

Show the real portal, not a wordmark

Putting the live portal above the fold lets merchants see what they’re getting, and leans less on sales demos.

Final design

I rebuilt the front end myself with Claude Code. Every visual and interaction call was mine; backend engineers owned the data.

  1. 1An icon rail by default gives the data the room: the numbers a store manager checks first (sales, lanes, card mix).
  2. 2Stock alerts call out what needs action, not just what happened.
  3. 3Hovering expands the rail over the page, so you can jump somewhere without losing your place. Clicking pins it open and the page makes room, for when you’re navigating a lot.

Design system

Ready and Review shared near-identical navy, even though one needs a human and one doesn’t. I caught it while documenting in Storybook and rebuilt the palette around what each state asks of the merchant.

Status badges before, grouped by look, and after, grouped by what each state asks of the merchant

Primitives → semantic tokens. Tokens by role, not raw hex: engineers pick “status/attention” or “text/secondary,” so every new screen stays consistent without a designer in the loop.

Teal, navy, and neutral color ramps beside the semantic token list

Merchants live in dense dashboards, so legibility mattered more than personality. I picked Inter over Plus Jakarta Sans and built one scale by role: display, heading, body, label.

Type scale by role: display, numeric, heading, title, body, label

Every component was documented in Storybook with its variants, states, and edge cases, and verified in isolation before it touched the portal.

Storybook documentation of the frosted component setStatus badges at Compact, Default, and Comfortable density

Outcome

My contract ended before v2 shipped, so I don’t have launch numbers. I’d track demo bookings from the marketing site, how fast merchants complete core portal tasks (finding a product, checking stock), and whether sidebar complaints actually go away.

Reflection

Align on one direction before building

Bold v1 shipped before every stakeholder had weighed in. Next time I’d get everyone aligned on a single direction first.

Document decisions as they happen

I reconstructed a lot of rationale afterward. Writing it down in the moment would have made handoff cleaner.

Hand off well

My contract ended before v2 shipped, so I handed off the design system (documented in Storybook) and portal work to the team.