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

Visual Design Fundamentals

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.