Ui Ux Designer

---
name: ui-ux-designer
description: Design user interfaces and experiences from research and flows to wireframes, mockups, and usability testing.
category: creative-design
---

## Overview

UI/UX design is problem-solving made visible: understanding what users need,
structuring it into
flows, and crafting interfaces that feel obvious. This skill covers the full arc
— user research,
information architecture, wireframing, visual design, prototyping, and testing —
with an emphasis on
decisions you can defend, not just screens that look nice.

## When to use

- Designing a new app, website, or feature from scratch

- Redesigning an existing product with usability problems

- Creating user flows, wireframes, or high-fidelity mockups

- Planning and running usability tests

- Reviewing designs for UX quality before handoff

## Core concepts

- - - **Jobs to be done.** Users don't want features; they want outcomes. Frame
  every screen around
  the job: "as a [user], I want to [goal] so that [outcome]." If a screen
doesn't serve a job, cut
  it.
- - - **Hierarchy and flow.** Every screen needs one primary action and a clear
  visual hierarchy
  guiding the eye to it. Map the happy path first, then edge cases — not the
reverse.
- - - **Consistency builds trust.** Same patterns for same actions across the
  product. Users shouldn't
  have to relearn your interface on every screen; familiarity is a feature.
- - - **Progressive disclosure.** Show what's needed now; hide the rest behind
  deliberate reveals.
  Complexity should be available, not unavoidable.
- - - **Design for the edge cases.** Empty states, errors, loading, offline,
  long names, right-to-left
  text. The difference between a demo and a product lives here.
- - - **Test with 5 users.** Five usability tests uncover ~85% of issues. Test
  early with rough
  prototypes — fixing a wireframe costs nothing; fixing shipped code costs
sprints.

## Practical workflow

1. 1. 1. **Define the problem.** Who are the users, what job are they hiring
   this product for, what
   does success look like (metrics)? Write a one-paragraph problem statement
before opening any
   design tool.
2. 2. 2. **Research lightly but really.** 3-5 user conversations or
   support-ticket reviews beat
   assumptions. Capture: goals, current workarounds, pain points, mental models.
3. 3. 3. **Map the flow.** User flows for the key journeys: boxes for screens,
   diamonds for decisions.
   Identify the happy path, then branches. Cut steps ruthlessly — every screen
is friction.
4. 4. 4. **Wireframe fast.** Low-fidelity, grayscale, fast. Explore 2-3
   directions for critical
   screens. Get feedback on structure before investing in visuals.
5. 5. 5. **Design high-fidelity.** Apply visual hierarchy, the design system (or
   create the
   foundations), real content (never lorem ipsum in final mocks — content is
design), and responsive
   behavior.
6. 6. 6. **Prototype the interactions.** Clickable prototype covering the key
   flows. Prototype only
   what needs testing — full-app prototypes waste time.
7. 7. 7. **Test and iterate.** 5 moderated tests: give tasks, observe silently,
   note where users
   hesitate. Fix the top 3 issues, retest. Repeat until the flow feels boring —
boring means usable.
8. 8. 8. **Document for handoff.** Annotated specs: behaviors, states, edge
   cases, responsive rules.
   (See design-handoff-specialist for the full handoff practice.)

## Common pitfalls

- - - **Designing for yourself.** Your mental model isn't the user's. Every
  assumption should be
  tested or at least acknowledged as one.
- - - **Dribbble-itis.** Optimizing for visual impressiveness over usability.
  Beautiful screens that
  confuse users are failed designs.
- - - **Skipping the flow.** Designing screens without mapping the journey
  produces disconnected
  experiences and missed states.
- - - **Lorem ipsum forever.** Designing around fake content, then cramming real
  content in later.
  Real headlines, real names, real edge-case strings from the start.
- - - **Ignoring accessibility.** Low contrast, tiny tap targets, keyboard
  traps. Accessibility isn't
  a phase — it's part of every design decision (see
accessibility-design-checker).
- - - **Falling in love with the first idea.** The first solution is rarely the
  best. Explore broadly
  at low fidelity before committing.