# Designing a User Experience

The UI is what users see; the UX is how it feels to get something done. Start from what users want to do, plan the flow and sketch a wireframe before writing code, then make every screen clear, consistent, honest about what's happening, and usable by everyone. Then watch real people try it.

Apprentice · Web Development · Software Development · Updated November 3, 2026

## After this lesson you can

- Plan a page from the user's goal, with a user flow and a wireframe
- Improve a page with clear feedback, consistency and accessibility

## Key takeaways

- The UI is what users see and touch; the UX is how it feels to get something done.
- Start from the user's goal: write the user flow and sketch a wireframe before writing code.
- Use plain words, make the same thing always look and work the same way, and when something fails, tell users what they can do about it.
- Label every input with a `<label>`, use real buttons, and don't rely on color alone, so everyone can use the app.
- Watch three to five real people try a real task without helping them, and fix where they hesitate or click the wrong thing.

Two apps can have the same features, and one feels effortless while the other makes you want to throw your phone. The difference is the **user experience**.

## UI and UX

| | Means | Example |
|---|---|---|
| **UI**, user interface | What users **see and touch**: buttons, colors, fonts, layout | A blue **Sign in** button in the top corner |
| **UX**, user experience | How it **feels** to get something done: easy or frustrating, quick or slow | Signing in takes one try, and you land on the page you wanted |

A beautiful UI can still be a bad experience: a gorgeous form that loses everything you typed when one field is wrong. Good UX is mostly invisible: things simply work the way people expect.

## Start from the user's goal

People don't come to an app to use its features. They come to **get something done**. So design starts with questions, not screens:

- **Who** will use it? A learner on a phone on the bus, an admin at a desk?
- **What** are they trying to do? Practice for a test, find a product, fix a typo in a category?
- **What** would make them give up?

Take a quiz app, where learners answer multiple-choice questions and get a score. A learner's goal isn't "use the quiz feature". It's "find out if I'm ready for my test, in ten minutes".

### A user flow

A **user flow** lists the steps a user takes to reach their goal:

```text
Home → Choose a quiz → Question 1 → ... → Question 10 → Score, with what to review → Home or try again
```

Writing it out shows problems early. Can they stop halfway and come back? What if they choose the wrong quiz? Does the score page say what to do next, or just show a number?

### A wireframe

A **wireframe** is a rough sketch of one screen: boxes and labels, no colors, no real text. Draw it on paper, or in a tool such as Figma, **before** writing code. Moving a box on paper takes a second; moving it in Angular takes an afternoon.

![A wireframe of one quiz question screen: at the top "Question 3 of 10" and a progress bar; below it the question text; four wide answer buttons stacked vertically; at the bottom a Next button, grayed out.](https://fsdtrainingmedia.blob.core.windows.net/public/images/2026/11/8d726fa9737d417c99eb91c6e9d82966.webp)

The quiz question screen, sketched:

- **"Question 3 of 10"** and a progress bar: the user always knows how far they've come.
- **One question per screen**, so it fits a phone without scrolling.
- **Big answer buttons**, easy to tap with a thumb.
- **Next** is disabled until an answer is chosen, so nobody skips a question by accident.

## Make every screen clear

A few principles cover most of good UX.

**Clarity.** Every screen has one main job, and its most important button looks most important. Use plain words: *Add a product*, not *Submit*; *Your order is on its way*, not *Status: 3*.

**Consistency.** The same thing always looks and works the same way: the same button style for every main action, the menu in the same place on every page. Bootstrap helps a lot: `btn-primary` for the main action, `btn-outline-secondary` for the rest, on every page.

**Feedback.** Never leave users guessing. Show *Loading...* while waiting, as in *Signals and Observables Together*. Confirm what happened: *Trail Mix was added*. And when something fails, say what the user can do about it. The messages in this course's examples, such as *Sorry, the products couldn't be loaded (500).*, show the status code to help **you** while you learn. A real user doesn't know what 500 means. Tell them what happened and what to do, *We couldn't load the products. Check your connection, and try again*, with a **Try again** button, and keep the status code in your logs.

**Forgiveness.** People make mistakes. Ask before deleting, keep what they typed when a field is wrong, and offer *Undo* where you can.

## Make it work for everyone

**Accessibility** means people can use your app whatever their abilities: with a screen reader, without a mouse, with poor eyesight or color blindness. It's also the law for many sites, and it makes apps better for everyone.

- **Label every input.** A screen reader reads the `<label>`. A placeholder disappears as soon as you type, so it's no label. The sign-in forms in this course use only placeholders, to keep the examples short; in your own apps, add a `<label for="...">` for each box.
- **Use real buttons and links.** A `<button>` works with the keyboard and screen readers; a clickable `<div>` doesn't.
- **Contrast.** Light gray text on white is hard to read. Bootstrap's colors are chosen with contrast in mind.
- **Don't rely on color alone.** A red border means nothing to a colorblind user: add the words *Required*.
- **Alt text.** Every picture that carries meaning gets an `alt` describing it.
- **Try the keyboard.** Put the mouse away, and use **Tab**, **Enter** and **Space**. Can you do everything?

And remember **mobile first**, from *Mobile-First Layouts with Bootstrap*: many users will only ever see your app on a phone.

## Watch real people

You can't judge your own app: you know where everything is. Ask a few people, even three to five, to do a real task, such as *"Add a product called Trail Mix"*, while you **watch, without helping**. Where they hesitate, click the wrong thing, or ask *"what does this mean?"*, the design needs work. It's the cheapest, fastest way to find UX problems, and it's humbling every time.

## Check yourself

2 questions to try on the lesson page.

## So what

Start from what users want to get done, sketch the flow and the screens before coding, then make every screen clear, consistent, honest and usable by everyone. Then watch real people try it, and fix what trips them up.

## Key terms

- User Interface
- User Experience
- User Flow
- Wireframe
- [Accessibility](https://www.ask-codey.com/glossary/accessibility)

## Cheat sheets

- [Designing a User Experience](https://www.ask-codey.com/cheat-sheets/ui-and-ux-designing-a-user-experience-cheat-sheet)

Source: https://www.ask-codey.com/lessons/ui-and-ux-designing-a-user-experience