Website Design: Designing With Every User in Mind

Laptop on a table Laptop on a table

Website Design: Designing With Every User in Mind

Design decisions can become subjective very quickly.

Everyone has colors they like, websites they prefer, or opinions about how something should look. Those perspectives are useful, particularly when we're learning about an organization's brand. But personal preference can't be the only measure of whether a design works.

Our designers continually bring the conversation back to the people who will actually use the website.

And that means more than just the customers of the organizations we work with.

Depending on the organization, website users might include prospective customers researching a service, existing customers logging into an account, job candidates exploring careers, salespeople sharing resources with prospects, marketers building landing pages, or administrators managing content behind the scenes.

Each interacts with the website differently, and each may have different goals.

During Research and Plan, we work to understand those audiences, their needs, and the jobs the website needs to help them accomplish. Design carries that understanding forward.

For someone visiting the website, that might mean making information easier to find, creating clearer paths through complex content, or establishing stronger visual hierarchy. For an internal team, it might mean creating flexible components that allow marketers to build new pages without needing a designer or developer every time. For an administrator, it could mean considering how content is structured and managed behind the scenes.

We keep our clients closely involved throughout this process because they understand the people interacting with their organization in ways we can't learn from analytics alone. Our role is to combine that knowledge with research, UX principles, accessibility best practices, and our experience designing digital experiences.

The result isn't a website designed around one person's preferences. It's an experience designed around the people who need to use it.

Design Builds on the Work We've Already Done

Design is the third step in our seven-step website process:

Research → Plan → Design → Build → Launch → Support → Grow

We don't begin Design by opening a blank canvas and deciding what might look good. By this point, Research has given us a better understanding of the organization, its audiences, goals, current website, competitors, and available data. Plan has turned those findings into decisions about information architecture, content hierarchy, user journeys, and functionality.

We also have wireframes.

The wireframes created during Plan act as the skeleton for the visual design. They establish what information needs to be on key pages, how that information is organized, and what users need to be able to do.

Design adds another layer of thinking.

How do we use typography and spacing to reinforce that hierarchy? Which elements should draw attention? How should different types of content be distinguished? What interaction patterns will feel intuitive? How does the brand translate to a digital environment?

Because those decisions are built on work we've already done, we're not designing based on assumptions. We're continuing to solve the problems identified earlier in the process.

Establishing the Visual Direction

Before we start designing complete pages, we often use style tiles to establish the site's visual direction.

Style tiles allow us to explore how the organization's brand translates to the web through elements such as typography, color, imagery treatment, buttons, interface elements, and other visual patterns.

The distinction here is important: we're not simply putting together a collection of inspiration.

We're applying the visual direction to elements that could actually exist on the website.

Depending on the project, we may explore more than one direction. Our design team presents the thinking behind the work, the client responds to it, and together we refine the direction.

This gives everyone an opportunity to align on the visual language before that language is applied across full page designs.

It also creates a more useful feedback conversation. Instead of reviewing an entire homepage and trying to decide whether the concern is the typography, photography, layout, colors, content, or structure, we can focus specifically on the visual direction.

Once that's established, the next round of design decisions has a much stronger foundation.

Applying Design to Real Experiences

From there, we start applying the approved direction to the website itself.

Depending on the project, we might design the homepage and several key interior templates. We may focus on reusable sections and components. For a more complex website, we may also design experiences such as account areas, portals, directories, forms, tools, or other functionality.

We don't necessarily design every individual page.

Instead, we identify the experiences that give us enough information to establish how the larger system should work.

A service detail page, for example, might establish patterns for page introductions, supporting content, related resources, testimonials, calls to action, and forms. Those patterns can then be used elsewhere without requiring every future page to be designed from scratch.

That's an important shift from thinking about pages to thinking about systems.

The goal is consistency without rigidity.

Designing for Flexibility

A website rarely stays exactly as it was on launch day.

A marketing team may need to create a landing page for a new campaign. Sales may need a new resource to support a service offering. HR may add a new type of career content. An administrator may need to reorganize information as the business changes.

We want the design to account for that.

Rather than creating highly specific layouts that only work for one piece of content, we design reusable components and flexible sections that can work together in different ways.

That gives internal teams more control over the website while maintaining consistency in areas such as typography, spacing, hierarchy, accessibility, and brand presentation.

There is a balance to strike.

Too little flexibility can make a website frustrating to maintain. Too much flexibility without clear rules can lead to inconsistency and eventually make the site difficult for visitors to use.

Part of our design process is finding the right amount of structure for the organization and the people who will manage the website after we're gone.

Considering the Experience Beyond the Desktop Mockup

A polished desktop design is only one representation of the actual website.

Real users will arrive with different devices, screen sizes, abilities, content needs, and circumstances. Real content will also rarely fit as perfectly as placeholder content does in a design file.

Our team considers those realities as part of the design process.

What happens to the navigation on a smaller screen? How does a complex section reorganize on mobile? Is the text still readable? Is there enough contrast? Is it clear which elements are interactive? What happens if a headline wraps onto another line or a content editor adds more copy than expected?

Accessibility is part of those conversations as well. Contrast, typography, hierarchy, interaction patterns, and other design decisions can all make an experience easier or harder to use.

Thinking through these scenarios early helps us create a design that can hold up outside of a presentation and in the hands of actual users.

Reviewing and Refining Together

Design is collaborative, but productive collaboration needs structure.

At key points in the process, our design team presents the work to the client and explains the thinking behind the recommendations.

We want clients to understand why we're proposing something, not simply see the finished design and give it a thumbs-up or thumbs-down.

That context also makes feedback more productive.

Maybe we've missed something important about how a particular audience behaves. Maybe an element doesn't feel consistent with the organization's brand. Maybe an internal team uses content in a way that wasn't apparent during earlier conversations.

That's valuable information.

At the same time, our designers can provide context when a recommendation is tied to usability, accessibility, hierarchy, consistency, or something we learned during Research and Plan.

The process isn't about our team defending a design or the client telling us exactly how to design it. We're bringing different types of expertise to the same problem.

That collaboration helps us get to an approved direction that works for the organization and its users before development begins.

Design Doesn't Stop at Handoff

Once the visual direction and key experiences are approved, we're ready for Build.

But that doesn't mean Design is finished.

Static designs can't answer every question that comes up when a developer starts turning them into a functioning website.

A component may need to accommodate an unexpected amount of content. An interaction might require more definition. Something may behave differently on mobile than anticipated. Development may uncover an edge case that wasn't represented in the original design.

Our designers stay involved during Build to help answer those questions, fill in gaps, and make recommendations as the website takes shape.

That ongoing collaboration between design and development is important because the goal isn't to reproduce a mockup pixel for pixel.

The goal is to preserve the thinking behind the design while creating something that works in the real world.

What We Have at the End of Design

By the end of this phase, we have much more than a collection of polished page designs.

We have an agreed-upon visual direction. We have established patterns and components. We've thought through how key experiences should work across different devices and content scenarios. We've considered how external and internal users will interact with the website. And we've given the development team a clear foundation for Build.

Most importantly, those decisions connect back to the work that came before them.

Research helped us understand the problem.

Plan gave the experience structure.

Design determines how that structure communicates, functions, and feels for the people using it.

That's what we mean when we talk about using design to solve problems. The objective isn't simply to make something look better. It's to make the website more useful—to the people visiting it, the people working with it, and the organization relying on it.

Coming Next: Build

With the research complete, the plan established, and the design system defined, it's time to turn those decisions into a functioning website.

Next in our seven-step process is Build, where our designers and developers work together to translate the approved experience into flexible, reusable components and functionality that work in the browser.