Good visual design is a set of learnable decisions, not a talent you either have or lack. This beginner course covers the principles behind clear screens: visual hierarchy, grids and whitespace, and the Gestalt principles of grouping; typography, colour and contrast that meet accessibility guidelines, and consistent icons and imagery; and the everyday tools of the job: frames and auto layout in Figma, reusable components and styles, and structured design critique. Each lesson has a short reading, curated videos and a hands-on task on paper, in free Figma or in a small HTML and CSS exercise. It prepares you for UX design, game design and front-end work.

Learn hierarchy, layout, type, colour and icons, then build and critique real screens in Figma.

Visual Design Fundamentals

Take a screenshot or photo of the design. Write one sentence: what should a viewer notice or do first?

Do the squint test: blur your eyes or step back. List the top three things you notice, in order.

Compare that list with your sentence. Note where the order is wrong or where elements compete equally.

List every element and label it 1 (primary), 2 (secondary) or 3 (everything else). Allow only one 1.

Sketch a new version. Change at least three tools: size, weight, colour, position or space. Keep one accent colour for the primary action.

Show your sketch to someone for five seconds, then hide it. Ask what it was about and what they could do next. Write down their answers.

Adjust anything they missed and save a photo of the before and after side by side.

## Why it matters

Every screen, poster or slide asks the viewer to do something: read a headline, press a button, notice a warning. People do not read a screen from top-left to bottom-right like a book. They glance, pick out one or two things that stand out, and decide in a second or two whether to keep looking. **Visual hierarchy** is the order in which the eye moves through a design. If you control it, the viewer sees the important thing first. If you do not, they see whatever happens to be biggest or brightest, which is often the wrong thing.

## The core idea

Hierarchy comes from **contrast**: an element stands out when it is different from what is around it. You have a small set of tools for creating that difference:

- **Size.** Bigger elements are seen first. A headline at twice the body size reads before the body.
- **Weight.** Bold text and thick shapes pull attention from thin ones.
- **Colour and contrast.** A saturated or dark element on a light, calm background jumps out. One bright colour on a mostly neutral screen works like a pointer.
- **Position.** In left-to-right languages, people tend to start near the top-left and scan down. Things placed high and near the start are noticed earlier.
- **Space.** An element with generous empty space around it looks more important than one crowded by neighbours.
- **Shape and imagery.** Faces, photos and unusual shapes attract the eye before text does.

The key is restraint. If everything is bold, nothing is. A good design usually has **three levels**: one primary element (the main message or action), a few secondary elements (supporting headings, key facts), and everything else as quiet tertiary content.

## A worked example

Here is the text for an event page, all at the same size and weight:

```text
Community Code Night
Thursday 14 November, 6-9 pm
Main Library, Room 2
Bring a laptop. Beginners welcome. Free pizza.
Register now
```

Everything shouts equally, so nothing reads first. Decide what the viewer must take away. For this page: **what it is** (primary), **when and where** (secondary) and **the action** (the button stands out by colour, not by size).

A better arrangement:

1. "Community Code Night" at about 2.5 times the body size, bold, at the top.
2. Date and place on two lines below, at about 1.25 times body size, regular weight, darker grey.
3. The friendly details in body text with comfortable line spacing.
4. "Register now" as a button in the page's one accent colour, with space around it.

Now a passer-by who looks for one second gets the event name. Two seconds gets the time and place. Interested people find the button without searching.

## Two quick tests

- **The squint test.** Step back from your screen or blur your eyes. The shapes that survive the blur are your top level. If the wrong thing survives, or nothing does, adjust size or contrast.
- **The five-second test.** Show the design to someone for five seconds, hide it, and ask what it was about and what they could do. If they cannot answer, the hierarchy is not doing its job.

## Hierarchy in interfaces

On app screens hierarchy also tells people what they can do. A screen should normally have **one primary action** styled as a filled button. Other actions are secondary (outlined or text buttons). If a form has two filled buttons, "Save" and "Delete", users hesitate, and some press the wrong one. Make the safe, common action primary and the rare or destructive one quieter.

Page titles, section headings and labels also form a hierarchy. In HTML this is the heading order (`h1`, then `h2`, then `h3`), which screen reader users rely on to navigate. Visual size should match that structure: an `h3` should never look bigger than the `h2` above it.

## Common mistakes

- **Too many levels.** Five font sizes and four colours create noise. Use few, clearly different steps.
- **Differences that are too small.** 16px next to 17px looks like a mistake, not hierarchy. Make steps obvious (for example, at least 1.2 times bigger).
- **Decoration that competes.** A bright illustration can steal attention from the button you actually need people to press.
- **Using colour alone.** Some people cannot tell certain colours apart. Back up colour with size, weight, position or an icon.

## Quick recap

- Visual hierarchy is the order the eye reads a design; you create it with contrast.
- Your tools are size, weight, colour, position, space and imagery.
- Aim for one primary element, a few secondary ones, and calm everything else.
- Check with the squint test and the five-second test.

## Try it

Open the **Do** tab. You will rank the elements of a real screen, redesign it on paper or in Figma, and test it on another person.


Arrange size, weight, colour and position so the most important element is seen first.

Visual hierarchy

Visual Hierarchy

Hierarchy | Basic Principles of Graphic Design [Ep. 01]

