UX and UI design

TL;DR

UX/UI design is a discipline of learning what the user needs to do, structuring the interface so they can do it, and expressing that structure with typography, color, layout, and motion that make the task feel obvious. A working process runs research, IA, wireframes, visual design, systems, and handoff in sequence with meaningful gates between each stage. The failure mode is jumping straight to visual design and hoping the underlying structure works itself out.

The playbook, in one paragraph

Run five to eight user interviews plus analytics review before opening Figma, map information architecture and top three task flows before wireframing, sketch wireframes at low fidelity to make structural debates cheap, move to high fidelity only when structure is agreed, build the visual design against a real design system (tokens, components, patterns), document accessibility from the start rather than at the end, and hand off to engineering with a walkthrough call and documented component states. The compounding value comes from a system that grows instead of a project that ships and stalls.

Where this fits in the modern discovery layer

The interface is where discovery becomes conversion. Every other surface (SEO, AEO, GEO, email, paid) delivers a visitor to a screen. What that screen does in the first eight seconds decides whether the discovery investment paid back. Design is the leverage point that multiplies or destroys the ROI of every acquisition surface.

Of the 19 ranking surfaces in the Playbook, design touches five directly. Core Web Vitals (CWV) rewards layout that renders fast and stops shifting. E-E-A-T rewards interfaces that make authorship, sources, and credentials legible. Reputation platforms depend on interface flows that make asking for reviews graceful, not intrusive. VxSO depends on video thumbnails and player interfaces that read at a glance. And accessibility (baseline for every surface) rewards or penalizes the interface on structure, contrast, keyboard access, and semantic HTML.

The strategic point: a beautifully designed interface that fails accessibility is a rendering problem. A structurally sound but visually flat interface is a fixable problem. Both start with the same discipline: understanding the user's actual task before designing anything.

The five levers

1. Research that changes direction

User interviews are not a formality. Five to eight interviews per persona surface the recurring problems: the term the user uses instead of the product's jargon, the step where they abandon the flow, the reason they went to a competitor. I run these before any wireframing. If the research does not change the design direction from what the founder assumed, either the founder is unusually right or the questions were leading. Both are worth checking.

2. IA before pixels

Information architecture is where structural problems get cheap. I map the site or product as a sitemap, tag each surface with its job and its entry points, and document the top three task flows end to end. A structural error at the IA stage costs an afternoon to fix. The same error at high fidelity costs two weeks.

3. Wireframes for structural debates

Wireframes exist to make structural debates cheap. Low fidelity, no visual polish, no distraction. The team debates what goes on the page and in what order, not the color of the button. Once the structure is agreed, wireframes end. Any hi-fi work on a disputed structure is throwaway work waiting to happen.

4. A real design system, not a component library

A design system is tokens (color, spacing, typography, radius, elevation), components (button, input, modal, table, card, and their states), patterns (form, empty state, loading, error), and documentation (when to use, when not to use, accessibility notes). A component library is a Figma file with buttons in it. Systems scale. Libraries do not.

5. Handoff as a partnership, not a throw over the wall

Engineering is a design partner. I design in the same tokens engineering will build in (from day one when possible), ship components with documented states and edge cases, do a walkthrough call rather than dropping a Figma link, and stay available through implementation to answer the specific questions that always come up. Design that never survives implementation is design that got handed off wrong.

First 30 / 60 / 90 days

Days 1 to 30: research and structure

Product and business audit. What the product does, who buys it, who uses it (often different from who buys it), how the current interface performs on top task completion, where users drop off in funnels. Analytics review in GA4, Mixpanel, or Amplitude depending on the stack. Support ticket review for the recurring language of frustration.

User interviews. Five to eight per persona. Recorded, transcribed, tagged for themes. I look for the moments the user hesitated, the vocabulary they used, and the workaround they invented. Workarounds are gifts, they show where the interface failed.

Information architecture. Sitemap for marketing surfaces, screen inventory for product surfaces. Top three task flows mapped end to end with entry points, exit points, and decision states.

Metric moving in month one: a decision document naming which parts of the product experience need structural redesign versus visual refresh. This document prevents scope drift for the rest of the engagement.

Days 31 to 60: wireframes and visual direction

Low fidelity wireframes on the priority flows. Reviewed with product, engineering, and one or two customers if the engagement structure allows. Structural feedback captured and applied before high fidelity begins.

Visual exploration in parallel. Three directions at low commitment, tested against real content (never lorem ipsum, always the actual copy the product will use). Selected direction refined into a small starter component set: buttons, inputs, cards, one form pattern.

Accessibility baseline documented. Color contrast pairs tested. Focus states designed. Semantic structure planned for screen readers. This is not a polish pass at the end. It is a constraint from day one.

Metric moving in month two: two priority flows at high fidelity, accessibility documented, and the design direction approved by the stakeholder who has final say. Approval from anyone else is not approval.

Days 61 to 90: system and handoff

Design system built from the shipped patterns. Tokens defined and mirrored in the engineering codebase. Components documented with states (default, hover, focus, active, disabled, error, loading), spacing rules, and when-to-use notes. The system starts small on purpose (twelve to twenty components covering 80 percent of the interface) and expands as new surfaces get designed.

Handoff. Walkthrough call with the engineering team. Component-by-component review. Edge cases documented. Open questions logged in a shared thread that stays live through implementation.

Governance handoff. Who approves new components. Who updates tokens. Who audits accessibility. The system is a living thing. Without ownership it drifts within a quarter.

