Design system · Furniture e-commerce
Forma & Field is a furniture retailer I created to explore one question: how far can a single, well-structured system carry a shopping experience , from the first browse to the final confirmation? It covers tokens, reusable components, commerce patterns and six full page templates.
Project overview
Furniture shopping mixes two moods: editorial inspiration and practical decisions about size, finish, price and delivery. I wanted a system that could hold both , warm enough to sell a room, clear enough to buy a chair.
So rather than designing screens one by one, I built the layers underneath them first, then used those layers to assemble a full shopping journey.
The design challenge
A furniture store repeats the same ideas everywhere: a product, its price, its options, whether it’s available, what happens next. Designed separately, each screen answers those questions slightly differently.
Image, name, attributes and price in the same order , whether a piece is full price, on sale or out of stock.
Sort kept separate from filters; applied filters visible as removable chips; result counts that stay honest.
Current price, previous price and an explicit saving , never red alone to signal a sale.
The same label, input and helper structure from the promo code to the delivery address.
Selected, unavailable, loading and error states that explain themselves in words, not just colour.
One spacing rhythm, one type pairing and one restrained palette behind all of it.
System architecture
I organised the file the way the system is meant to be used: foundations first, then tokens, type and icons, then component families, then the templates and guidelines that put them to work.
Primitive
color/olive/700Semantic
color/action/primaryComponent
button/primary/fill
Foundations
The palette is deliberately restrained , ivory, charcoal, taupe , so product photography carries the colour. Field olive is reserved for actions and selected states, never for decoration.
Lora gives headlines warmth; Inter keeps prices, labels and forms clear. A 4px spacing base keeps rhythm consistent from a chip to a full page.
Each colour is named for its role: Canvas, Raised surface, Primary text, Action / selected, Focus. Status colours always pair with a label or icon.
“Lora for the story. Inter for the shop.” Display 64 down to labels at 12, with semibold Inter for prices.
8–16px inside a control group, 24px between items, 48–80px between sections , written into the guidelines, not just the spacing scale.
A dedicated Focus colour (#566D9A) and a persistent 3px focus ring, separate from hover and selection.
Component architecture
Each component page pairs a documentation board , the component in context, with its rules , and a native library of variants. Here are the families that do the most work.
Button (13 variants) · Icon button · Chip · Badge · Tab · Navigation
One primary action per task. Buttons vary by intent , Primary, Secondary, Tertiary, Destructive , and every state is named: default, pressed, disabled, loading, focus. The header keeps 44px targets on every utility action.
Product Card (5 variants) · Filter option · Category tile
The product card keeps the same anatomy , media, name, attributes, price , whether a piece is default, on sale or unavailable. Status changes the badge and price, never the structure.
Product gallery · Gallery thumbnail · Swatch
Availability, price and the purchase action stay together. Swatches show “Selected” with a border, check and text, and “Unavailable” with a slash and an explicit label , never colour alone.
Form Field (7 variants) · Selection option · Cart Item · Order summary
Every field shares one label → input → helper structure, so validation looks the same everywhere. Totals are transparent: subtotal, delivery and “Including VAT. No additional fees.”
Commerce patterns
I assembled six full 1440px desktop templates from the same components to test whether the system holds together across a realistic journey. They demonstrate the intended experience , they aren’t a live prototype.
States
States say what’s possible, what’s happening and what to do next. Each example in the file is explicitly named , no generic variant labels, no colour-only feedback.
Default, pressed, disabled, loading (“Adding…”) and focus for the primary action; saved favourites; selected, focus and unavailable options; default → focus → error → success for fields; an empty search state.
Desktop is the only breakpoint designed so far. Responsive specifications, catalogue loading states and a full accessibility review are natural next steps.
Usage guidelines
Components alone don’t keep a system consistent; shared judgement does. The file closes with ten do/don’t comparisons , instructions, not alternate variants , and a short checklist every new pattern must pass before it joins the system.
One primary action per decision region.
Image → name → attributes → price; names, not promotional copy.
Square product media; never crop arms, legs or shades.
Current price, struck-through previous price and the saving.
Sort separate from filters; removable chips; visible result count.
Variant = Secondary, State = Focus, Status = Unavailable.
Reflection
Designing the token chain before the pages meant every later decision had a home. When the product card needed a sale state, the question wasn’t “what colour?” but “which role?”.
It also made the difference between a component library and a design system clear to me. The components are the visible part; the naming, the states and the written rules are what would let someone else use them well.
Future work
Every page referenced here , foundations, variables, components, templates and guidelines , is in the original file.