Draw or create a 360 by 640 frame. On paper, use 45 by 80 squares at one square per 8px.

Add a 4-column grid with 16px margins and 16px gutters (in Figma: select the frame, then Layout grid > Columns).

Write down your spacing scale before you start: 4, 8, 16, 24, 32, 48.

Place the card so its left and right edges sit on the margins. Give it 16px padding inside.

Place the avatar, name, title and bio, using 4px for items that belong together and 16px between groups.

Add two 48px-tall buttons side by side with an 8px gap, 24px below the bio.

Measure every gap. Change any value that is not on your scale.

Squint at the card. Check that the groups (identity, bio, actions) are visible from spacing alone.

## Why it matters

When elements line up and the gaps between them follow a pattern, a screen looks calm and trustworthy, even if the viewer cannot say why. When every gap is slightly different and edges almost-but-not-quite line up, the design feels messy. Layout is also practical: a consistent system makes decisions faster for you, and it makes the design much easier for a developer to build.

## The core idea: columns and spacing

A **layout grid** is a set of invisible guides that you place content on. Most screen grids have three parts:

- **Columns**: vertical strips that content spans. Phones commonly use 4 columns, tablets 8, desktops 12.
- **Gutters**: the gaps between columns (for example 16px on mobile, 24px on desktop).
- **Margins**: the space between the outer columns and the edge of the screen (often 16 to 24px on mobile).

A card might span all 4 columns on a phone, 4 of 8 on a tablet and 4 of 12 on a desktop. The grid does not force every element to fill a column exactly, but edges of major blocks should land on column lines.

## The 8-point spacing system

The **8-point grid** is a simple rule: every size and space is a multiple of 8 pixels. Typical spacing steps are 8, 16, 24, 32, 48 and 64. A 4px half-step is allowed for small adjustments such as the gap between an icon and its label.

Why 8? It divides evenly at the common screen densities (1x, 1.5x, 2x, 3x), it gives enough steps without too many choices, and it is widely used, so developers often already have matching spacing tokens. The exact number matters less than having a scale and sticking to it.

## A worked example: a profile card on a phone

Frame: 360 by 640 (a common small-phone size). Grid: 4 columns, 16px margins, 16px gutters.

```text
Card padding ............ 16
Avatar .................. 64 x 64
Avatar to name .......... 16
Name to job title ....... 4   (they belong together)
Title to bio ............ 16
Bio to buttons .......... 24  (a new group)
Button height ........... 48  (a comfortable tap target)
Gap between buttons ..... 8
```

Notice that the spacing tells a story. Name and job title are 4px apart because they are one unit. The buttons sit 24px below the bio because they are a separate group. Small gaps join things; large gaps separate them. That idea, **proximity**, is covered more in the next lesson.

## Whitespace is not wasted space

**Whitespace** (or negative space) is any empty area, whatever its colour. Beginners often fill every gap because empty space feels like wasted space. In practice whitespace:

- **Groups content**, as in the card above.
- **Creates focus.** An element surrounded by space looks important.
- **Improves reading.** Generous line spacing and paragraph spacing make text easier to scan.

**Micro whitespace** is the small space inside components: padding in a button, space between lines. **Macro whitespace** is the large space between sections. Both matter. A crowded button with 2px padding looks cheap even on an otherwise roomy page.

## Alignment

Pick a small number of alignment lines and use them again and again. Left-aligned text is easier to read than centred text for anything longer than a couple of lines, because each line starts in the same place. Centred layouts suit short, symmetrical content such as a title over a single button.

A simple check: draw vertical lines down the left edges of your elements. If you count more than three or four different lines on a simple screen, tidy them up.

## Responsive thinking

Screens vary in width, so layouts must adapt. Designers usually design a small and a large version and decide what changes: the number of columns content spans, which elements stack, and which spaces grow. Spacing tokens can scale too, for example 16px section gaps on mobile and 32px on desktop, while staying on the 8-point scale.

## Common mistakes

- **Random values.** Gaps of 13, 17 and 22px suggest nobody decided. Snap them to the scale.
- **Equal spacing everywhere.** If every gap is 16px, the viewer cannot tell which items belong together.
- **Ignoring the margins.** Text touching the edge of a phone screen is hard to read and looks broken.
- **Tiny tap targets.** Keep buttons and tappable rows at least about 44 to 48px tall.

## Quick recap

- A layout grid has columns, gutters and margins; big blocks line up to it.
- The 8-point system uses multiples of 8 (with 4 for fine adjustments) for every size and space.
- Small gaps group, large gaps separate. Whitespace creates focus and readability.
- Keep alignment lines few and consistent.

## Try it

Open the **Do** tab and lay out a profile card on a 4-column, 8-point grid, on graph paper or in free Figma.


Use columns, an 8-point spacing system and whitespace to lay out a clean, consistent screen.

Layout, grids, and whitespace

8 Point Grid system - Improve your UI designs (Figma file included)

White Space | Basic Principles of Graphic Design [Ep. 04]

## Why it matters

People do not see a screen as a list of separate pixels, boxes and words. The brain automatically groups what it sees into larger patterns: this label goes with that field, these three cards are a set, that row of icons is a toolbar. **Gestalt principles**, described by German psychologists in the early 20th century, explain how that grouping works. If your layout agrees with these instincts, people understand the screen without effort. If it fights them, they misread it, for example by matching a label to the wrong input.