Deliverable at day 90: shipped priority flows, a working design system, accessibility documented, and a clear roadmap for months four through twelve (secondary flows, motion identity, additional components, quarterly system review cadence).

Tools I use

Figma is the design surface. Auto layout, variables, components, dev mode, prototyping. It is the environment engineering, product, and design already share, which matters more than any specific feature. I use Figma for everything from wireframes to high fidelity to system documentation.

Adobe Creative Suite for the work Figma is not the right tool for: complex vector illustration in Illustrator, photography retouching in Photoshop, motion source files in After Effects, print collateral in InDesign.

Dovetail or Notion for research repositories. Every user interview transcript, every tagged theme, every insight lives in one place the whole team can search.

Maze or UserTesting for unmoderated usability testing on prototypes. Faster and cheaper than moderated sessions for validation. I still run moderated sessions for the initial discovery interviews.

Storybook or Zeroheight for design system documentation that engineering can consume. Figma is where I design the system. Storybook is where engineering interacts with it as living code.

Loom for asynchronous walkthroughs. A five minute Loom walkthrough of a design saves two hours of back and forth in Figma comments.

Stark or the Figma accessibility plugins for contrast checking, color blindness simulation, and semantic structure validation.

GA4, Mixpanel, or Amplitude for behavior data. The tool depends on the client's stack. I read event data, funnel analysis, and retention curves before I open Figma.

What kills the program

1. Skipping research

The founder says "we know our users." Sometimes true. Usually the founder knows a version of the user from two years ago, or knows the buyer without knowing the daily user. Five interviews take a week. Rework because the interface designed against assumptions failed takes months.

2. Starting at high fidelity

The designer opens Figma and drafts a beautiful screen. Reviewers cannot debate the structure because the visual polish makes them commit to the surface. Structural problems that would have been obvious in wireframes now require throwing away hi-fi work. The polished draft is faster to make and slower to iterate.

3. Design system as afterthought

Each surface gets its own buttons, its own spacing, its own type scale. Six months in the interface looks like it was designed by six people. It was, functionally, because there was no shared system enforcing consistency. Systems designed on day one hold. Systems retrofitted at month nine are always partial.

4. Accessibility at the end

The design ships. The accessibility audit finds 40 issues. Fixing them requires rewriting components and revisiting layouts. Meanwhile the audit is finding basic issues (contrast, focus states, alt text) that would have been prevented at zero cost during initial design. Accessibility is a design constraint, not a QA step.

5. Handoff by Figma link

The designer shares the Figma link and moves to the next project. Engineering builds against their interpretation of the design. QA finds twenty inconsistencies between the design and the implementation. Every one of those inconsistencies was preventable with a thirty minute walkthrough call.

6. Ignoring content

The design uses lorem ipsum. The layout looks great with placeholder copy. Real content ships. Real content is longer, uneven, and includes edge cases the placeholder never showed. The layout breaks. Designing against real content from day one prevents this and makes the design honest.

KPIs that matter

Task completion rate. The core UX metric. For the top three tasks, what percentage of users complete the flow without abandoning. Target 85 percent or higher for critical flows.

Time on task. How long the user spends completing the flow. Target consistent time (predictability). Wide variance means the flow has an unclear step somewhere.

System Usability Scale (SUS). Standardized questionnaire administered pre and post redesign. Target above 68 (industry benchmark for "above average") within one release cycle post launch.

Accessibility conformance. WCAG 2.2 AA compliance across the priority flows. Automated tools (axe, Lighthouse) plus manual keyboard testing plus screen reader spot check.

Conversion rate lift on marketing surfaces. Redesigned homepage, redesigned pricing, redesigned checkout. Measured against pre-launch baseline over a 4 to 8 week window.

Design system adoption rate. Percentage of shipped components that use the system versus one off implementations. Target 80 percent within three months of system launch.

Engineering handoff turnaround. How many days from design signoff to implementation start. A well documented system with proper handoff shortens this significantly.

FAQ

What is the difference between UX and UI?

UX is the shape of the experience: information architecture, task flow, interaction logic, and what the interface asks of the user. UI is the visual and interactive expression of that shape: layout, typography, color, motion, and component behavior. UX is what it does. UI is how it looks and feels while doing it.

How much user research is enough before designing?

Five to eight user interviews per persona reveal about 85 percent of the recurring problems. Analytics and support tickets cover the rest. More interviews rarely change the design direction. Less than five leaves you designing against assumptions.

Do we need a design system?

If you have more than one designer, or one designer plus engineers building product for more than six months, yes. A design system pays back in month three by removing every hour spent recreating buttons, inputs, and modals. It also makes accessibility enforceable.

How do you make handoff to engineering not painful?

Design in the same tokens engineering will build in. Ship components with documented states, spacing, and edge cases. Do a walkthrough call, not just a Figma link. And treat engineering as a design partner, not a downstream vendor.

How long does a full UX/UI project take?

A marketing site redesign: 8 to 14 weeks. A product surface redesign: 12 to 20 weeks. A full product design system: 6 to 9 months to stable v1. Anything called agile is usually just shipping without the earlier stages, which shows up later as rework.

Should we start with wireframes or with hi-fi mockups?

Wireframes for structure decisions where visual polish will bias the conversation. Hi-fi mockups directly for pages where structure is already clear and the debate is about visual and interaction quality. Skipping wireframes on complex flows is a common way to redesign the same screen three times.

Related reading

• The design portfolio
• Brand strategy and identity playbook
• Conversion rate optimization playbook
• Replatforming and migration playbook
• All case studies and playbooks