If the first thing your website project produces is a Figma file, you may be starting too early.
Before wireframes and UI, there are a number of decisions that need to be made about the business, the audience, the positioning, the content, the structure, and the user experience.
These decisions may not look as exciting as a new visual direction.
But they determine what that visual direction needs to communicate.
The most important decisions in a website project often happen before design starts.
A strong B2B website isn't designed from the screen up. It is built from a clear understanding of what the business needs to achieve, who the website needs to serve, and how users should move through the experience.
So what should happen before the first wireframe?
A website should have a business purpose.
Before thinking about layouts or components, define what the website needs to help the business achieve.
For a B2B company, that could mean:
Different goals lead to different website decisions.
A company entering a new market may need to communicate its positioning differently to a new audience.
A company trying to improve conversion may need to rethink its user journeys and calls to action.
A business selling a complex service may need a completely different content structure from a company with a simple product.
Without a clear goal, design decisions can become subjective.
The conversation becomes:
"Do we like this layout?"
Instead of:
"Does this help the business achieve what the website is supposed to do?"
That's an important difference.
Knowing your ideal customer profile is useful.
But for a B2B website, it's often not enough.
B2B buying decisions can involve several stakeholders, and each one may arrive with a different question.
A CEO may want to understand business value and risk.
A CMO may care about positioning, differentiation, proof, and conversion.
A Product or Digital Director may need to understand capabilities, integrations, implementation, or technical requirements.
And the person actually evaluating the solution may simply want to know:
Is this relevant to my problem?
Before design starts, you need to understand:
This turns "we're designing for our target audience" into something much more concrete.
Once you understand the business and its audience, you need to know what the website should communicate.
Before designing the homepage, you should be able to answer:
Who are we?
Who are we for?
What problem do we solve?
Why should our audience choose us?
What makes us different?
What should someone understand within the first few seconds of visiting the website?
These questions shape everything that comes later.
If the positioning is unclear, the design team is forced to solve a strategy problem visually.
And visual design can't fix unclear positioning.
A sophisticated interface won't make a vague value proposition more relevant.
A beautiful homepage won't compensate for a company that hasn't decided what it wants to be known for.
Before designing the experience, decide what the experience needs to communicate.
Content shouldn't be written after the design is finished.
It is part of the design process.
That doesn't necessarily mean every sentence needs to be polished before a designer opens Figma.
It means the team should understand what each page needs to communicate.
Before design, define things such as:
This matters because real content has structure.
A headline may need supporting context.
A complex service may require a process explanation.
A product may need technical details, use cases, proof, and FAQs.
A CTA may only make sense after the visitor has understood the value proposition.
If designers work with empty boxes and placeholder text for too long, the final interface can end up being designed around assumptions rather than the actual content.
Content gives design something meaningful to solve.
Once you know what needs to be communicated, you need to decide how the information is organised.
This is where information architecture comes in.
The key question is:
What information does the user need — and where should they find it?
The structure should be based on audience needs and user intent, not simply on the company's internal organization.
A useful way to think about it is:
Audience → Intent → Information → Page → Action
This can influence:
For example, if a company offers several related services, simply putting all of them under a generic "Services" menu may not be enough.
Users may think about their problem differently from the way the company categorises its services.
The website structure needs to bridge that gap.
A strong information architecture makes the experience easier to understand before visual design even begins.
Information architecture answers: Where does the information live?
UX asks: How does the user move through it?
Before wireframes, identify the key journeys people need to take through the website.
A typical B2B journey might look like:
Problem → Solution → Value → Proof → Process → Action
But not every visitor starts at the same point.
Someone may arrive from a search result looking for a specific service.
Someone else may come through a campaign landing page.
Another visitor may already know the company and be looking for proof before contacting sales.
The UX needs to account for these different entry points and intentions.
Before design starts, think through:
This is where many website projects become more strategic.
Instead of designing individual pages, you're designing how the pages work together.
Once the business goals, audience, positioning, content, structure, and UX are clear, design has something solid to build on.
Wireframes can answer questions about layout, hierarchy, and interaction.
UI can then translate the strategy into a visual system.
At this point, design isn't being asked to discover what the business means.
It's being asked to communicate it clearly.
That distinction matters.
The sequence becomes:
The process is not completely linear. New insights during UX or wireframing can lead to changes in content or structure.
But the important thing is that those decisions are made before the project becomes heavily invested in visual design.
That makes iteration easier and prevents expensive changes later.
Before design starts, your team should be able to answer:
What business problem are we solving?
Who are we designing for?
What does each key audence need to know?
What should the website communicate about the business?
What makes the company different?
What content does each page need?
How is the information structured?
What journeys should users take?
What actions should users be able to take?
If several of these questions don't have clear answers, the project probably isn't ready for UI design.
And that's not a problem.
It's a signal that there is still important strategic work to do.
A website redesign or new website project often creates pressure to show something quickly.
A homepage concept feels tangible.
A new visual direction feels like progress.
A Figma file gives everyone something to react to.
But speed at the beginning doesn't necessarily mean speed overall.
If positioning changes after UI is approved, the design needs to change.
If the content structure changes after development starts, templates may need to change.
If user journeys weren't considered early enough, conversion problems may only become visible after launch.
The work done before design reduces that uncertainty.
The goal isn't to delay design. It's to make design more effective.
That's why the strongest website projects don't begin with screens.
They begin with decisions.
At Octo, we approach website projects by connecting business goals, strategy, content, UX, design, and technology from the beginning.
Our Launch approach is designed to turn that early thinking into a clear digital experience and a scalable website — rather than treating strategy as something separate from execution.
If you're planning a new B2B website or redesign, start by defining what the business needs the website to achieve.
Discuss your website project with Octo