## The core principles

### Proximity

Things that are **close together** are seen as a group. This is the strongest and cheapest grouping tool you have, because it needs nothing but space.

A form where every label sits exactly halfway between two fields is confusing: which field does "Email" belong to? Move each label 4px above its own field and 24px away from the field above, and the pairing becomes obvious.

### Similarity

Things that **look alike** (same colour, shape, size or style) are seen as related. If every link on a page is blue and underlined, a new blue underlined word will be read as a link. That is useful, and it is also a trap: if you make a plain heading blue, people will try to click it.

Similarity also lets you break a pattern on purpose. In a row of grey tags, one tag in the accent colour reads as "selected".

### Common region

Elements inside the **same boundary** (a card, a panel, a shaded background) are seen as a group, even if they are not very close. Cards on a dashboard work this way. Common region is stronger than proximity, so use it when spacing alone is not enough, but do not box everything: too many borders add clutter.

### Continuity

The eye follows **lines and curves**. Items arranged along a line, such as a horizontal row of steps or a timeline, are read as a sequence. Breadcrumbs and progress steppers use continuity.

### Closure

People **fill in missing parts** of a shape. A circle drawn with a small gap still reads as a circle. Many icons rely on closure, and so do carousels where a card peeking in from the edge hints that there is more to scroll.

### Figure and ground

The brain separates a **figure** (the thing you look at) from the **ground** (the background). A modal dialog with a dimmed backdrop uses this: the dialog becomes the figure and the page behind it becomes ground.

### Common fate

Elements that **move together** are seen as a group. When you drag a selected set of files and they all move, you understand they are one selection.

## A worked example: a settings screen

Imagine a settings screen with ten toggles listed with equal spacing. It works, but it is hard to scan. Apply the principles:

1. **Proximity**: split the toggles into three groups (Notifications, Privacy, Display) with 32px between groups and 8px within.
2. **Common region**: put each group on a lightly shaded card.
3. **Similarity**: make every toggle and every label the same style, so differences are meaningful.
4. **Hierarchy** (from lesson 1): give each group a short heading.

The same ten toggles now read as three understandable sections.

## When principles conflict

Principles can pull in different directions. If two items are close together but look different, or far apart but share a card, the viewer has to work out which signal wins. Common region usually beats proximity, and proximity usually beats similarity. The safest design makes the signals agree: related items are close, look alike and share a region.

## Common mistakes

- **Equal spacing everywhere**, so nothing groups.
- **Accidental similarity**, such as styling non-clickable text like a link or a button.
- **Boxes inside boxes inside boxes.** Common region overused becomes noise; often whitespace alone is enough.
- **Labels floating between fields.** Always place a label clearly nearer to its own control.

## Quick recap

- The brain groups what it sees automatically; Gestalt principles describe how.
- Proximity (closeness) and similarity (look-alike) are your everyday tools.
- Common region, continuity, closure, figure-ground and common fate add more ways to group.
- Make the signals agree so the grouping is unambiguous.

## Try it

This lesson is quiz only. Open the **Do** tab and test yourself on which principle explains each layout.


Group related elements with proximity, similarity, common region and continuity so screens explain themselves.

Gestalt principles

The Gestalt Principles for User Interface Design

Gestalt Principles

Make the important thing read first: hierarchy, grids, whitespace and the way people group what they see.

Design Principles

## Why it matters

Most interfaces are mostly text: labels, buttons, headings, messages, articles. Typography is how that text looks and how easy it is to read. Good typography is nearly invisible; people just read. Poor typography makes them squint, skip lines or give up. Because text is everywhere, a few typographic decisions affect the whole product.

## The vocabulary

- **Typeface** (or font family): a designed set of letters, such as Georgia or Inter. A **font** is one style of it, such as Inter Bold.
- **Serif** typefaces have small strokes at the ends of letters (Georgia, Merriweather). **Sans-serif** typefaces do not (Arial, Inter, Roboto). **Monospace** typefaces give every character the same width (used for code).
- **Weight**: how thick the strokes are, from thin (100) to black (900). Regular is 400, bold is 700.
- **Size**: on screens, usually set in pixels or `rem` (1rem is normally 16px).
- **Line height** (leading): the vertical distance between lines.
- **Measure**: the length of a line of text, in characters.

## Choosing and pairing fonts

You rarely need more than **two typefaces**, and one family with several weights is often enough. Common, reliable pairings:

- A **serif for headings** and a **sans-serif for body**, or the reverse. The contrast in style makes headings distinct.
- **One sans-serif family** using weight and size for hierarchy (bold headings, regular body). This is the most common choice in product interfaces.

When pairing, look for contrast in style but similarity in proportions: fonts with a similar x-height (the height of lowercase letters) sit well together. Avoid pairing two fonts that are only slightly different; it looks like a mistake.

For UI work, choose typefaces designed for screens with clear, open letterforms, where similar characters (capital I, lowercase l and the number 1, or O and 0) are easy to tell apart. Free, well-made families are available from Google Fonts; check the licence for each.

## Setting a type scale

A **type scale** is a fixed set of sizes made by multiplying a base size by a ratio. With a 16px base and a ratio of 1.25 (called a "major third"):

