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.
A practical sitemap can begin as a list of questions rather than a diagram. For a services website: What does the business do? Who is each service for? Can visitors see relevant work? What happens after an inquiry? These map naturally to Services, Projects, About, and Contact, with individual service pages when the offerings need their own explanations. Before drawing a homepage, write one sentence describing the job of each page and one action its visitor should be able to take. If two pages promise exactly the same thing, reconsider the split.
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.
Try writing a page brief for a single service before opening Figma. Give it a visitor question, one clear answer, evidence that supports the answer, a next action, and a destination for people who need more detail. If any of those pieces is missing, the layout will not fix the information problem. Once several page briefs exist, navigation labels become easier to test: each label should predict the answer a visitor will find behind it.
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.
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.
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.
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.