Website user experience (UX) concerns what people can understand and accomplish as they interact with a site; user-interface design (UI) makes the interactions, layout, language and states perceivable and coherent. Professional UX/UI work is therefore not a coat of visual polish. It reduces uncertainty at meaningful decision points: finding a service, assessing fit, comparing options, completing a form or returning to an unfinished task.
For SaaS and B2B websites, decision-making often spans roles and visits. An evaluator may seek integration details while a founder wants commercial context. A useful design lets both progress without requiring every visitor to follow the same scrolling story. Accessibility and performance are properties of that experience, not optional final passes.
Executive takeaways
- Research tasks and decisions before wireframes. A stakeholder’s preferred homepage style is not equivalent to observed user need.
- Separate clarity, trust, usability, accessibility and visual expression; a page can succeed at one and fail at another.
- Use information scent—labels and contextual signals that accurately predict the next page—to make complex service architectures navigable.
- Prototype key states, including errors, empty results, loading, confirmation and mobile menu—not only pristine screenshots.
- Combine small qualitative task tests with appropriately powered quantitative measurement. Neither can replace the other.
1. Understand the work the visitor is trying to finish
A design project starts with questions that can be observed. What prompted the visit? What decision must the visitor make? What information is missing? What would count as success or a safe next step? Record the task in the visitor’s words rather than retrofitting a marketing KPI. “I need to know whether this platform supports a migration from our current CRM” is testable. “The site must look premium” is a design aspiration, not a user task.
Build a research set from actual sales objections, support questions, search patterns and interviews. Record source confidence. Internal stakeholders can reveal organisational constraints but cannot stand in for all buyers. Separate first-time visitors, returning customers, technical evaluators and users of assistive technology as appropriate. Recruit relevant participants; avoid assuming that a five-person convenience sample represents an entire market.
2. Translate the task into an information hierarchy
Useful pages have a sequence: orient, explain, substantiate, compare, act. Put the reason for the page early, then present the supporting evidence near the decision it affects. A service page may need fit and boundaries before a contact form; a Guide needs a direct explanation before a commercial suggestion. Headings should allow scanning without requiring the reader to parse every paragraph.
Labels are promises. If a menu item says “Resources” but contains only unrelated marketing blogs, the user must learn an unexpected taxonomy. Test whether people can predict content behind each destination. The Nielsen Norman Group’s guidance on small-sample usability testing is valuable for iterative issue discovery, but it does not support estimating a numeric population conversion rate from five participants.
Bargaon explanatory framework
Information hierarchy
A page must earn the right to ask for action
Design decision: if visitors reach the correct page but still cannot explain the offer, repair the page’s evidence hierarchy—not simply the menu. If visitors know what they need but cannot find the page, repair navigation and contextual signposting first.
3. Design interaction states, not only attractive screens
Document the full state model for each consequential interaction. What happens when a required field is empty? When an email address is mistyped? When a form successfully submits but the server rejects the request? When the user changes a filter and no matches remain? When a mobile menu opens with a keyboard? A polished default screenshot proves none of these behaviours.
Use an interaction contract: trigger, feedback, data change, error recovery and focus management. Present helpful inline feedback and prevent duplicate actions where they create repeated submissions. For forms, ask only for information needed at the current stage; explain why anything sensitive is requested. W3C’s form-label tutorial explains how visible labels and correctly associated controls improve both clarity and assistive-technology access.
| State | User needs to know | Design response | Test to run |
|---|---|---|---|
| Initial | What can I do here? | Clear label, sensible default, visible action | Understand task without coaching |
| Loading | Did my input register? | Timely feedback, preserve entered data | Slow-network simulation |
| Error | What failed and how can I recover? | Field-specific explanation and retry | Keyboard and screen-reader error review |
| Success | Was the request actually received? | Accurate confirmation and next step | Server/CRM receipt check |
| Empty | Why are there no results? | Explain filters and offer reset | Filter combinations on mobile |
4. Design for mobile, keyboard and variable vision
Mobile UX is not desktop content compressed into narrow columns. Prioritise reading order, touch targets, menu disclosure, table strategies and form labels. Decide whether a dense matrix belongs in a horizontally scrollable region, a stacked comparison or a downloadable accessible document. Preserve context: a user should know what every number means without visually aligning distant columns.
Keyboard focus must be visible, interactive controls must be operable, and content should remain meaningful at zoom. Check contrast and error identification through WCAG 2.2’s testable criteria. An axe scan can flag specific defects; it cannot certify a full page or all its responsive states. Moderated tasks with relevant assistive technology add evidence that automation misses.
5. Build a design system around reusable decisions
A component system is useful when it standardises behaviour as well as appearance. Define typography, spacing, semantic colours and reusable content blocks, but also define error states, keyboard patterns and responsiveness. A CTA button that is teal in three templates but has different meaning on each is not a coherent component contract.
For Gutenberg, control global presets and editor behaviour through a small set of documented tokens. The WordPress theme.json reference describes how a theme can expose consistent controls. Use native editable blocks where appropriate; avoid building a custom block only because it is visually convenient in one static prototype. Template consistency should not force all Guide chapters or commercial pages into identical content structure.
Bargaon explanatory framework
Interaction-state contract
The user journey includes failure and recovery
6. Evaluate usability with complementary evidence
Qualitative research explains why a user hesitates or fails. Behavioural analytics may show where a symptom appears. Controlled experiments may estimate whether a change affects a predefined metric under appropriate conditions. A recording of one user abandoning a form is a hypothesis generator; it is not proof that the form caused all abandonment. Microsoft Clarity’s documentation describes reconstructed sessions rather than literal videos of users. Privacy and consent requirements must be evaluated before recording tools are enabled.
| Evidence source | Useful question | Limitation | Next action |
|---|---|---|---|
| Moderated task interview | Why is the label misunderstood? | Small sample; facilitator effects | Revise label and retest |
| Page/interaction analytics | Where are users dropping out? | Cannot establish cause | Segment and inspect the journey |
| Session reconstruction | Where might friction occur? | Behaviour context is incomplete | Frame a testable hypothesis |
| A/B test | Did a change move the preselected metric? | Power, duration and variant contamination | Review experimental validity |
| Customer support notes | What problems recur after launch? | Not representative of all users | Prioritise high-consequence issues |
7. A hypothetical B2B comparison-page redesign
A SaaS vendor has two product tiers, and its sales team reports that evaluators misunderstand integration requirements. The existing comparison page uses vague checkmarks and a large hero image. Rather than move the CTA higher, the team interviews technical buyers, labels the integration conditions plainly, adds a dependency table and tests whether participants choose the appropriate tier. Designers prototype the error and contact states and engineering validates the technical claims.
A small study reveals several misunderstandings, but that is not a quantified revenue impact. The team ships an approved change, then monitors relevant enquiries and subsequent sales clarifications. The example demonstrates a decision path, not an observed client outcome.
8. A practical design-review rubric
Review each important page against five questions: orientation (where am I?), comprehension (what is offered?), confidence (what evidence supports it?), action (what happens next?) and recovery (what if something goes wrong?). Mark findings by severity and evidence, not subjective numerical aesthetics. A broken mobile submission is typically more consequential than a minor illustration difference, but commercial context determines the priority.
For each finding record the affected audience, reproducible task, screenshot or observation, hypothesised cause, owner and retest date. Avoid marking “complete” because a designer signed off a Figma file; use an accessible, responsive browser implementation for acceptance.
9. An iterative 90-day sequence
Discover: align stakeholders on a few representative buyer tasks, audit existing design and navigation, recruit relevant participants and document starting measures. Prototype: test information hierarchy and interactive states, refine mobile and keyboard patterns, and implement a narrow reusable component set. Validate: run a production-equivalent test, verify data delivery and accessibility, observe agreed outcomes and schedule the next round. The sequence is illustrative; a real engagement depends on complexity and access.
Field guide: specify, test and govern the interaction system
A polished screen does not define how an interface behaves. For each reusable component, document a small interaction contract: triggering action, resulting state, visual and spoken feedback, keyboard behaviour, error recovery and destination. The contract should cover empty, loading, success, failure and disabled states where relevant. In a design review, the missing error state is often more consequential than a small change in colour or border radius.
Consider a mobile contact form. A user submits, the network request fails and the interface shows a green success message anyway. The layout may look complete, but the interaction has created false confidence. The design specification must distinguish client validation from server receipt, preserve entered values after recoverable errors, put focus or an announcement where the user can perceive it, and avoid multiple submissions when one is pending. Testing the screen with a pointer is not enough.
| Component | Required state or task | What to verify |
|---|---|---|
| Mega menu | Closed, open, focused item, Escape, focus return | Navigation works with keyboard and touch, without trap |
| Form | Invalid field, submitting, delivery error, confirmed receipt | Label and error association; actual acknowledgment is accurate |
| Accordion | Collapsed/expanded | Button state and relationship are communicated; no hidden tab stops |
| Content table | Narrow mobile and enlarged text | Table retains headings and is navigable without page-wide overflow |
| CTA | Focused, activated, unavailable destination | Descriptive action, visible focus and real destination |
Build a moderated task protocol, not a preference poll
Ask participants to complete representative tasks with minimal coaching. Record whether they locate the right information, complete the task, recover from an error, and can explain the next step. Include different roles and devices where those differences matter. Start with exploratory observation; only then ask what users thought of the layout. A favourable aesthetic opinion cannot correct a failed task.
Use two evidence streams. Qualitative observation explains a mechanism: a user mistakes a label, misses a constraint or assumes a button has submitted. Quantitative data can show frequency or segment differences, subject to instrumentation and consent. These streams should inform one another, not substitute for each other. A session recording is an incomplete view of interaction, not a direct recording of intent. For the limits of small-sample qualitative study, see Nielsen Norman Group’s guidance.
Treat accessibility as a design input
Apply WCAG 2.2 to concrete controls from the first component sketch: keyboard operability, visible focus, label associations, reflow, pointer target requirements where applicable, and meaningful error identification. Test content at zoom and enlarged text. Decorative contrast ratios alone cannot establish that an interface is usable. Use native HTML controls where possible and document any deviation. A desktop Figma mockup cannot prove these behaviours; a rendered, functioning implementation must be tested.
For Gutenberg, constrain typography, spacing and colour decisions with the WordPress theme.json reference, but preserve deliberate editorial flexibility. Excessively restrictive tokens can push authors into brittle custom markup; unlimited controls can fragment the design system. Test the editing workflow with a nontechnical content author: replace an image, edit a card, add a long title, and confirm the public layout still holds.
Define design acceptance in observable terms
For every changed journey, choose three to five critical tasks, relevant devices, keyboard scenarios, and an error state. Record who tested, what failed, what was changed, and what remains uncertain. Shipping decisions should rely on functional acceptance and observed task success rather than on a screenshot approval alone. Iterative usability checks are research activities; an accessibility conformance claim requires a separately scoped evaluation.
10. Frequently asked questions
Can UI design alone improve conversion?
It can remove friction, but weak offer-market fit, poor traffic, unverified proof or failed lead receipt may remain. Diagnose the whole journey before assigning a commercial effect to visual polish.
Is a larger sample always better for UX research?
Not automatically. Small qualitative studies can efficiently expose usability problems, while quantitative estimation usually needs a different design and more observations. The correct sample depends on purpose and participant diversity.
Do we need a custom design system before starting?
Not necessarily. Begin with reusable patterns that address real repeated decisions. Codify behaviour and accessibility as components stabilise; avoid component libraries that delay necessary learning.
What is the acceptance test for a design?
Critical tasks succeed in a production-equivalent browser across meaningful devices and input methods, copy matches verified business claims, and error/success states behave correctly. A screenshot is one artifact, not a complete acceptance test.
References and further learning
- Nielsen Norman Group — how many users in a usability study?. Qualitative discovery, exceptions and sample-size context.
- W3C — WCAG 2.2. Accessible interactions and content requirements.
- W3C WAI — form labels. Practical accessible form controls.
- WordPress —
theme.jsonreference. Gutenberg design-system implementation. - Microsoft — session recordings overview. Evidence type and limitations.
Apply these design decisions to the relevant commercial journey and implementation constraints. This Guide explains methods, not a promise of specific project outcomes.