```text
small   16 / 1.25      = 12.8px
body    16px
h3      16 x 1.25      = 20px
h2      16 x 1.25^2    = 25px
h1      16 x 1.25^3    = 31.25px
```

Larger ratios such as 1.333 or 1.5 give more drama, suited to marketing pages; smaller ones such as 1.2 suit dense apps. Like the 8-point grid, a scale stops you inventing random sizes and gives developers a short list of tokens.

## Making text readable

- **Body size**: at least 16px for long reading on screens. Small labels can go a little smaller, but not much.
- **Line height**: about 1.4 to 1.6 times the font size for body text; headings can be tighter, around 1.1 to 1.3. Long lines need a little more leading.
- **Measure**: about 45 to 75 characters per line. In CSS, `max-width: 65ch` is a quick way to get there.
- **Alignment**: left-align body text. Avoid justified text on the web; it creates uneven gaps between words.
- **Contrast**: dark grey on white is easier on the eyes than pure black for some readers, but it must still pass contrast checks (next lesson).

A worked CSS example:

```css
body { font-family: Inter, Arial, sans-serif; font-size: 16px; line-height: 1.5; }
h1, h2 { font-family: Georgia, serif; line-height: 1.2; }
h1 { font-size: 31.25px; }
h2 { font-size: 25px; }
p { max-width: 65ch; }
```

Font names are a list: the browser uses the first one it has, so always end with a generic family such as `serif` or `sans-serif`.

## Common mistakes

- **Too many fonts and sizes.** Three typefaces and nine sizes look chaotic.
- **Body text that is too small or too light.** Thin weights at small sizes are hard to read.
- **Very long lines.** Text that runs the full width of a desktop screen makes readers lose their place.
- **ALL CAPS for long text.** Capitals are harder to read in bulk; keep them for short labels.
- **Decorative fonts for body copy.** Save script and display fonts for large, short headlines, if at all.

## Quick recap

- Use one or two typefaces; pair them by contrast in style and similarity in proportion.
- Build sizes from a type scale (base 16px times a ratio such as 1.25).
- Body text: at least 16px, line height about 1.5, line length 45 to 75 characters, left-aligned.

## Try it

Open the **Do** tab. You will fix a page where every heading and paragraph is the same size and font, by adding a pairing, a scale, line height and a readable measure.


Pair a heading and body font, set a type scale and make paragraphs comfortable to read.

Typography basics

Beginning Graphic Design: Typography

10 Tips for Pairing Fonts

## Why it matters

Colour sets the mood of a product, shows what is clickable, signals success and errors, and ties a brand together. It is also one of the easiest places to exclude people. Around 1 in 12 men and 1 in 200 women have some form of colour vision deficiency, many more people have low vision, and everyone uses screens in bright sunlight sometimes. A palette that only works for perfect eyes on a perfect monitor is a broken palette.

## A little colour theory

Colours on screens are usually described by **hue** (the colour family: red, blue, green), **saturation** (how vivid or grey it is) and **lightness** (how close to black or white). Tools such as HSL make these easy to adjust.

The colour wheel gives classic relationships:

- **Complementary**: opposite hues (blue and orange). High energy; use one as an accent.
- **Analogous**: neighbouring hues (blue, teal, green). Calm and harmonious.
- **Monochromatic**: one hue at different lightness levels. Simple and safe for interfaces.

For product design, theory matters less than **roles**. Most interfaces need:

- **Neutrals**: background, surface, borders, text and muted text (mostly greys, sometimes tinted).
- **Primary (brand/accent)**: buttons, links, selected states. Use it sparingly so it keeps its meaning.
- **Semantic colours**: success (green), warning (amber), error (red), information (blue).

A common guideline is roughly 60% neutral background, 30% secondary surfaces and text, and 10% accent. Each role gets a few shades, for example a light tint for backgrounds and a dark shade for text on that tint.

## Contrast: the numbers that matter

The Web Content Accessibility Guidelines (WCAG) define a **contrast ratio** between two colours, from 1:1 (identical) to 21:1 (black on white). It is calculated from the **relative luminance** of each colour: `(lighter + 0.05) / (darker + 0.05)`. At level AA, the level most organisations aim for:

- **Normal text**: at least **4.5:1** against its background.
- **Large text** (about 24px, or about 18.5px bold, and up): at least **3:1**.
- **User interface components and meaningful graphics** (button edges, input borders, icons, chart lines): at least **3:1** against what is next to them.

Read the official definitions on the W3C site (w3.org/WAI/WCAG22/Understanding), because rules get updated. Checked on 2026-10-23.

## A worked example

A design uses light grey `#9CA3AF` text on white. Its contrast ratio is about 2.5:1, which fails for body text. Darkening it to `#4B5563` gives about 7.6:1, which passes comfortably and still looks soft.

A yellow `#FCD34D` button with white text fails twice: white on yellow is about 1.5:1 for the label, and yellow against a white page is also about 1.5:1, so the button barely stands out. Options: keep the yellow fill but use near-black text (which passes for the label), and give the button a darker border so it reaches 3:1 against the page; or switch to a darker fill such as `#1D4ED8` with white text, which passes both.

You do not need to calculate these by hand. Use a free checker such as the WebAIM Contrast Checker, the contrast panel in browser developer tools, or a Figma contrast plugin.

