Role 2: UI/UX Designer
Decides how it looks and how users move through it. Visual hierarchy, user flow, trust.
The Excel Analogy
This role has a direct parallel to something every CA has experienced — and the quality difference it creates is identical.
You have seen this at every CA firm. Two people create reports from the same data. One report has dense columns of numbers, inconsistent fonts, some cells highlighted in yellow for no apparent reason, and tables that start in different columns on each page. The other report has consistent formatting, a clear hierarchy, color coding that means something, and a summary at the top that tells you the conclusion before you read the detail.
Both reports are factually identical. But the second one gets read. The first one gets questions like "can you simplify this?"
The person who created the second report was acting as a designer — even if they never used that word. They decided which information should be prominent, which should be secondary, what the eye should land on first, and what color red means in this context (and that it means the same thing on every page).
In software, this is the UI/UX Designer. They decide what the formatted, client-facing experience looks like — and they think about it before anyone writes a single React component.
What This Role Decides
UI (User Interface) — what is on the screen:
- Which buttons exist and what they say
- Where information is placed on the page
- What colors, fonts, and spacing are used
- What feedback the user gets when they do something (loading state, error message, success message)
UX (User Experience) — how the user moves through the app:
- Which page comes after which
- How many steps does a task take?
- What happens when someone makes a mistake?
- What does a first-time user see versus a returning user?
- Where do users get confused or give up?
The distinction matters. A button that is the wrong color is a UI problem. A checkout flow that makes users fill the same form twice is a UX problem. Both matter. Both are the Designer's job.
Concrete Examples
| Decision | UI or UX? | Example |
|---|---|---|
| The "Pay Now" button is green | UI | Color signals a positive action |
| The fee payment confirmation appears immediately after payment | UX | Reduces anxiety about whether the payment worked |
| Error messages appear in red next to the field that failed | UI + UX | Users know exactly where to fix the problem |
| Onboarding has 3 steps instead of 1 long form | UX | Reduces overwhelm, increases completion rate |
| The app uses the same blue for every link | UI | Consistency builds familiarity and trust |
| A progress bar shows which step of 4 you are on | UX | Users know how much is left; they do not abandon |
The Trust Problem
Here is something that is counterintuitive until you have seen it in the real world.
Two apps. Identical features. Identical prices. Identical security. One looks like it was designed by a professional. One looks like a government form from 2009.
Which one do users trust with their credit card? The professional-looking one. Every time.
Both forms collect the same information. The professional version uses consistent spacing, clear labels, contextual hints, and a logical button hierarchy. The amateur version works — but it signals that the app was not built with care. Users feel that.
Design is not decoration. Design is trust. In consumer apps, the visual quality of the interface is a proxy for the quality of the company. Users cannot see your database schema. They cannot audit your security. What they can see is whether your buttons are consistent, whether your typography looks intentional, and whether the app feels like it was built by people who care.
This is why the Designer role is not optional — even for a developer who "just wants to ship something functional."
When You Are in This Role
Put on the Designer hat:
- After the Product Owner has defined what is being built, but before any code is written
- When you are sketching flows on paper or a whiteboard (even rough boxes and arrows)
- When you are choosing which shadcn/ui components to use for a new screen
- When a screen looks "wrong" but you are not sure why — stop and think like a designer
- When you are writing copy for buttons, labels, and error messages
- When you are deciding what a user sees immediately after they complete an action
Common Mistakes When You Skip This Role
Designing while coding. The most common trap. You start building a screen and make design decisions on the fly — "I'll put the button here for now" and "I'll figure out the layout later." Three hours later you have a screen that works technically and feels incoherent visually. You then spend another three hours rearranging things you could have sketched in 15 minutes.
Inconsistency across screens. Every screen was built at a different time with a slightly different idea of what things should look like. The fee payment screen uses one shade of blue. The profile screen uses a different shade. One screen uses a card layout. Another uses a list. Users cannot build a mental model of the app because it behaves differently everywhere.
No empty states, loading states, or error states. You design the happy path — what the screen looks like when everything works and there is data. You do not design what it looks like when the list is empty, when the data is loading, or when something goes wrong. Users encounter these states constantly and find them confusing or alarming.
Every screen has three states you must design: loading (while data arrives), with data (the happy path), and empty (when there is nothing yet). The empty state — often neglected — is frequently the first thing a new user sees. It should tell them what to do next, not just display a blank page.
Writing labels as a developer, not as a user. A developer labels a button Submit Form. A designer labels it Book Appointment. A developer shows the error 400 Bad Request. A designer shows Please enter a valid phone number. Users do not speak developer.
Left: three screens in the same app — each with different button styles, sizes, and colors, because each was built at a different time with no design system. Right: the same three screens after applying a design system — one button style, one card style, one heading style. The app on the right feels trustworthy. The one on the left feels like it was assembled by different people.
Consistency is more important than creativity. Pick a design system and stick to it. We use shadcn/ui and Tailwind. Every button follows the same pattern. Every card follows the same pattern. Deviating from the system to make one screen look "interesting" creates confusion. The best-designed apps are the ones where users never think about the design — because it gets out of the way.
A Designer's Vocabulary You Need to Know
| Term | What it means | Excel analogy |
|---|---|---|
| Design system | A set of reusable rules and components that keep the app visually consistent | Your firm's report template — consistent formatting on every document |
| Component | A reusable UI building block (button, card, input field) | A named cell style that you apply everywhere |
| Hierarchy | Making important things visually prominent and secondary things less so | Bold for total rows, regular for line items |
| White space | Empty space used intentionally to make content breathable and readable | Margins and padding in a well-laid-out report |
| User flow | The sequence of screens a user moves through to complete a task | The steps in a process memo |
| Call to action | The primary button or action on a page | The "Approve" stamp on a document |
| Skeleton screen | A loading state that shows the shape of content before it loads | A report template with placeholder cells before data is pasted in |
How Claude Code Helps in This Role
Generate a user flow description:
"I am building a school management app. Describe the complete user flow for a parent paying their child's school fee — from opening the app to a confirmed payment. List every screen the user sees and every decision they make."
Review a screen for UX problems:
"Here is my current fee payment screen [describe it or paste the code]. What would confuse a first-time user? What is missing? What should I change?"
Write user-facing copy:
"Write the button label, page title, and error messages for a form where users enter their address. The app is a home cleaning service. Keep the tone professional but warm."
Generate Tailwind layout code:
"Create a responsive card layout for a list of available cleaning services. Each card should show: service name, price, duration, and a 'Book Now' button. Use shadcn/ui Card component and Tailwind."
What Claude struggles with in this role:
- Genuine aesthetic taste (it can follow rules, not break them creatively)
- Understanding your specific brand personality
- Knowing what "feels off" when you cannot articulate why
How to Switch Into This Role
Before you design any screen, say:
"I am not a developer right now. I am the first user of this screen. I have never seen this app before. What do I see? What do I click? What do I do if something goes wrong?"
Then sketch the screen with pen and paper — not in code. Even badly-drawn boxes and arrows. The point is to make design decisions before writing code, not while writing it.
Ask these questions about every screen you design:
- What is the ONE thing the user should do on this screen?
- Can someone understand the purpose of this screen in 3 seconds?
- What happens if there is no data yet?
- What happens if something goes wrong?
- What does the user see immediately after they complete the primary action?
Exercise
Open any app on your phone that you use regularly — your bank app, a food delivery app, a government service.
Pick one screen and answer:
Write down your observations. You are now thinking like a designer.
Next, open an app that you find frustrating to use. Do the same exercise. Compare. The difference between the two experiences is almost entirely design — not features.