A team collaborates around a wooden table using laptops and tablets displaying digital content.

Beyond responsive design: designing for intent, not just screens

A website can fit every screen and still make people work too hard to get what they need. As experiences become more responsive to intent, designers need to define what can adapt and what can't.

Key takeaways

  • Responsive layouts still matter. Designing around intent adds decisions about which content and components belong in a response, and when an action is appropriate.
  • The order of information can adapt. Facts, permissions and accessibility standards can't become negotiable.
  • Start with one task. Define how the experience should handle missing information, test where it fails and keep another route to help available.

Making a website fit someone's screen doesn't mean it helps them finish a task. The next design responsibility is deciding how the experience should respond when the visitor's need doesn't fit the journey we've planned.

When responsive design was becoming standard, I kept having the same conversation: don't hide content to make it fit a smaller screen. Rewrite it. Work out what matters and make it easier to use. Mobile forced us to make better decisions about hierarchy and language, not just layout.

I've taken a similar approach to navigation for years. Content can move someone through a site more effectively than asking them to work out which menu label applies to them. But even useful content often sits in a sequence we've chosen in advance.

Now a visitor can express what they need in their own words and refine it through a conversation. As those experiences develop beyond answers, there's an opportunity to bring relevant content and components together around the task. That's part of the shift from fixed to fluid experiences we're calling the Intelligence Era.

The design work doesn't disappear. Teams need to decide which sources to trust, how components should behave and where the experience must stop and ask for more information or hand over to a person.

We explored the broader shift in Beyond static experiences: How AI is changing the next generation of websites. Here, I want to focus on what that asks of the people designing the experience.

How does intent-driven web design differ from responsive design?

Responsive design adapts a layout to the screen. Designing around intent adds another responsibility: deciding which information and next step will help someone complete a particular task. Clear language, accessible components and visual hierarchy still matter, but the visitor's question can help determine what's relevant.

A café owner trying to arrange outdoor seating may need guidance from several parts of a council website. The council's departmental structure isn't their concern. They need to know which requirements apply and what to do first. An intent-driven experience should help bring that information together; as richer interfaces develop, it could also present a relevant step list or application link without making the visitor assemble the journey themselves.

The question gives the team a starting point, not a complete picture. The location may be missing, or the visitor may not know whether the seating would be on public or private land. Those gaps affect what the experience can responsibly tell them. A useful response can begin with the context someone gives in the interaction; it doesn't require an existing customer profile. That doesn't remove the need to explain how their inputs are used and retained.

What should adapt in an intent-driven website and what should stay consistent?

I wouldn't start by asking a system to invent an interface for every question. I'd start with the content and components the team already trusts, then define where each belongs and what information it needs. The order of information can change: outdoor seating requirements might come first for one visitor, while food preparation requirements matter more to another. Both should draw from the same approved guidance. A different question can't change a published fee or turn general guidance into permission to proceed.

As teams introduce more adaptable interfaces, a comparison, deadline notice or application link could appear where it's useful. Its accessible behavior, labels and visual standards should remain dependable. The design system needs to describe when to use a component as well as how it looks.

People also need a way out. Source pages, browsing and human help should stay available. If a visitor would be better served by opening the guidance or speaking to someone, don't make them keep asking questions.

Intent-driven web design example: helping visitors navigate council permits

Imagine the café owner asking, “Which permits do I need for outdoor seating, and what should I apply for first?” This is an illustrative design scenario, not a deployed service or a claim about current Squiz functionality. I'd want the experience to ask for the details that actually change the answer. If the approved guidance distinguishes public and private land, the response needs that context. It shouldn't guess from the words “outdoor seating,” and it should explain why the detail matters.

Once there's enough information, a step list could make the sequence easier to follow, but only if the council's guidance establishes that sequence. If it doesn't, the experience shouldn't invent an application order. The same applies to fees and deadlines.

The boundary around action matters just as much. Explaining which application may be relevant doesn't mean the proposal is approved. A link to a form is a useful next step; submitting it or confirming an official decision involves separate systems, permissions and checks.

If the guidance doesn't cover the situation, I'd want a clear route to the right team, with enough context for the visitor to know what to ask. They should still be able to open the source material and browse. That's the design goal: less work for the visitor, with the council's approval process intact.

How to govern and test intent-driven web experiences

There's a cost to making an experience more adaptable. The team has to maintain the source content, define how the response should behave and test more than the appearance of a finished page. A conversational interface won't fix contradictory policy or unclear service ownership.

For the permit example, I'd test what happens when the location is missing, the request changes or the situation falls outside the guidance. Does the response ask for necessary context? Does it acknowledge what it can't establish? Can the visitor reach a useful next step without treating guidance as approval?

Someone needs to own each boundary. Content owners maintain the guidance, designers define interaction patterns and components, and service teams confirm what actions are permitted. Privacy, accessibility and technical specialists help establish the controls and test whether they hold up. Measure whether people can complete the task, whether avoidable calls and enquiries fall, and what it costs the team to maintain. The number of generated answers won't tell you that.

How Squiz products support intent-driven web experiences today

There are practical starting points in Squiz's products today. Content Intelligence audits content for accessibility and AI readiness, identifies gaps and prioritizes fixes. Conversational Search, a capability of Squiz Funnelback Search, lets visitors ask questions in their own words and follow up, with answers drawn from selected content sources and links to those sources. Teams can configure behavior controls and a default response and CTA when the content doesn't support an answer.

Squiz DXP brings reusable components, workflows, permissions, forms and integration capabilities into the platform. Those are useful foundations for richer experiences. Connecting them into a particular service journey still needs design, configuration and, where required, integration work. It isn't a promise that Conversational Search automatically assembles any interface or completes a transaction.

How to start designing a website around visitor intent

You don't need to redesign every journey to begin. Pick one task people struggle to complete. Find out what information they're missing, what your content can reliably answer and where they need another route to help. Improve the source material that affects that task, test the response and use unresolved questions to decide what needs work next. That's enough to give the team something concrete to design and test.

What comes after the hamburger menu? I don't think the answer is another way to hide the navigation. It's making the content and the next step easier to reach, even when someone's need doesn't fit the route we've laid out. Pages and menus still have a job, as does the website as the authoritative foundation for experiences people use directly and those mediated by AI. As more of the experience can adapt around intent, designers need to define the building blocks and boundaries that make that adaptation useful.

Where should you start?

Use the website readiness assessment to identify gaps in your current experience and decide what to improve first.