Figma Web Design: How to Design a Website UI Step by Step

Figma web design means planning, drawing, testing and handing off every screen of a website inside one shared file before anyone writes production code. In this guide I walk through the order I follow on my own projects: brief, sitemap, wireframe, design system, responsive layouts with auto layout, prototype and developer handoff in Dev Mode.
This is not a feature tour. I use the exact terms from Figma's official help center, but the focus is on decisions: what to do first, what to skip and what each step should produce. So whether you design the site yourself or hire a designer, you will know where the project stands at any moment.
How does Figma web design work, step by step?
Figma web design follows seven steps: a brief that sets goals, a sitemap that lists pages and templates, a grayscale wireframe, a design system built with variables and components, responsive screens with auto layout, a clickable prototype, and a handoff through Dev Mode. In other words, each step produces the input for the next one.
Skipping ahead is tempting. For example, many teams start with a polished homepage, and then everything breaks once the real copy arrives. That is why I finish the first two steps outside Figma, in a plain document. When I finally open the canvas, I already know what I am drawing.
The sections below cover each step in order. For every step I explain which Figma feature I use, why I use it and what output moves the project forward. At the end, you will also find the whole process in one table.
Why write a brief before you open Figma?
A brief is a short document that states what the design must achieve. Without it, then, every hour in Figma turns into a debate about taste. After all, "does it look good?" has no measure. However, "did more visitors reach the quote form?" does.
I fill in the brief under these headings:
- The site's one sentence purpose and its main conversion action (quote, booking, purchase, call).
- The target audience, the first three questions they ask and the objections that stop them.
- Existing brand assets: logo, colors, typefaces and photo library.
- Three sites the client likes and three they dislike, each with a reason.
- Technical limits: the CMS, language versions and integrations.
Above all, do not rush the audience part. My guide to target audience analysis gives you the questions to ask. To define the conversion action, my article on website conversion goals helps. Also, I never start wireframes before the client signs off the brief. In my experience, this single rule cuts revision rounds more than any tool does.
How do you build a sitemap and a page inventory?
A sitemap is a tree that shows every page and how pages relate to each other. For design, however, its main job is to reveal how many templates you need. A fifteen page business site usually needs four or five: home, service detail, listing, article and contact.
I draw the sitemap in FigJam or on a separate page inside the Figma file. Then, next to each box, I note the target search phrase and the main action for that page. As a result, design and SEO planning meet at the same table from day one. To assign search phrases to pages, I use keyword mapping.
If you plan a large catalog or a site with many categories, hierarchy depth matters even more. In that case, apply the rules from my article on category structure for large websites before you design anything. Otherwise you will redraw menus and filters later.
I also list the special states of each template at this stage. An empty search result, an out of stock product and a form success screen each need their own design. If you list them early, nobody asks "what does this screen look like?" during development. In short, the sitemap works like a scope agreement, not just a menu plan.
The output of this step is two lists: pages and templates. The template list also sets the working order inside your Figma file.
What should a wireframe in Figma focus on?
A wireframe is a plain skeleton without color or decoration. In other words, it shows the order and priority of content blocks. At this stage I avoid talks about color, photos or fonts. Instead, I look for three answers: what should visitors see first, in what order should they become convinced, and where should the main button sit?
In practice, gray boxes, one typeface and simple frames are enough. Still, use copy that is close to the real text. A service page drawn with lorem ipsum almost always overflows when the real copy lands. So I ask the client for a rough draft or I write the headings myself.
I draw the wireframe at mobile width first. If a block does not fit a narrow screen, it probably adds little on desktop too. I explain this logic in detail in my article on mobile first design.
You can also link three or four wireframe screens with simple connections. That way the client understands the flow better. However, I add no animation here, because the only goal is to confirm the order of blocks.
I close this step with a short approval call. Once the block order is final, the visual design stage only covers appearance. As a result, the structure debate does not come back.
How should you organize a Figma file?
File structure decides how fast you can work in the second month of a project. Figma's own handoff advice points the same way: name pages clearly, give layers meaningful names and group related screens in sections.
My standard page structure looks like this:
- Cover: project name, status and last update note.
- Brief and sitemap: a short summary of approved decisions.
- Wireframes: mobile and desktop skeletons.
- Design system: color, type, spacing and components.
- Screens: one section per template, with breakpoints inside each section.
- Prototype: connected flows.
- Archive: rejected alternatives.
I never leave automatic names like "Frame 427". For example, I name a card "card/service" and a hero title "hero/title". Developers see these names in Dev Mode, so names close to CSS class names speed up communication. The archive page also matters. Moving old versions there instead of deleting them saves the day when the client asks to "bring back the first version".
Where does a design system start: color, type and spacing?
In Figma web design, a design system collects every repeated decision of an interface in one place. I build one even for a small business site, because it pays off quickly. Without it, every new page brings a new shade of gray and a new spacing value.
First, I define the color palette. I take the brand colors as primary colors and then create lighter and darker shades for each. After that, I assign roles: text, background, border and status colors for success, warning and error. You can compare color codes and test shades with my HTML color codes tool.
Next, for typography I set a scale: body text, small text and four or five heading levels. I keep body text at a readable size with generous line height. For spacing, I pick a series based on multiples of 4 or 8. As a result, padding and gap values follow a system instead of random numbers.
All of these decisions live on one "Design system" page. A new designer or developer should learn the rules of the project in ten minutes just by looking at it.
Variables or styles: which should you use and when?
Figma offers two ways to store design decisions, and one does not replace the other. According to Figma's page on the difference between variables and styles, styles hold a combination of values and apply them all at once. Variables, on the other hand, hold single values, and those values can change with context.
Variables come in four types: color, number, string and boolean. You group them in collections, and each collection can hold several modes, such as light and dark or mobile and desktop. When you switch a frame to dark mode, every layer bound to a variable shows its dark value.
| Need | Variables | Styles |
|---|---|---|
| Single color, theme switching | Good fit (color + modes) | Possible, but no modes |
| Spacing, corner radius, widths | Good fit (number) | Not available |
| Gradient fills | Not supported | Good fit |
| Full text style (font, size, line height) | Parts can bind | Good fit (text style) |
| Shadows and effects | Partly | Good fit (effect style) |
| Point one value to another (alias) | Good fit | Not available |
My rule of thumb: raw values become variables, while text and effect combinations become styles. As the same Figma page notes, variables cannot hold gradients, so gradients stay as styles.
How do you set up components and variants?
A component is a piece of interface you design once and reuse as instances everywhere. When you change the main component, Figma updates every instance. Buttons, form fields, cards, the menu and the footer always sit at the top of my component list.
A variant groups different states of the same component inside one component set. Figma's guide to variants explains this with properties and values. For instance, a button can have size, state and color properties, and the state property can hold values like default, hover, pressed and disabled.
Here is what I watch when I build variants:
- I never keep default property names like "Property 2". Instead, I use clear names such as "size" or "state".
- Also, I do not group different icons as variants. Figma also suggests variants for different sizes of the same icon only.
- I lay out variants in rows and columns, so a missing combination stands out at a glance.
- I add a short description to each component: when to use it and an accessibility note.
Buttons deserve extra care, because they do the selling. For copy, color and placement decisions, my article with CTA button examples is a useful reference.
How do you make responsive layouts with auto layout?
Auto layout is the Figma feature that arranges objects in a frame by rules and resizes the frame as content changes. In practice, it works much like CSS flexbox. Figma's guide to auto layout describes four flows: vertical, horizontal, wrap and grid.
Three resizing settings control responsive behavior. Hug contents keeps a frame at the smallest size around its children. Fill container stretches an object to take all available space in its parent. Finally, fixed keeps the size unchanged. On top of that, you can add minimum and maximum width and height.
In practice, I set it up like this. The page frame has a fixed width. The content wrapper uses fill container with a max width. Cards sit in a horizontal flow with wrap turned on. When I narrow the frame, the cards drop to the next line on their own. So I do not need to draw the same component twice for desktop and mobile.
I also bind padding and gap values to number variables. There is also an "ignore auto layout" option, formerly called absolute position. I only use it for badges or corner labels that must sit outside the flow. Use it too often and you break the responsive behavior yourself.
How do you choose breakpoints in Figma web design?
A breakpoint is a screen width where the layout changes. In Figma I create a separate frame for each breakpoint, but the components stay the same. Only the layout rules change, so the system stays intact. Three frames usually do the job: mobile, tablet and desktop.
Pick widths based on content rather than a device list. For example, the width where a three column card grid starts to feel cramped is a natural breakpoint. Then I compare it with the values in the developer's CSS framework and align them if needed.
Variable modes also help a lot here. If you define "mobile" and "desktop" modes for spacing and font size values, switching the frame's mode updates all of them in one move. Instead of fixing heading sizes by hand on every screen, you manage them through the system.
At every breakpoint I check the same things. What happens to the menu? Does the table overflow? Do form fields switch to full width? Are the buttons large enough for a thumb? I cover the mobile side in more depth in my mobile first design guide.
How do you move from the homepage to inner pages?
Once the system is ready, I move to visual design. The order never changes: first the template with the most traffic and the most components, then the rest. On most projects that means the homepage or the main service page.
If a new component appears while I finish the first template, I move it to the design system page right away. In short, I do not collect "one off" pieces inside screens. Otherwise, copying the same piece from a screen for the second template creates inconsistency.
I also pay attention to photography at this stage. Real photos of the client's team, product or facility build more trust than stock images. So I set photo placement and ratios in Figma and then prepare a shot list from them.
Forms, however, need separate care. The number of fields in a quote or booking form, where error messages appear and what the success screen says all affect how many leads the site brings in. Here I follow the rules from my article on lead form design. After each template, I present it to the client with a short video walkthrough. Written feedback also comes back much clearer that way.
Which accessibility checks belong in the design file?
Checking accessibility while you build components costs far less than fixing it after launch. For the web, specifically, the shared standard is WCAG. The WCAG 2.2 contrast criterion requires at least 4.5:1 for normal text and 3:1 for large text.
WCAG 2.2 also added a target size criterion (2.5.8). It asks for touch targets of at least 24 by 24 CSS pixels or enough spacing around them. I design buttons and icon links larger than that, especially in the mobile menu.
My accessibility checks inside Figma:
- I measure the contrast of every text and background pair when I define color roles.
- I draw hover, focus and disabled states as variants. Above all, keyboard focus must stay visible.
- I show error messages with text and an icon, not with red color alone.
- I write the heading level into layer names, so the developer picks the right tag.
These checks also support SEO. Readable text and a clear heading structure help both people and search engines. I discuss that balance in my article on balancing UX and SEO.
How do you connect a prototype, and what should it show?
A prototype turns static screens into a clickable flow. In Figma you add an interaction to an object from the Prototype tab. Every interaction then has a trigger and an action.
According to Figma's page on prototype triggers, the common ones are On click (On tap on mobile), While hovering, Mouse enter, Mouse leave and After delay. For After delay you set the duration in milliseconds. There is one important limit: On click and While hovering do not work together on the same object. Instead, you use Mouse enter and Mouse leave.
For actions, I mostly use Navigate to for moving between frames. I also use overlays for pop ups and links to external URLs. Smart animate matches layers with the same name across frames and smooths the transition. That is another reason to keep layer names consistent in Figma web design.
Still, I do not try to connect everything. A prototype should show only the critical flows: from home to a service, from the service to the form, and from the form to the thank you screen. Those three or four flows are more than enough for testing.
Who should test the prototype, and how?
Testing shows how the design works for real users. Nielsen Norman Group has long argued that small, repeated tests with a few users find more problems than one large test. So I work with a handful of people per round and repeat rounds as needed.
First, I pick participants close to the target audience. The client's own staff or my designer friends make poor testers, because they already know the screens. I give each participant a task, such as "request a quote from this company". Then I watch without guiding them.
I note three things:
- Where did the participant pause or go back?
- Which text did they skip, and which did they read twice?
- Did they finish the task, and in how many clicks?
For remote tests, the Figma prototype link is enough. The participant opens it in a browser while I watch through screen sharing. Afterwards I rank the findings and feed them back into the design system or the relevant template. My most common change after a test? Simpler button copy and fewer form fields.
What does Dev Mode give developers at handoff?
Dev Mode is Figma's inspection interface for developers. According to Figma's guide to Dev Mode, it is available on all paid plans and needs a Full seat or a Dev seat. There, developers see measurements, colors, variable names and generated code.
These features help most at handoff:
- Ready for dev status. You mark a frame, component, instance or section as ready, so developers do not have to guess what is finished.
- Annotations. You add measurements, behavior notes and special callouts right on the design.
- Code view. It shows generated code for CSS, iOS and Android, with a choice of language and units.
- Compare changes. It shows how a screen differs from an earlier version.
- Figma for VS Code. Developers inspect the file without leaving their editor.
Code Connect lets a team show real component code in Dev Mode. According to Figma, it is available on Organization and Enterprise plans. That said, I rarely need it for small projects. Also, do not paste the generated CSS as is. That code is a starting point, not production code.
Which formats should you use to export images and icons?
Figma exports PNG, JPG, SVG and PDF. Dev Mode can also detect icons and list them as downloadable assets. Still, as the designer I decide which asset leaves in which format.
My general rule: icons and logos in SVG, photos as JPG or as a high quality source that the developer converts to WebP, and images with transparency in PNG. I add export settings to each asset in the design file. That way the developer does not have to ask one by one.
Image weight also affects page speed directly. A hero image exported at 2x from Figma can weigh several megabytes. Before launch, you can compress images with my image resizer. I explain how speed affects rankings and sales in my article on site speed and SEO.
Finally, I add the favicon and the social sharing image to the export list. On most projects these small assets wait until the last day and end up rushed. Preparing them together with the design system keeps the brand consistent.
What process mistakes slow down Figma web design?
This section does not cover usability mistakes in the interface itself. I wrote about those in a separate article on UX mistakes that cost sales. Here I list process mistakes, because they tend to stretch a project by weeks.
- Starting visual design without a brief and debating structure over colorful screens.
- Drawing screens without components. Ten pages later the same button exists in seven versions.
- Skipping auto layout. Every text change then means fixing screens by hand.
- Designing desktop only and leaving the mobile layout to the developer.
- Leaving layers unnamed. A developer who sees "Group 12" in Dev Mode has to guess.
- Forgetting states like hover, focus, error and empty.
- Sending the prototype for approval without testing it.
In practice, each item on this list comes from a skipped step in the earlier sections. Therefore the fix is not a new tool; it is sticking to the order. On my own projects I review this checklist at the end of every stage. If anything is missing, I do not move on.
Process summary: which stage produces which output?
The table below sums up the steps with their outputs and approval points. You can use it as a checklist when you plan your own project.
| Stage | Figma feature | Output | Approved by |
|---|---|---|---|
| Brief | Document or FigJam | Goals, audience, conversion action | Client |
| Sitemap | FigJam or separate page | Page and template lists | Client + SEO |
| Wireframe | Frames, simple boxes | Block order | Client |
| Design system | Variables, styles, components, variants | Color, type, spacing, components | Designer + developer |
| Responsive screens | Auto layout, modes | Mobile, tablet, desktop templates | Client |
| Prototype and test | Prototype, Smart animate | Test findings | Designer |
| Handoff | Dev Mode, annotations, export | Ready for dev screens, assets | Developer |
Timelines depend on scope. As a starting range from my field experience, not a guarantee: for a business site with five templates, the brief and sitemap take a few days, while the design system and screens take a few weeks. Then plan testing and handoff on top of that.
When should you hire help for Figma web design?
Figma itself is not hard to learn, and Figma web design basics come quickly. You can start on the free plan and grasp the basics in a few days. The hard part is not the tool but the decisions: which block comes first, what each button says, which component joins the system. Those decisions take experience, so be honest about yours.
You can handle it yourself for a one page promo site, a small tweak to an existing template or a quick internal prototype. On the other hand, I recommend professional help for a business site that must bring in sales, a multilingual setup, e-commerce flows and projects with more than one developer.
In my web design service I follow exactly the order in this article, and I hand over the Figma file at the end of the project. If you want to explore the conversion side of design, my article on conversion focused web design is a good next step. To talk about your project, reach me through the contact page.




