A website is a content system before it is a screen

Figma is useful for exploring hierarchy, interaction, and visual language. It cannot decide what pages the site needs or what each page must explain. Those decisions belong to the website plan: the structure that connects audience needs, business goals, content, navigation, and conversion paths.

Starting with screens often produces a polished homepage followed by a difficult question: what happens next? Starting with a plan makes the homepage one part of a coherent route through the site.

Figma is useful for exploring interface decisions, but it cannot solve an undefined website. Before designing screens, the team needs to understand audiences, tasks, content, page responsibilities, and the relationships between sections. Without that foundation, visual design becomes a way of postponing structural decisions. The result may look complete while important journeys remain missing.

A website plan does not need to be a large strategy document. It should be detailed enough to answer what pages exist, why each page exists, what content belongs there, how people reach it, and what action follows. This foundation also improves estimates, stakeholder review, CMS setup, SEO, and development handoff.

Define the audience tasks

List the reasons people will arrive. A prospective client may want to understand services and process. A collector may want to view available artworks, inspect details, and ask a question. A returning customer may need a policy, order information, or a direct path to a product. These tasks reveal the pages and calls to action the site needs.

Create an inventory. List every current page, file, form, campaign, and recurring content type. Mark what should be kept, rewritten, merged, redirected, archived, or removed. An inventory prevents important content from disappearing during redesign and reveals duplication before it enters the new structure.

Map audience tasks. For each primary audience, write the questions they need answered and the actions they need to complete. Then connect those tasks to pages. This produces a sitemap based on behavior rather than internal departments or organizational history.

Create a sitemap with page jobs

A sitemap is more than a list of links. Each page should have a defined job, primary audience, key information, and intended next action. This prevents duplicate pages and helps teams identify gaps before design begins.

• Homepage: establish the offer and route visitors to the right path.

• Service or collection pages: explain the offer and give enough depth for a decision.

• Individual detail pages: provide the specific information a visitor needs before acting.

• About page: establish perspective, credibility, and context.

• Contact or conversion pages: reduce friction at the point of inquiry or purchase.

Assign a job to every page. A page should inform, compare, persuade, collect information, support a transaction, or connect visitors to another step. If a page has no clear job, it may belong inside another page or should be removed. Page jobs also help determine headings, proof, calls to action, and metadata.

Design navigation language. Use labels visitors can predict. Test the primary menu, footer, breadcrumbs, contextual links, and mobile navigation together. A sitemap can be logically correct while the navigation remains confusing if labels are vague or routes are hidden.

Write navigation from the visitor's point of view

Use labels people can understand without knowing the business internally. Limit top-level choices to the destinations that matter most. A navigation menu should reveal the site structure, not reproduce an organizational chart.

Starting with a homepage moodboard. The homepage cannot carry the entire site. Beginning with its visual style often delays decisions about deeper pages, forms, filters, and content relationships.

A common mistake is ignoring redirect planning. When URLs change, old pages need clear destinations. Redirect decisions should be made before launch, not after analytics and search traffic begin failing.

Bring the plan into design

Once the sitemap and page jobs are clear, Figma can test what matters: hierarchy, responsive behavior, component patterns, and the sequence of tasks. The design will move faster because it has a structure to support.

Plan the website as a content and navigation system before treating it as a collection of screens. A clear sitemap, page inventory, task map, and content outline give Figma something real to solve. The design phase then becomes faster because the team is making interface decisions, not repeatedly rediscovering the structure.

A practical way to carry the article forward is to create an inventory, map audience tasks, assign a job to every page, and design navigation language. The evidence should appear in the content inventory, sitemap, interface states, responsive behavior, accessibility checks, and complete user journeys.

Write the content outline before choosing components

For every core page, write a rough outline in plain text. Start with the page question, then list the evidence, examples, details, and action the visitor needs. This does not need to be final copy. It is a way to prove that the page can carry its job before the design begins.

A content outline also makes design handoff cleaner. Designers can create hierarchy around real information instead of filler. Developers can see which patterns repeat. Stakeholders can resolve missing details early, when the cost of change is low. The website plan becomes a shared reference rather than a private design file.

Before finalizing the decision, check for two risks: starting with a homepage moodboard and ignoring redirect planning. A final review should test the experience with real content, small screens, keyboard navigation, slow connections, and the exact actions visitors need to complete.

Continue reading Explore QART.Studio and Website Content Audits: What to Fix Before a Redesign.