## Do not rely on colour alone

WCAG also says colour must not be the **only** way information is shown. An error field that only turns red is invisible to someone who cannot see red. Add an icon and a text message. A chart line that differs only by colour needs labels or different line styles.

## Tokens make palettes maintainable

Name colours by role, not by appearance: `--color-text`, `--color-muted`, `--color-primary`, `--color-on-primary` (text placed on primary). If the brand colour changes, you update one token and every component follows. Dark mode becomes a second set of values for the same tokens, each checked for contrast again.

```css
:root {
  --color-bg: #ffffff;
  --color-text: #1f2937;
  --color-primary: #1d4ed8;
  --color-on-primary: #ffffff;
}
```

## Common mistakes

- **Light grey text** for "subtle" captions that fails 4.5:1.
- **Brand colours used for text** without checking them.
- **Placeholder text as the only label**: it is usually low contrast and disappears when typing.
- **Checking only the default state**: hover, disabled-looking and focus states need checking too (focus indicators need 3:1).

## Quick recap

- Give colours roles: neutrals, one primary accent, semantic colours.
- AA contrast: 4.5:1 for normal text, 3:1 for large text and UI components.
- Never use colour as the only signal; add text or icons.
- Store colours as role-named tokens so palettes stay consistent.

## Try it

Open the **Do** tab. You will repair a palette whose text, caption and button all fail contrast, by changing only the token values.


Build a small colour palette with roles and check that text and controls meet WCAG contrast ratios.

Colour theory and contrast

Beginning Graphic Design: Color

How to test for Color Contrast | TPGI & WebAIM | WCAG

Screenshot the screen. Circle every icon and image.

For each icon, write what you think it means without reading any label. Mark the ones you were unsure about.

Check consistency: note any differences in size, stroke weight, outlined vs filled, or corner style.

Pick one free icon set, read its licence, and choose a replacement for every icon from that set only.

Add a short text label to every icon that is not universally understood, and mark the selected state (for example, filled).

For each image, write which job it does: shows the real thing, explains, or sets the mood. Mark any that do none of these.

Write alt text for each meaningful image in one sentence, and mark decorative ones as alt="".

Sketch or build the improved version and compare it with the original.

## Why it matters

Icons and images are the fastest-reading parts of a screen. A good icon helps people scan a toolbar in a glance; a good photo can explain a product better than a paragraph. But mismatched icons make a product look assembled from spare parts, mystery icons slow people down, and stock photos that say nothing waste the most valuable space on the page.

## Icons: recognition first

Very few icons are understood by almost everyone without a label: a magnifying glass for search, a house for home, a printer for print, a cross for close, a gear for settings is close. Most others, such as a cloud, a star, a heart, a lightning bolt or three dots, mean different things in different products.

So the main rule is: **icons should support words, not replace them**. A navigation bar with icon plus label is understood by more people than one with icons alone, especially for new users. If space forces icon-only buttons, use only well-known icons, add an accessible name (for example `aria-label="Search"`), and show a tooltip on hover or focus.

## Icons: consistency

Use **one icon set** throughout a product. Sets such as Material Symbols, Lucide, Phosphor and Heroicons are free, but each has its own licence, so read it before you use the set. Within a set, icons share:

- **A grid and size**, usually 24 by 24 with a small padding area, displayed at 16, 20 or 24px.
- **A stroke weight**, such as 1.5 or 2px, and line caps and corners (round or square).
- **A style**: outlined or filled. A common pattern is outlined for normal state and filled for the selected tab.

Mixing a thin outlined icon with a heavy filled one in the same toolbar is the most common beginner mistake. If you must draw a missing icon, copy the set's grid, stroke and corner radius exactly.

Size icons to match the text next to them: a 20px icon pairs with 16px text, and they should be vertically centred. Icon-only tap targets still need about 44 to 48px of tappable area even if the icon itself is 24px.

## Images: does it earn its place?

Before adding any image, ask what job it does:

- **Shows the real thing**: a product photo, a screenshot of the app, the actual team.
- **Explains**: a diagram, a chart, a step-by-step illustration.
- **Sets the mood**: a hero illustration for a landing page. This is the weakest reason, and it should not push the content too far down.

Generic stock photos (people in suits shaking hands, smiling at laptops) are often ignored by readers. Real, specific images do better.

## Images: practical rules

- **Licences.** Free libraries such as Unsplash and Pexels have their own licences; read them. Never take images from a search engine and assume you can use them.
- **Consistent treatment.** Use the same aspect ratios (for example 16:9 for cards, 1:1 for avatars), similar lighting and colour, and the same corner radius.
- **Cropping.** Crop to the subject. Make sure the important part survives on small screens.
- **Text on images.** Text over a photo often fails contrast. Add a dark overlay or a solid panel behind the text, and check the ratio.
- **File size.** Export at the size it will be displayed (with a 2x version for sharp screens) and use modern formats such as WebP or AVIF, or the platform default, to keep pages fast.

## Alt text

Every meaningful image needs **alternative text** for people who use screen readers and for when images fail to load. Describe what the image communicates in context, in a short sentence: "Bar chart: sign-ups doubled from March to June." Not "image of chart". Decorative images that add nothing get empty alt text (`alt=""`) so screen readers skip them. Icons inside buttons with visible labels are usually decorative; icon-only buttons need an accessible name.

