Every discipline that goes into fixing a website, explained properly, without a glossary of buzzwords. This is the thinking behind everything we do at Constant Insights, and a place to learn if you'd like to know more.
Before you fix anything, you need to know what's actually going wrong, and for whom. This is the evidence-gathering end of the work.
Talking to, watching and testing with real people who use (or should use) your product, instead of guessing what they want. Interviews, usability testing, surveys, analytics: whatever gets you real evidence.
In practice. The most common mistake founders make is skipping this step and jumping straight to redesigning. Ten minutes watching one real customer try to check out is usually more revealing than a week of internal debate.
In every review
The philosophy underneath everything else on this page: decisions get made on real evidence about real users, not internal opinions or best guesses. Every discipline here sits inside this approach.
In practice. UCD is a loop, not a one-off step: understand, design, test, refine, repeat. A one-time review still follows the loop. It just runs it once, fast, and hands you the output.
How we work
What people actually do on your site, at scale: where they click, where they scroll to, where they leave. This is the quantitative half of research. User interviews are the qualitative half. You need both.
In practice. Analytics tells you where people are dropping off. It rarely tells you why. That's what pairing it with real user research is for: the numbers show the symptom, people explain the cause.
When the data's there
A structured look at what similar businesses are doing. Not to copy them, but to understand what your customers already expect as normal before they land on your site.
In practice. If every competitor in your space has a live chat bubble or a certain checkout flow, its absence on your site reads as a gap to customers, even if it wasn't a deliberate choice.
For context
Once you know what's wrong, this is where it becomes something people can actually use: structured, worded and designed properly.
How something works, not just how it looks. UX design shapes the journey someone takes through your site or product so it feels obvious, not confusing.
In practice. UX and UI get used interchangeably, but they're different jobs. UX is the flow and logic. UI is the look. A site can be beautiful and still be confusing, and that's a UX problem, not a UI one.
Core of the work
The actual look: colour, type, spacing, imagery, visual hierarchy. UI design is what makes a site feel trustworthy and professional at a glance, before anyone reads a word.
In practice. Visual polish affects trust more than people realise. A dated or inconsistent design can quietly make a solid business look unreliable, however good the product actually is.
First impressions
The small stuff: what happens when you click, tap, hover or scroll. Good interaction design makes a site feel responsive and alive. Bad interaction design makes people wonder if it's broken.
In practice. This is often the cheapest category of fix on the whole page. A button that doesn't visibly react, or a form that doesn't show what went wrong, costs almost nothing to fix but quietly erodes trust every time it happens.
Cheap, fast fixes
The actual words on your buttons, forms and error messages. It's a discipline of its own. The difference between "Submit" and "Get my free quote" is content design, and it moves conversion numbers.
In practice. Content design is usually the fastest, cheapest fix in any review, because it's just words. It often has an outsized effect, since confusing copy is one of the top reasons people abandon a form.
Cheap, fast fixes
How your content and pages are organised and labelled. Bad IA is why people can't find the "contact us" page, or give up three clicks deep. It's invisible when it's right and infuriating when it's wrong.
In practice. A common test is asking someone unfamiliar with your site to find a specific piece of information, live, and timing how long it takes. If it's more than a few seconds, that's an IA problem, not a them problem.
When people can't find things
Where the plan meets reality: prioritising what matters, working with the people who build it, and making sure it keeps getting better.
Deciding what to actually build or fix first, based on impact and effort, not whoever shouts loudest. Product thinking turns a long list of problems into a plan you can realistically follow.
In practice. A review that hands you 40 unranked issues isn't that useful. Good product thinking narrows it to "fix these three first, they're the ones actually costing you money."
How we prioritise
Conversion Rate Optimisation: making more of your existing visitors actually buy, sign up or enquire, rather than spending more to attract new ones. Often the fastest return of anything on this page.
In practice. Most businesses spend heavily on ads to bring more people to a leaky site, when fixing the leak would have been cheaper and had a bigger effect on revenue.
Core of the work
Recommendations are only useful if they can actually be built. We frame fixes so your developers can pick them up and run with them: realistic, scoped, and not designed in a vacuum.
In practice. Every recommendation comes with roughly how big a job it is, not just what's wrong, so you can weigh it against everything else on your plate before committing.
How we hand things over
Making sure your site works for everyone, including people using screen readers, keyboard navigation, or who simply can't see a pale grey font on white. It's often legally required, and it's just good practice.
In practice. Accessibility fixes usually improve the experience for every visitor, not just those who strictly need them. Clearer contrast and simpler navigation help everyone.
Checked in every review
Not a service, just useful context. AI is already part of how digital work gets done, so here's the plain-English version, with the same evidence-first thinking as everything above.
Not "learn to prompt a chatbot." It's figuring out which specific, everyday tasks in a team could genuinely be faster or better with AI, and which ones absolutely shouldn't be.
In practice. The useful question isn't "should we use AI," it's "which three tasks this month would actually benefit," grounded in how the team really works, not hype.
A plain-English map of the different categories of AI tool (chat assistants, writing and image tools, workflow automation, "copilots" built into software you already use) and what each is actually good for.
In practice. Most teams have only tried one category, usually a chatbot, and assume that's "AI." The bigger wins are often in the automation and copilot categories nobody's looked at yet.
The practical skill of getting genuinely useful output from AI tools: giving clear context, checking the result, and knowing when to trust it and when to double-check it.
In practice. The gap between someone who "uses AI" and someone who gets real value from it usually comes down to a handful of habits, not technical skill.
The honest caveats: AI tools can be confidently wrong, data you paste in may not stay private depending on the tool, and not every task is a good fit for AI at all.
In practice. A five-minute "what not to paste into a chatbot" conversation with your team is one of the highest-value, lowest-effort things most organisations haven't had yet.
Every project moves through the same rough shape: understand, then shape, then build and improve, with AI thinking woven in wherever it's genuinely useful, not bolted on at the end.