The UI/UX Design Process, Explained Through Real Case Studies

Most people think "UI/UX process" means a stack of deliverables: personas, wireframes, a Figma file with fifty artboards. In practice it's simpler than that, and far less linear. It's a discipline for making decisions in the right order, so you don't design the visual layer before you understand the problem, and you don't code a flow before you've watched someone try to use it.

I've run this process, in one form or another, on every project in my portfolio: a furniture storefront, a footwear brand's landing page and sign-in flow, a fashion e-commerce site, and a travel blog. The tools and the visual language change from project to project. The order almost never does: discover, wireframe, design, prototype, build.

Why process matters more than the tool

It's tempting to judge a designer's process by their software: Figma versus Sketch, this plugin versus that one. None of that is the actual skill. The skill is knowing which questions have to be answered before you're allowed to move to the next stage, and having the discipline to actually answer them instead of skipping ahead to the part that photographs well for a portfolio.

Skip discovery and you get a beautiful interface for the wrong problem. Skip prototyping and you ship a flow nobody tested, and find out it's broken from support tickets instead of a usability session. The five stages below aren't a formality: each one exists because skipping it has a specific, predictable cost.

Step 1: Discover, research before you open Figma

Every project starts with constraints, not colors. Before I sketch anything, I want answers to three questions: who is this for, what are they trying to do, and what's actually stopping them right now?

For HomeLoom, a furniture e-commerce concept, the starting brief was about craft and material, but the real design problem was friction in the shop-to-cart journey. Furniture shopping is high-consideration; people compare, second-guess, and abandon carts more than almost any other product category. So discovery wasn't just "what should this look like," it was "where does hesitation happen, and how do we design for it instead of against it."

The discovery phase is where you decide what a project is actually about, not the brand's stated goal, but the underlying user behavior you're designing around. Get this wrong and every decision downstream inherits the mistake.

Step 2: Wireframe, structure before style

Wireframes are where I make layout and hierarchy decisions with none of the distraction of color, type, or imagery. This is deliberate. If a wireframe only works because the hero photo is beautiful, the structure underneath it is doing too little of the job.

A wireframe that nobody argues about usually isn't finished; it just hasn't been looked at closely enough yet.

I keep wireframes low-fidelity long enough to test the argument: does this order of information actually answer the user's questions in the order they ask them? For an e-commerce flow like Glam, that meant deciding early whether the product grid or the editorial lookbook content should lead the homepage: a decision that shapes everything downstream, and one that's much cheaper to get wrong in grayscale boxes than in a finished comp.

Step 3: High-fidelity design, where the brand shows up

Once the structure holds up under scrutiny, I move into high-fidelity screens with a real content and component system: actual copy, real product photography (or stand-ins close enough to be honest), and a type and color system consistent enough to reuse across every page, not just the hero.

Editorial fashion: Glam

Glam is a good example of how visual style has to serve shopping behavior, not just a mood board. Fashion e-commerce customers browse the way they'd flip through a lookbook, so the interface leans into a dusty, editorial palette and generous imagery, while keeping the product grid, filters, and cart mechanics conventional enough that nobody has to relearn how to shop.

Warmth and material: HomeLoom

HomeLoom took the opposite emotional register: warm tones, tactile textures, and typography that reads more like a craft brand than a big-box retailer, because the goal was to make a considered, higher-cost purchase feel less transactional and more like a decision worth taking time over.

The lesson that repeats across both projects: high-fidelity design isn't "add the final colors." It's translating a brand's actual sales psychology into layout, type, and imagery decisions that a customer feels before they consciously notice them.

Step 4: Prototype and test, catching friction before it ships

This is the step that gets skipped most often, and it's the one that pays off the most. Streets to Runways, a footwear brand landing page and sign-in flow, is the clearest example in my portfolio of why it's worth the extra week.

The original sign-in and checkout flow ran five steps: account details, shipping, verification, payment, and confirmation, each on its own screen. It worked. It also lost people along the way. Usability testing on the interactive prototype (watching real users move through it, not just asking what they thought afterward) showed exactly where the drop-off happened: two of those steps were re-collecting information the user had effectively already given, just in a different form.

• Combined shipping and verification into a single step, since both were collecting contact information
• Moved payment method selection earlier, ahead of the final confirmation screen, to remove a late decision point
• Cut the flow from five steps to three without removing a single required field

None of that came from a hunch. It came from watching people hesitate at the same point, twice, in a row, in a recorded session. That's the value of prototyping before build: it's far cheaper to move a form field in a prototype than to refactor a checkout flow after it's already in production and already losing customers.

Step 5: Build, where design meets code

I hand-code most of my own front-ends, and that changes how I design. When you know you're the one who has to implement a hover state, a breakpoint, or a loading pattern, you stop designing things that only work at the one artboard size you happened to be looking at when you made them.

The build phase is a second usability test, this time against real browsers, real fonts loading asynchronously, and real thumbs on real screens, not a static comp. Spacing that looked generous in Figma sometimes needs to shrink on mobile. A carousel that felt smooth in a prototyping tool needs actual momentum scrolling and touch targets that meet a reasonable minimum size, not just a visual approximation of one.

What ties these projects together

WanderLust Diaries, a travel blog concept, is a useful counterexample to the others, because its design brief was almost the opposite of HomeLoom's or Glam's: get out of the way. The process was the same five steps, but the outcome leaned on large-format photography and minimal chrome, because the thing being "sold" was the feeling of a place, not a physical object with a price tag and a comparison table.

That's really the point of having a repeatable process. It doesn't produce the same-looking output every time; it produces the right output every time, because the discovery phase tells you what "right" means before you've spent hours designing toward the wrong goal.

A quick process checklist

• Discover: identify the real behavior you're designing around, not just the stated brief
• Wireframe: prove the structure works in grayscale before adding any style
• Design: build a real, reusable component system, not a one-off comp
• Prototype: test with real users before a line of production code is written
• Build: treat implementation as a second, more honest usability test

If you're planning a product, storefront, or landing page and want a process that catches friction before it ships instead of after, I'd like to hear about it. Get in touch and let's talk through what you're building.