## A worked example

A course app's bottom navigation has five icons: a house, an open book, a speech bubble, a bell and a person. Some are filled, some outlined, sizes vary from 20 to 28px, and there are no labels. Fix:

1. Choose one set (say, an outlined set at 24px with a 2px stroke).
2. Replace all five icons from that set; use the filled variant only for the selected tab.
3. Add short labels under each: Home, Courses, Forum, Alerts, Profile.
4. Make each tab at least 48px tall.

## Common mistakes

- Mixing icon sets, styles or stroke weights.
- Icon-only controls with no label or accessible name.
- Images chosen for decoration that push content below the fold.
- Text over busy photos with no overlay.

## Quick recap

- Pair icons with labels; use icon-only buttons only for universally known icons, with an accessible name.
- Use one icon set with one grid, stroke and style.
- Every image should show, explain or (sparingly) set the mood; treat images consistently and check licences.
- Write alt text that says what the image communicates; use `alt=""` for decoration.

## Try it

Open the **Do** tab and audit and rebuild the icons and images of a real screen.


Choose a consistent icon set, pair icons with labels, and pick and describe images that support the content.

Icons and imagery

Tips for Icon Usability

Decorative Images: Delightful or Dreadful?

Choose and size type, build a colour palette that passes contrast checks, and use icons and images consistently.

Typography and Colour

Sign up for a free Figma account (or Penpot) and create a new Design file called "Design fundamentals practice".

Press F and create a phone-sized frame. Name it "Home".

Build the button from the reading: text, Shift + A, padding 12/24, a fill, radius 12, width and height set to Hug.

Change the button text to a longer phrase and confirm the button resizes by itself.

Build a vertical auto layout card with 16px padding and 16px gap: image placeholder (Fill width), title, paragraph and your button.

Set the card to a fixed width that leaves 16px on each side of the frame and Hug height. Add text to the paragraph and watch the card grow.

Add a horizontal auto layout row with two buttons and an 8px gap.

Rename every layer meaningfully, then share a view link with a friend or classmate.

## Why it matters

Figma is the most widely used interface design tool in product teams today. It runs in the browser (with optional desktop apps), files live in the cloud, and many people can work in the same file at once, including developers who inspect measurements and copy CSS. Knowing the basics lets you turn sketches into clean, shareable screens and join a design team's workflow. The ideas in this lesson (frames, constraints, auto layout) also exist in other tools such as Penpot, a free open-source alternative.

## Getting set up

Figma has a free plan, which is enough for learning; it limits some features and the number of files you can keep in team projects. Plans and limits change, so check figma.com/pricing for the current details. Students and teachers can apply for a free education plan. Checked on 2026-10-23.

Create an account, then create a new **Design file** from the file browser. The screen has three main areas:

- **Left panel**: layers (everything in the file, as a tree) and pages.
- **Canvas**: the infinite workspace in the middle.
- **Right panel**: properties of whatever is selected (size, position, fill, text, layout), plus Prototype and the developer-facing view.

Useful shortcuts (Mac uses Cmd where Windows uses Ctrl): **F** or **A** frame, **R** rectangle, **T** text, **V** move, **Space + drag** pan, **Cmd/Ctrl + scroll** or **Z** zoom, **Shift + 1** zoom to fit everything.

## Frames: your screens and containers

A **frame** is a container, like an artboard. Press **F** and pick a preset from the right panel (for example a phone size) to create a screen. Frames can hold other frames, so a card inside a screen is also a frame. Unlike a plain group, a frame can have its own fill, corner radius, padding, layout grid and clipping.

Name your layers as you go ("Card / Profile", "Button / Primary"). Developers and future you will read these names.

## Auto layout: frames that arrange themselves

**Auto layout** turns a frame into a flexible container, similar to CSS flexbox. Select a frame or some layers and press **Shift + A**. You can then set:

- **Direction**: horizontal (a row) or vertical (a column), or wrap.
- **Gap**: the space between children (use your 8-point scale).
- **Padding**: space inside the frame's edges.
- **Alignment**: where children sit (top-left, centre, and so on).
- **Resizing**: each layer can be **Fixed** (a set size), **Hug** contents (grow to fit what is inside) or **Fill** container (stretch to the available space).

## A worked example: a button

1. Press **T** and type "Save changes". Set 16px text, semi-bold.
2. With the text selected, press **Shift + A**. Figma wraps it in an auto layout frame.
3. Set padding to 12 top and bottom, 24 left and right. Add a fill colour and a corner radius of 12.
4. Set the frame's width and height to **Hug**.
5. Now edit the text to "Save". The button shrinks to fit. Change it to "Save and continue" and it grows. That is the point of auto layout: no manual resizing.

## A worked example: a card

1. Create a vertical auto layout frame with 16px padding and a 16px gap.
2. Inside it, add an image placeholder (a rectangle set to **Fill** width), a title, a short paragraph and your button.
3. Set the card to a fixed width (for example 328, which fits a 360 phone with 16px margins) and **Hug** height.
4. Add a line to the paragraph. The card grows taller by itself and everything below moves down.
5. Nest a horizontal auto layout for two buttons side by side with an 8px gap.

