how to give useful feedback on a website design
In every review session we run, we tell the room what kind of feedback we need before anyone opens their mouth.
Not because we’re precious about it. Because the wrong type of feedback at the wrong stage is the single biggest reason redesign projects spiral.
Here’s what that looks like in practice. A team reviews a wireframe. The wireframe exists to test structure, flow, and content hierarchy. Someone raises a concern about colour. Someone else flags the font. Now the conversation has shifted to decisions that haven’t even been made yet.
The structural problems nobody mentioned? They survive into the next round. And the next.
By the time anyone catches them, the visual design is built on a broken foundation. Rework gets expensive fast.
Most teams think feedback quality is about being more detailed. It’s actually about matching the type of input to the phase of the project. Those are two very different skills, and the second one is where almost everyone falls short.
That timing problem is just one part of a larger feedback methodology we mapped out in our latest article.
what makes a good website footer
Can you describe, from memory, what’s in your website footer?
Not vaguely. The actual links, the groupings, the order they appear in.
Almost nobody can. Because almost nobody planned it.
The footer got treated like the last five minutes of a build. Throw in a logo, paste some links, ship it. But that strip of space appears on every single page of your site. Every. Single. One.
And here’s what most teams miss: your header navigation can realistically hold five to seven items before it turns into a mess. Everything else your visitors need has to live somewhere.
The footer is that somewhere.
When someone scrolls all the way to the bottom, they’re either looking to go deeper or they already failed to find what they wanted higher up. Both of those moments are high intent. Both of them deserve better than a random cluster of links nobody has reviewed since launch.
The best-performing footers we’ve seen are prototyped at the same stage as the header. First round of wireframes. Not after the site is “done.”
That gap between planned and unplanned is bigger than most people realise.
We broke this down properly in our latest article.
should i use a website template or custom design
Most teams choose template vs. custom design based on budget.
Best-run projects choose based on what the website actually needs to do that no other website does.
Most teams hear “custom” and assume it means every pixel designed from zero.
Best-run projects know there’s a middle ground: purpose-built components assembled into a system, genuinely custom but far more efficient.
Most teams think they need bespoke when a well-chosen template would get them live months sooner.
Best-run projects recognise that roughly 60% of business websites are better served by templates. And they’re honest about whether they’re in that 60%.
Most teams get burned because they picked the wrong starting point.
Best-run projects never confuse “template with heavy modifications” for “custom design.” Those are different things with different costs, timelines, and outcomes.
The real problem isn’t which option is better. It’s that almost everyone misjudges which category their business falls into.
We wrote a practical framework for making this decision with confidence.
what is responsive design and why does it matter
“Mobile-friendly” is not the same as responsive.
Most mid-market sites pass the basic sniff test. They load on a phone. Nothing overlaps. The team moves on.
But responsive design isn’t about fitting content onto a smaller screen. It’s a set of decisions about fluid grids, flexible images, content hierarchy, and conditional logic that determine whether a site actually works across devices or just survives them.
Here’s one that surprises people: a site can serve the same 3MB hero image to a phone that was built for a retina desktop display. The visitor on the train doesn’t see the difference in quality. They feel the difference in speed.
And that’s just images. Navigation patterns change. Forms become harder to complete. Brand perception shifts at smaller sizes in ways nobody tested for.
The real problem? These decisions need to happen at the start of a project. Most teams treat them as a QA step at the end. By then, the architecture is locked and you’re patching instead of building.
More than half of all web traffic is mobile. “Not broken” isn’t the bar.
We broke this down in our latest piece.
how to design a website navigation that works
Something we keep noticing in mid-market website projects:
The menu mirrors the company’s internal departments. About Us, Products, Services, Solutions, Resources, Contact.
It feels logical to everyone in the room. Because it matches how they think about their own business.
But visitors don’t think about your org chart. They arrive with a task. Compare pricing. Find a case study. Understand what you actually do. And if the menu doesn’t map to those tasks, they leave.
Most teams treat navigation as a design job. Hand it to someone who arranges pages into a dropdown and moves on. The real problem is that nobody asked a more fundamental question first: what are the five to seven things people actually come to this site to do?
Not what you want them to do. What they actually do.
The gap between those two things is where bounce rates quietly inflate and marketing ROI erodes without anyone noticing for months.
We wrote about why this keeps happening and what it costs.
How Much Does A Website Prototype Cost
Your website prototype isn’t a design exercise. It’s a business decision that shapes your pipeline for years.
Get it wrong and you’re building on assumptions. Your development team codes the wrong thing. Your sales team sends prospects to pages that don’t convert. You burn months and budget fixing problems that should have been caught before a single line of code was written.
The cost range is enormous. £3,000 to £30,000+, with most mid-market B2B projects sitting between £5,000 and £15,000. That spread exists because “prototype” covers everything from a basic clickable wireframe to a fully interactive model with conditional logic, form validation states, and responsive breakpoints across multiple devices.
What surprises most people is where the money actually goes. It’s not the screens. The bulk of the investment sits in research, information architecture, content strategy, and interaction design. The visual output is almost a byproduct of that thinking.
We published a full breakdown of the four factors that determine prototype cost and where the budget actually lands for different project types.
What Is A Clickable Prototype
Most website projects don’t fail in development. They fail in the gap between what stakeholders imagined and what actually got built.
That gap exists because teams sign off on static screenshots and assume everyone sees the same product. They don’t. A flat mockup can’t reveal that the navigation logic falls apart three clicks in, or that the user journey your sales team needs is completely different from what marketing approved. These problems only become visible when someone can actually click through the experience.
This is exactly what clickable prototypes exist to solve. But most teams either skip them entirely or confuse them with wireframes and mockups, which answer very different questions. The terminology gets muddled constantly, and that confusion has real cost implications when you’re heading into a six-figure build.
We wrote a detailed piece on what clickable prototypes actually are, how they sit alongside other design deliverables, and why the distinction matters far more than most project teams realise.
What Is The Difference Between UX And UI Design
Say you’re reviewing a website redesign proposal and it mentions “UX/UI” as a single line item. No breakdown of what falls under each. No separate phases. Just one lump of work with a price next to it.
That’s usually where confusion starts. Because UX and UI are genuinely different disciplines with different deliverables, different skill sets, and different stages in a project timeline. UX figures out what needs to happen on each page and in what order. UI figures out what every element actually looks like. One defines the journey a user takes. The other defines the vehicle they take it in.
The problem isn’t that people don’t know the difference in theory. It’s that when they’re treated as interchangeable during a build, you end up with sites that look polished but quietly underperform. Or sites that convert well on desktop but fall apart visually on mobile because nobody separated the structural decisions from the visual ones.
We wrote a full breakdown covering what each discipline actually involves, how they work together in practice, and where things tend to go wrong. Worth a read if you’re about to kick off a website project or evaluate one that’s already in motion.
What Is The Difference Between A Wireframe And A Prototype
If your website redesign keeps requiring “one more round of revisions” that nobody budgeted for, it’s usually not a design quality problem. It’s a process sequencing problem.
Most of the expensive misalignment we see traces back to the same few patterns:
Stakeholders reviewing a static mockup and treating it like a wireframe → feedback on layout and hierarchy arrives after visual design is already underway.
Teams skipping wireframes entirely and jumping to a prototype → structural decisions get buried under interaction design before anyone agrees on page hierarchy.
Designers calling an interactive wireframe a “prototype” → the client expects clickable functionality, gets a grey-box layout, and loses confidence in the process.
Tools like Figma make it easy to blur these stages together. That flexibility is useful in skilled hands, but dangerous when nobody on the team has defined what deliverable they’re actually reviewing and why.
The wireframe answers “what goes where.” The prototype answers “what happens when someone uses this.” They solve different problems at different moments. Collapse them and you pay for it in rework.
Wrote a full breakdown on the actual distinction and where each fits in a project.
Prototype-First Websites: The Fastest Way to Align Stakeholders and De-risk Big Decisions
Share Prototypes turn concepts into a visual experience you can click and interact with, so decisions get made early, with less politics and less rework. When stakeholders debate abstract concepts, meetings multiply. When they interact with a clickable representation of the solution, alignment can happen in hours instead of weeks. This guide is written for […]