Mapping to code helps here: the card is roughly `display: flex; flex-direction: column; gap: 16px; padding: 16px;`, and Hug is like `width: fit-content`.

## Sharing and handoff

Use **Share** to invite people as viewers or editors, or copy a link. Comments (press **C**) let people pin feedback to exact spots. Developers can inspect sizes, colours and spacing.

## Common mistakes

- **Using groups instead of frames.** Groups cannot have padding or auto layout.
- **Placing everything by hand.** If you nudge items pixel by pixel, wrap them in auto layout instead.
- **Unnamed layers** ("Frame 427", "Rectangle 12"). Rename as you go.
- **Off-scale values** like a 13px gap. Keep to 4, 8, 16, 24, 32.

## Quick recap

- Figma files hold frames (screens and containers) on an infinite canvas.
- Auto layout (Shift + A) arranges children with direction, gap, padding and alignment.
- Hug, Fill and Fixed decide how layers resize.
- Name layers and share links for feedback.

## Try it

Open the **Do** tab and build a phone screen with an auto layout button and card in a free Figma file.


Set up a free Figma file, create frames and build a button and a card with auto layout.

Getting started in Figma

Figma Tutorial for Beginners (13-min crash course!)

Figma in 5:  Auto Layout

Create a page called "Components" and move your auto layout button there.

Create colour styles (or variables) named by role: Color/Text/Default, Color/Primary/Default and Color/On-primary. Apply them to the button.

Create two text styles: Text/Body/Regular and Text/Label/Button. Apply the label style to the button text.

Turn the button into a component (Create component).

Add variants for Type (Primary, Secondary) and State (Default, Disabled). Make Secondary an outlined button.

Back on your screen, replace the hand-made buttons with instances and override their label text.

Change Color/Primary/Default to a different colour and the corner radius of the main component. Check that every instance updated.

Check the disabled variant still has readable text, and note the contrast ratio you measured.

## Why it matters

Real products have hundreds of screens, and they reuse the same pieces again and again: buttons, inputs, cards, navigation bars. If each copy is drawn separately, a small change (a new corner radius, a darker brand colour) means editing every screen by hand, and copies drift apart. **Components** and **styles** solve this. Change the source once and every use updates. They are also the bridge to code: developers build the same pieces as reusable components in React, SwiftUI or a game engine's UI system.

## Components and instances

A **component** is a reusable design element. In Figma, select a layer (for example the button you built with auto layout) and choose **Create component** (Cmd/Ctrl + Alt + K, or Option on Mac). The original becomes the **main component**, marked with a four-diamond icon.

Copies you place are **instances**. Instances stay linked to the main component:

- Change the main component's fill or radius, and every instance updates.
- In an instance you can **override** some properties, such as the label text or an icon, without breaking the link.
- If you need a one-off change that the component does not support, you can detach the instance, but then it no longer updates. Detaching should be rare.

Keep main components together on a separate page (for example "Components") so they are easy to find and are not accidentally edited inside a screen.

## Variants and properties

Most components come in versions: a button can be primary or secondary, small or large, default, hover or disabled. Instead of separate components for each, Figma lets you combine them into one **component set** with **variants**. Each variant has property values, for example `Type=Primary, Size=Large, State=Default`. When you use an instance, you pick values from dropdowns in the right panel.

Components can also expose simpler **properties**: a text property for the label, a boolean to show or hide an icon, and an instance swap to choose which icon. This keeps the number of variants small.

A worked example, a button set:

```text
Type:  Primary | Secondary
Size:  Medium  | Small
State: Default | Hover | Disabled
Label: text property
Icon:  boolean (show/hide) + instance swap
```

That is 2 x 2 x 3 = 12 variants, but one component for people to learn.

## Styles and variables

**Styles** store reusable visual values: colour styles (fills), text styles (font, size, weight, line height), effect styles (shadows) and layout grid styles. **Variables** store single values such as a colour, number or string, and can hold different values per **mode**, which is how teams set up light and dark themes. Use whichever your team uses; the principle is the same as the design tokens from the colour lesson.

Name them by role, using slashes to create folders:

```text
Color/Text/Default      #1F2937
Color/Text/Muted        #4B5563
Color/Primary/Default   #1D4ED8
Color/On-primary        #FFFFFF
Text/Heading/H1         Georgia 31/38 Bold
Text/Body/Regular       Inter 16/24 Regular
Spacing/2               16
```

Then apply styles everywhere instead of typing hex values. If the primary colour changes, you edit `Color/Primary/Default` once.

## How this maps to code

A design system usually has the same structure in design and in code:

- Design tokens (colour, type, spacing) match CSS custom properties or a theme file.
- A Figma component set matches a code component, for example `<Button variant="primary" size="small" disabled>`.
- Variant properties match component props.

When names agree in both places, handoff is much smoother. That is why designers and developers often agree on names together.

## Common mistakes

- **Making a component too early or too late.** Make one when something appears in two or more places and you expect it to stay the same.
- **Too many variants** for things that could be properties (one variant per label text, for example).
- **Detaching instances** to make small changes, which quietly breaks consistency.
- **Hard-coded colours** typed directly instead of styles or variables.
- **Names by appearance** such as "Blue 2", which stop making sense after a rebrand.

## Quick recap

- A main component is the source; instances are linked copies that allow overrides.
- Variants combine versions (type, size, state) into one component set; properties handle labels and icons.
- Styles and variables store colours, text and spacing by role; variables support modes such as dark theme.
- Matching names in design and code make handoff easier.

## Try it

Open the **Do** tab. You will turn your button into a component with variants, create styles, and see one change update a whole screen.


Turn repeated elements into components with variants, and store colours and text as reusable styles.

Components and styles

Components fundamentals: Figma Design for beginners [7 of 13]

Lesson 5: Styles and variables

Write a one-paragraph brief: the users, the goal, constraints, the stage of the design and two specific questions you want answered.

Choose a facilitator and a note-taker, or ask one person to do both.

Present the brief in five minutes or less, without defending the design.

Give everyone five minutes of silent review to write notes.

Discuss for 15 minutes, starting with your two questions. Ask reviewers to use observation, effect, goal and a "what if" question.

Listen and ask clarifying questions only. Do not argue any point during the session.

Summarise what you heard in one minute and group the notes into themes.

Pick the top two changes, make them, and send a short follow-up saying what you changed and why.

## Why it matters

Designers never work alone for long. Product managers, developers, other designers, and sometimes clients all look at the work and react. Unstructured reactions ("I don't love it", "make it pop") are frustrating and rarely improve anything. A **design critique** is a structured conversation that tests a design against its goals, so the work gets better and nobody's feelings get trampled. Being good at critique, both giving and receiving, is one of the clearest signs of a professional designer, and it matters just as much for developers and game designers who review each other's work.

## Critique is not approval and not taste

A critique is not a vote on whether people like the design, and it is not the moment a manager signs it off. It answers one question: **does this design achieve its goals for its users, and what would make it better?**

That means every critique needs the goals on the table first. "This button is too small" is an opinion. "The goal is that first-time users find Register in under five seconds, and this button is the same colour as the body text, so it might be missed" is useful feedback linked to a goal.

## Roles in a critique

- **Presenter** (the designer): explains the context, the goals, the constraints and what kind of feedback they want.
- **Reviewers**: give feedback tied to the goals.
- **Facilitator**: keeps time, keeps the discussion on goals, and makes sure everyone speaks. In a small group the presenter can facilitate.
- **Note-taker**: captures feedback so the presenter can listen instead of writing. It can be one of the reviewers.

## A simple format (30 minutes)

1. **Context (5 min).** The presenter states: who the users are, the problem, the goals or success measures, constraints (time, technology, brand), what stage this is (early sketch or nearly final), and the **specific questions** they want answered. Early sketches deserve big-picture feedback; near-final designs deserve detail.
2. **Silent review (5 min).** Reviewers look at the design and write notes privately. This stops the loudest person from setting the agenda.
3. **Discussion (15 min).** Reviewers share, one point at a time, starting with the presenter's questions.
4. **Wrap-up (5 min).** The presenter summarises what they heard and what they will do next. They do not have to accept every point.

## Giving good feedback

A useful pattern is **observation, effect, goal**:

```text
Observation: The price is in the same small grey text as the description.
Effect:      I had to search for it; I found the button before the price.
Goal link:   The brief says people should compare plans quickly.
Question:    What if the price were the largest element on each plan card?
```

Other tips:

- **Start with what works**, specifically. "The step numbers make the sign-up flow feel short" helps the designer know what to keep.
- **Describe problems, not solutions.** Offer ideas as questions ("What if...?"), because the designer may know constraints you do not.
- **Be specific.** Point at the exact element and say what happened when you looked at it.
- **Separate your taste from user needs.** If it is only a preference, say so.
- **Critique the work, not the person.** "This layout" not "you".

## Receiving feedback well

- **Listen first, then ask clarifying questions.** "Can you say more about where you got stuck?"
- **Do not defend every decision in the moment.** Note it, then decide later.
- **Look for patterns.** If three people mention the same area, take it seriously even if their suggested fixes differ.
- **Close the loop.** Afterwards, share what you changed and why you did not change other things.

## Remote and async critique

Teams spread across time zones often critique in comments. In Figma, reviewers can pin comments to exact spots. The same rules apply: the designer posts context and questions first; reviewers write observation, effect and goal; the designer replies and resolves comments when handled.

## Common mistakes

- No goals presented, so feedback becomes taste.
- Jumping straight to solutions ("make it blue").
- Pixel-level comments on a rough sketch, or big rethinks on a design shipping tomorrow.
- The designer arguing every point instead of listening.

## Quick recap

- Critique tests a design against its goals; it is not approval or a taste vote.
- The presenter gives context, stage and questions; reviewers review silently, then discuss.
- Feedback pattern: observation, effect, goal, then a question.
- Receive feedback by listening, looking for patterns and closing the loop.

## Try it

Open the **Do** tab and run a 30-minute critique of one of your designs from this course with two or three people.


Run a structured critique session and give and receive feedback tied to goals, not taste.

Design critique

UX Design Critiques: 3 Tips for Effective Feedback

How to Give Design Feedback

Build screens in Figma with frames and auto layout, reuse work with components and styles, and run a useful critique.

Visual Design Fundamentals

About this course

Course content

Design Principles

Typography and Colour

Design Tools

Where this course leads

Next course on the path

Careers that use it