Category: UX Design & User Experience

• 

  Why Is My Website Not Converting? Diagnose the UX Before Redesigning It

  Why is my website not converting? Often, the right visitor cannot quickly recognize that the page is for them, understand the offer, trust the evidence, choose a sensible next step, complete it without unnecessary effort, or recover when something goes wrong. That is a user-experience failure. But bad traffic, a weak offer, broken technology, missing measurement, and lousy follow-up can produce the same symptom. Diagnose the system before buying another redesign. Pretty pixels cannot rescue the wrong diagnosis.

  TL;DR: Why is your website not converting?

  • Confirm that enough of the right people are reaching the page. Forty random visits do not constitute a conversion crisis; they constitute forty visits.
  • Test the experience as a decision path: Recognize, Understand, Trust, Choose, Act, and Recover.
  • Treat accessibility as a condition across the whole path, not a compliance garnish sprinkled on at launch.
  • Remove accidental friction. Keep intentional friction when it protects qualification, safety, privacy, informed consent, or the quality of the next conversation.
  • Observe real people attempting real tasks. Analytics show where behavior changed; they rarely explain why.
  • Fix the earliest broken step. A button-color test is a particularly silly response when nobody understands the offer.
  • Measure the last meaningful outcome the website can influence, then follow it downstream to lead quality, sales, service, retention, or another business result.

  What UX design actually means for a business website

  User experience design is the discipline of making an experience effective, efficient, understandable, accessible, and satisfying for the people who must use it in a specific context. In plain English: decide who needs to accomplish what, then make that outcome possible without needless confusion or obstruction.

  That is broader than the interface. Our UI versus UX guide for business websites explains that boundary. It includes research, information architecture, content, interaction, forms, navigation, accessibility, performance, feedback, error recovery, and the operational handoff after somebody acts. The W3C explains that accessibility, usability, and inclusion overlap, while still requiring distinct attention. A technically compliant interface can remain frustrating. A generally usable interface can still exclude people with disabilities. Good UX has to deal with both realities.

  UX is not the tasteful coat of paint applied after everybody has already made the important decisions. It is the decision discipline that asks what the experience is for, who must succeed, and what evidence will show that they did.

  This is where some design conversations wander into the decorative wilderness. The client wants a giant looping video because it feels premium. The designer wants tiny gray type because restraint. The visitor wants to know whether the company can solve the problem before lunch. Guess which person the website actually needs to work for.

  Taste still matters. Distinctive visual character can improve recognition, memory, credibility, and brand preference. It just does not get veto power over comprehension, accessibility, or completion. A gorgeous interface that hides the answer is not sophisticated. It is expensive camouflage.

  Why is my website not converting? Confirm UX is actually the problem

  “The website is not converting” is a symptom, not a diagnosis. The failure can sit before the page, on the page, after the page, or inside the measurement pretending to describe the page.

  Use this sequence before prescribing UX work:

  Possible constraint	What it looks like	What to check before redesigning
  Measurement	People say leads exist, but reporting shows none—or the reverse	Submit every form, call every tracked number, inspect event definitions, notifications, consent behavior, CRM routing, and attribution
  Relevant volume	Conversion rate swings wildly because only a handful of qualified people arrive	Sessions by source and landing-page intent, sample size, seasonality, distribution, and whether the audience can reasonably act
  Traffic quality	Visitors arrive for a different problem, geography, price point, or level of intent	Queries, ads, referral context, entry pages, audience targeting, and sales feedback
  Messaging	People leave early or ask sales what the company actually does	Above-the-fold clarity, specificity, audience fit, message match, and the evidence supporting the promise
  UX	People understand the offer but get lost, hesitate, fail, or abandon the action	Navigation, hierarchy, choices, forms, accessibility, mobile behavior, feedback, errors, and task completion
  Offer	Qualified people understand everything and still do not want the trade	Price, risk, proof, differentiation, terms, urgency of the problem, and alternatives
  Operations	The website produces an action that the business mishandles	Response time, ownership, availability, qualification, sales process, onboarding, and service capacity

  Our website strategy guide goes deeper into diagnosing the commercial system. The important point here is simple: do not blame UX for every disappointing dashboard. A perfect booking experience cannot make an irrelevant offer desirable, and it cannot force the sales team to answer the phone.

  Once the evidence points to comprehension, navigation, interaction, access, or completion, UX becomes the right operating lens.

  The Scope Design UX Decision Path

  Most business websites ask a visitor to move through six decisions:

  1. Recognize: Is this page for my situation?
  2. Understand: What is offered, for whom, and why does it matter?
  3. Trust: Does the evidence support the claim?
  4. Choose: Which option or next step fits me?
  5. Act: Can I complete the task with appropriate effort?
  6. Recover: If I hesitate, make a mistake, or hit an exception, can I continue?

  Access is the foundation beneath all six. People using different devices, abilities, input methods, languages, network conditions, and contexts must be able to move through the path.

  

  The framework matters because businesses often optimize the last visible step while the first broken decision sits three screens earlier. They shorten a form when the visitor does not trust the company. They add testimonials when the page is attracting the wrong audience. They change the button from green to orange while the button says “Submit,” which is less a value proposition than an instruction from a parole officer.

  Find the earliest failing decision. Fix that first.

  1. Recognize: make the right person feel oriented

  A visitor arrives with a question, not an obligation to admire your homepage.

  Recognition means the page matches the context that brought the person there. The query, ad, referral, email, or sales conversation created an expectation. The page should continue that conversation instead of abruptly introducing a generic corporate personality disorder.

  Check whether the first useful screen makes these facts clear:

  • what situation or problem the page addresses;
  • who the offer is for;
  • what kind of outcome it supports;
  • whether geography, industry, timing, eligibility, or another constraint matters;
  • where someone with a different need should go.

  Recognition is not the same as cramming the entire company into a hero section. It is orientation. A person should know whether continuing is sensible.

  This is also where traffic and UX meet. If a search result promises a font-size guide and the landing page opens with a sales pitch for branding, the layout is not the main problem. The promise was broken before the visitor started reading.

  2. Understand: explain the offer without making people decode it

  Comprehension is the ability to explain the page’s essential meaning after a short, realistic encounter. It does not require reducing every complex service to three baby words. It requires a clear information hierarchy.

  Put the answer before the autobiography. Use concrete nouns and outcomes. Separate the primary promise from supporting detail. Explain unfamiliar terms when the audience needs them. Use headings that tell the story even when someone scans.

  People do read websites, despite the internet’s fondness for declaring reading dead every six months. They read selectively. They scan to decide what deserves attention, then read the sections that reduce uncertainty. That is why readable typography and useful structure matter. Our website typography guide covers font size, line length, hierarchy, and legibility; our content readability guide focuses on making the message easier to process without sanding off its intelligence.

  Comprehension fails when:

  • the headline could describe 400 competitors;
  • every service is “innovative,” “integrated,” and “tailored” but never explained;
  • internal company structure dictates the navigation;
  • critical conditions are buried in accordions nobody knows to open;
  • visual effects delay or interrupt the answer;
  • a wall of text contains the truth but gives it nowhere to stand.

  The fix is not automatically shorter copy. A considered purchase may require substantial detail. The goal is decision-ready copy: enough information, in the right order, at the moment the visitor needs it.

  3. Trust: put evidence where doubt appears

  Trust is not a logo carousel hiding near the footer like a witness in protective custody. It is the relationship between a claim and the evidence that makes the claim believable.

  Different claims require different proof:

  Claim	Useful evidence
  “We understand this problem”	Specific diagnosis, process knowledge, useful educational content, and questions that reveal real experience
  “We can do the work”	Relevant examples, credentials, demonstrations, deliverables, team capability, and technical detail where appropriate
  “This creates value”	Bounded case evidence, measurable outcomes with context, customer references, or a defensible economic explanation
  “Working with us is safe”	Clear process, ownership, terms, security/privacy practices, accessibility, realistic expectations, and visible people
  “This is right for you”	Fit criteria, limitations, pricing factors, comparisons, and honest wrong-fit guidance

  Generic praise is weak evidence. “Amazing service!” proves that somebody found an exclamation point. Specific proof explains the situation, work, constraint, and result without pretending correlation is magic.

  Trust also grows through candor. Explain price ranges when defensible. Discuss tradeoffs. Name who is not a fit. Do not hide every objection until a sales call and then act surprised when buyers suspect the website is withholding something.

  Place evidence beside the claim it supports. A testimonial about implementation belongs near implementation risk. A security explanation belongs near sensitive data entry. A case example about a specific industry belongs near that industry. Trust should arrive before the demand for commitment.

  4. Choose: make options understandable, not artificially scarce

  Choice architecture helps people compare realistic paths and select the next one. The goal is not always fewer choices. It is clearer consequences.

  A high-intent visitor may need a direct action such as booking, buying, applying, or requesting a quote. Someone earlier in the decision may need pricing factors, a diagnostic, an example, a comparison, or a useful guide. Those are different states, not failures to click the biggest button.

  Good choice design explains:

  • what each option is;
  • who it is for;
  • what happens next;
  • what commitment it requires;
  • what information is needed;
  • what the person can do if none of the options fit.

  Artificial urgency, fake scarcity, trap navigation, and confirm-shaming can move a short-term click metric while setting fire to trust. Scope Design will not call that optimization. If a tactic makes the visitor feel tricked once they understand it, the “lift” is a loan against the brand.

  Intentional friction can be useful here. A budget range on a consultation form may reduce raw submissions while improving fit. A warning before deleting data is good friction. A clear eligibility question can prevent wasted time on both sides. UX is not the cult of fewer clicks. It is the discipline of less uncertainty and appropriate effort.

  5. Act: remove accidental effort from the real task

  The action is where strategy meets fingers, thumbs, keyboards, screen readers, browsers, networks, forms, calendars, carts, and the occasional plugin that chose violence.

  Test the entire task, not the component in isolation:

  • Can the person find the action?
  • Does the label describe what happens?
  • Are requirements explained before work begins?
  • Are fields necessary for this stage?
  • Do labels, instructions, and errors remain available to assistive technology?
  • Does autofill work where appropriate?
  • Can the action be completed by keyboard?
  • Does the interface work at narrow widths and zoomed text sizes?
  • Does it preserve entered information after a correctable error?
  • Does the confirmation explain what happens next?
  • Does the submission actually reach the responsible person or system?

  The W3C’s web-accessibility design guidance calls for identifiable interactive elements, consistent navigation, associated form labels, useful feedback, logical grouping, and support for different viewport sizes. These are not exotic edge-case requests. They are basic conditions for completing work.

  Performance is part of the action because an interface that arrives late or responds unpredictably changes what people can do. Google’s current Core Web Vitals measure loading with Largest Contentful Paint, responsiveness with Interaction to Next Paint, and visual stability with Cumulative Layout Shift. Google recommends evaluating the 75th percentile rather than treating one fast lab run as universal truth. Our web-development and performance pillar owns the deeper technical work.

  Do not turn these metrics into conversion-rate fortune cookies. They are experience signals. Use field data, segment by device where useful, and connect performance changes to task outcomes in your own context.

  6. Recover: design for errors, hesitation, and real life

  People mistype email addresses. Cards fail. Calendars run out of slots. Eligibility gets complicated. Someone needs a human. A good experience does not punish ordinary uncertainty.

  Recovery includes:

  • specific error messages placed where the error occurred;
  • instructions that explain how to fix the problem;
  • preserved form input;
  • undo where the consequence warrants it;
  • visible alternative contact or support paths;
  • empty states that explain what to do;
  • confirmation pages and emails that set expectations;
  • routing when the visitor chose the wrong path;
  • respectful exits from subscriptions, trials, and accounts.

  The classic Nielsen Norman usability heuristics include visible system status, user control, error prevention, recognition over recall, and help recovering from errors. They remain useful because interfaces still need to communicate what happened and what a person can do next. The technology changed. Human uncertainty did not receive a software update.

  Recovery is also operational. A confirmation that promises a reply within one business day becomes bad UX when nobody owns the inbox. The experience does not end at the button.

  Access belongs across the entire path

  Accessibility is not a widget, an overlay, or a legal paragraph. It is whether people with disabilities can perceive, understand, navigate, interact with, and contribute through the experience. The W3C’s introduction to web accessibility emphasizes that barriers can make a site difficult or impossible to use and recommends evaluating accessibility early and throughout development.

  The WCAG 2 standard provides shared technical requirements for accessible content. Standards are essential, but a checklist alone cannot establish that a real task is usable. W3C describes “usable accessibility” as combining standards, usability practices, and involvement from people with disabilities.

  That means accessibility work should influence:

  • research and participant recruitment;
  • information hierarchy and language;
  • color, contrast, typography, spacing, and zoom behavior;
  • keyboard and alternative-input operation;
  • headings, landmarks, labels, names, roles, and states;
  • images, audio, video, animation, and time limits;
  • forms, errors, authentication, and support;
  • testing, content governance, and regression monitoring.

  Our website accessibility guide covers the standards and evaluation process in more detail. The business point is uncomplicated: if a person cannot use the experience, the experience failed them. A conversion dashboard does not get to vote that person out of the audience.

  A real example: the right UX fix was asking for less

  A fleet-services company wanted the intended job-application action measurable. The obvious project could have become a form redesign followed by campaign tracking.

  Discovery showed a more basic problem: the destination asked applicants for information the business did not need at that stage. The experience created unnecessary burden before the company could responsibly judge advertising performance.

  Scope Design simplified what applicants had to provide and instrumented the intended action. The safe, evidence-backed conclusion is not that a prettier form produced a tidy conversion lift. We do not have records supporting that claim. The conclusion is that the correct UX work was reducing unjustified effort and making the task observable before spending more money to send people into it.

  That distinction matters. “Redesign the form” describes a deliverable. “Help the right applicant complete the appropriate step and let the business measure it” describes the job.

  UX, UI, website strategy, CRO, and development are not interchangeable

  These disciplines overlap, but they ask different primary questions:

  Discipline	Primary question
  Website strategy	What commercial job must the site do, for whom, and how does it fit the business system?
  UX design	Can the intended person understand and complete the job effectively in context?
  UI design	How should the interface visually and interactively express that experience?
  Content design	What information and language help the person decide and act?
  Development	How should the experience be implemented, secured, maintained, and made performant?
  Conversion rate optimization	Which constraint should be changed and evaluated to improve a defined outcome?

  Our conversion rate optimization guide explains how to diagnose and evaluate improvement work. The website conversion checklist checks the complete chain from intent match through operational follow-through.

  Calling all of this “web design” may be convenient, but it hides responsibility. A polished UI can sit on weak strategy. Excellent code can implement a confusing workflow perfectly. Strong copy can lead to a broken form. The customer experiences the whole system, not your org chart.

  How to diagnose UX on a low-traffic business website

  Most small-business sites cannot run statistically persuasive experiments on button colors, headline punctuation, or sixteen tiny layout variations. Pretending otherwise does not create evidence. It creates a spreadsheet wearing a lab coat.

  Low traffic does not mean you cannot learn. It means you should use methods suited to the decision:

  1. Verify the mechanics. Complete forms, bookings, calls, purchases, downloads, authentication, notifications, and CRM handoffs on real devices and browsers.
  2. Run task-based usability sessions. Give representative people a realistic goal. Ask them to think aloud. Observe where they misinterpret, hesitate, backtrack, or fail. Do not coach them through the interface you are trying to evaluate.
  3. Interview customer-facing staff. Sales, service, reception, recruiting, and support hear confusion the analytics platform never will.
  4. Review search and arrival intent. Compare queries, ads, referrals, and email promises with the landing-page answer.
  5. Inspect behavior by stage. Look at entry, scroll, navigation, CTA use, form starts, errors, completions, and downstream quality. Heatmaps can suggest where to investigate; they do not explain motives.
  6. Audit accessibility. Combine automated checks, keyboard review, screen-reader testing, zoom/reflow checks, and human evaluation. Automation catches only what it can detect.
  7. Use before-and-after task measures. Completion, error rate, time on task, abandonment stage, support burden, qualified outcomes, and participant confidence can be more useful than a sitewide conversion rate with a tiny denominator.
  8. Make larger, meaningful changes. When evidence shows that the value proposition is unclear, test a clearer proposition—not a slightly warmer shade of teal.

  For low-volume considered services, one relevant session can expose a severe failure. That does not prove how common the failure is, but it can prove the failure exists. Fixing a broken required field does not need a six-month controlled trial.

  A practical website UX audit sequence

  1. Define the user, task, and context

  Name the intended person, the job they are trying to complete, what they already know, what may limit them, what creates risk, and what happens afterward. “Everyone” is not a useful research participant.

  2. Map the decision path

  For the primary journey, document what the person must recognize, understand, trust, choose, do, and recover from. Mark where accessibility requirements affect each step—which is generally all of them.

  3. Gather evidence from multiple sources

  Use analytics, search queries, form data, sales feedback, support questions, usability observation, accessibility evaluation, performance field data, and content review. No single dashboard gets custody of the truth.

  4. Identify the earliest broken decision

  If people do not recognize the page as relevant, polishing the checkout is premature. If they understand and trust the offer but cannot submit the form, adding more testimonials is decorative procrastination.

  5. Prioritize by harm, reach, confidence, and effort

  Fix blockers and exclusion first. Then address high-reach confusion, repeated abandonment, and expensive operational failures. Keep a record of the evidence behind each priority so the loudest opinion does not become the roadmap.

  6. Change the smallest coherent part of the experience

  Small does not mean cosmetic. A coherent change may include the headline, comparison information, CTA label, form requirements, confirmation, and CRM routing because together they create one decision. Do not split a working idea into meaningless fragments merely to call it testing.

  7. Verify the complete experience

  Review visual rendering, keyboard operation, assistive-technology behavior, forms, errors, responsive layouts, performance, analytics events, notifications, and downstream ownership. Then observe the task again.

  8. Keep learning after launch

  Content changes. Plugins update. staff changes. Offers evolve. Accessibility regresses. UX is governed, not ceremonially completed and mounted above the conference table.

  What should you fix first?

  Use this order unless evidence gives you a better one:

  1. Broken or inaccessible actions.
  2. Security, privacy, safety, or legal-risk failures.
  3. Wrong traffic or severe arrival-message mismatch.
  4. Unclear offer, audience, or next step.
  5. Missing evidence at major moments of doubt.
  6. Navigation, choice, form, and mobile friction.
  7. Error recovery and operational handoff.
  8. Performance problems affecting real users.
  9. Readability, hierarchy, and visual refinement.
  10. Micro-optimization after enough meaningful evidence exists.

  This order is deliberately unglamorous. Business websites rarely fail because nobody found the secret gradient. They fail because people cannot figure out what is happening, do not believe it, cannot complete it, or receive nothing useful after they do.

  Frequently asked questions about website UX and conversions

  Why is my website getting traffic but no sales?

  Traffic without sales can indicate irrelevant visitors, unclear positioning, weak proof, a poor offer, UX friction, technical failure, or a broken sales handoff. Segment traffic by source and landing-page intent, verify the conversion mechanics, then find the earliest point where qualified visitors stop progressing.

  Why are people clicking but not converting?

  The click may promise something the destination does not deliver. Check message match, page speed, mobile rendering, offer clarity, trust, price expectations, CTA meaning, form requirements, errors, tracking, and what happens after submission. A click proves interest in the link, not acceptance of the entire offer.

  What is UX design for a website?

  Website UX design is the process of helping intended users understand, navigate, access, and complete meaningful tasks effectively in their real context. It includes research, information architecture, content, interaction, accessibility, performance, feedback, testing, and continuous improvement—not only visual styling.

  What is the difference between UX and UI design?

  UX concerns the complete experience and whether the intended person can succeed. UI concerns the visual and interactive interface through which part of that experience occurs. UI is one contributor to UX. A beautiful interface can still support a confusing or inaccessible experience.

  What are the most important UX design principles?

  Start with user and task clarity, visible system status, consistency, recognition over recall, error prevention and recovery, accessible operation, appropriate effort, readable hierarchy, and evidence-based iteration. Scope Design organizes a business website around six visitor decisions: Recognize, Understand, Trust, Choose, Act, and Recover.

  What makes a website user-friendly?

  A user-friendly website helps the intended person find relevant information, understand choices, operate controls, complete tasks, and recover from mistakes across devices and abilities. It is predictable where predictability helps, distinctive where character helps, and clear about what happens next.

  How do I know whether my website has bad UX?

  Watch representative people attempt real tasks. Warning signs include early confusion, repeated backtracking, missed navigation, unexplained hesitation, inaccessible controls, mobile failures, form abandonment, unhelpful errors, support questions the page should answer, and sales calls that begin by re-explaining the website.

  How can I improve my website’s user experience?

  Define the primary user and task, map the decision path, verify mechanics and accessibility, observe task attempts, review analytics and staff feedback, identify the earliest failure, make a coherent change, and test the full experience again. Do not begin with trend shopping.

  Does page speed affect user experience?

  Yes. Loading, responsiveness, and visual stability affect whether people can perceive and operate the page. Use field data where available, not only lab scores. Page speed is one part of UX, however; a fast page can deliver the wrong answer with impressive efficiency.

  How does accessibility affect UX?

  Accessibility determines whether people with disabilities can perceive, understand, navigate, and interact with the experience. It affects content, structure, visuals, input, media, forms, errors, and testing. Accessibility standards and usability evaluation should work together.

  What is a good website conversion rate?

  There is no universal useful rate. The answer depends on the action, traffic intent, price, business model, device, channel, qualification, sales process, measurement, and denominator. Compare equivalent cohorts, attach quality to the conversion, and judge whether the result supports the business economics.

  Can a website redesign fix poor conversions?

  It can fix UX, messaging, accessibility, performance, or technical constraints when those are the actual problem. It will not fix irrelevant traffic, an unwanted offer, missing proof the business does not possess, or slow sales follow-up. Diagnose before redesigning.

  How do I test UX on a low-traffic website?

  Use task-based observation, customer and staff interviews, form and error analysis, accessibility evaluation, technical verification, search-intent review, and meaningful before-and-after task measures. Make larger evidence-backed changes instead of pretending tiny A/B tests have statistical authority.

  Should every form have as few fields as possible?

  No. Every field should earn its place at that stage. Remove data that is unnecessary, premature, unsafe, or available elsewhere. Keep fields that protect qualification, routing, safety, consent, or service quality. The goal is appropriate effort, not the shortest form in captivity.

  Stop asking the redesign to diagnose the business

  A serious UX process does not begin with the assumption that the website needs to look different. It begins with a person, a task, a context, and evidence of where the experience breaks.

  Sometimes the right answer is a clearer page. Sometimes it is a different navigation structure, a faster implementation, accessible controls, better proof, fewer form requirements, a more honest choice, or a useful recovery path. Sometimes the website is fine and the follow-up process is the part quietly setting money on fire.

  If you need help determining whether the constraint is traffic, message, UX, technology, offer, measurement, or operations, talk with Scope Design. We will diagnose the path before prescribing another tasteful pile of pixels.

  August 11, 2025

• 

  Website Font Size Guide: Readable, Responsive Type That Works

  Warning: truncated output (original token count: 10449)
  Total output lines: 990

  For most business websites, start body copy around 16–18 CSS pixels on smaller screens and 18–20 pixels when the reading context supports it. Then test the actual typeface, line length, line height, contrast, zoom, language, and device. There is no universally perfect website font size, and WCAG does not prescribe a minimum pixel size for ordinary web content. Sixteen pixels is a practical starting point, not a commandment delivered on a stone tablet by the Department of Fonts.

  TL;DR: practical website font-size recommendations

  • Body copy: start at 16–18px; consider 18–20px for long-form reading, older audiences, low-contrast environments, or typefaces with a small x-height.
  • Form controls and buttons: keep their text comfortably readable and give the control enough space to survive zoom and longer labels.
  • Small supporting text: avoid shrinking important instructions, prices, errors, consent language, or eligibility details into decorative dust.
  • Headings: size them by hierarchy and available space, not by copying a “perfect” scale from a design-inspiration post.
  • Line height: 1.45–1.7 is a useful body-copy starting range, adjusted for the typeface, size, measure, and language.
  • Line length: roughly 45–80 characters can be a useful working range for sustained Latin-script reading; treat it as a design range, not a criminal statute.
  • Units: use a root-relative system such as rem for most typography, while preserving browser zoom and user settings.
  • Accessibility: verify 200% text resizing, reflow at 320 CSS pixels, spacing overrides, contrast, semantic structure, and real task completion.
  • Performance: load only the font files and weights you need, use strong fallbacks, and prevent font swaps from turning the page into a furniture-moving contest.
  • Testing: inspect real content on real devices, at narrow widths, at 200% zoom, with browser text changes, and with people who actually have to read it.

  The number matters. It just does not matter alone.

  Why there is no single best font size for every website

  A CSS font size describes the em box used to lay out type. It does not tell you exactly how large the lowercase letters will look, how wide the words will run, how open the counters are, how heavy the strokes feel, or whether two similar characters can be distinguished.

  Two typefaces set to 18px can look and behave very differently. One may have a generous x-height and wide characters. Another may look delicate, compact, and noticeably smaller. Add weight, letter spacing, screen density, viewing distance, glare, language, browser settings, and a 72-year-old reader trying to use the site on a phone in a parking lot, and the fantasy of one perfect number falls apart quickly.

  Font size also interacts with the width of the text column. Eighteen-pixel text in a 620px reading column may feel calm and readable. The same text stretched across a 1,400px monitor becomes a cross-country eye-tracking exercise. Making it 22px does not fix the badly designed measure; it just creates larger words on the same terrible road.

  That is why a serious typography decision accounts for:

  • the typeface’s actual letterforms and x-height;
  • the reading task and content density;
  • the expected audience and context;
  • line length, line height, paragraph spacing, and alignment;
  • contrast and font weight;
  • responsive layouts and zoom behavior;
  • language, script, and content variation;
  • fallback fonts and loading states;
  • headings, forms, buttons, tables, captions, and error messages;
  • the user’s own browser and operating-system settings.

  The right question is not “What number looks premium?” It is “Can the intended person find, distinguish, read, understand, and use this text in the conditions that matter?”

  The Scope Design Website Type Stack

  Website typography works as a stack. A failure near the bottom contaminates everything above it.

  1. Glyph: Can the reader distinguish individual characters and symbols?
  2. Word: Do the weight, spacing, language shaping, and word forms support recognition?
  3. Line: Do font size, line length, and line height support comfortable tracking?
  4. Block: Can the reader scan, keep their place, and understand paragraph boundaries?
  5. Hierarchy: Do headings, labels, emphasis, links, lists, and captions explain the structure?
  6. System: Does the type survive devices, zoom, user settings, fallbacks, loading, localization, and real content?

  

  This stack prevents a common design mistake: arguing about a headline font while the body copy is too faint, the lines are 120 characters wide, the form errors are 12px gray, and the web font has not loaded yet.

  Typography is interface infrastructure. Brand character matters, but character does not get veto power over legibility, accessibility, or completion. A beautiful typeface that nobody can read is not refined. It is decorative obstruction with a licensing fee.

  A practical website font-size table

  Use these values as starting ranges for common Latin-script business websites, then test the actual implementation.

  Content role	Practical starting range	What to verify
  Body copy	16–20px	sustained reading, x-height, line length, zoom, audience
  Compact UI or navigation	14–17px	clarity, contrast, control size, localization
  Form labels and input text	16–18px	zoom, errors, autocomplete, long labels, mobile input
  Buttons	16–18px	clear action label, weight, spacing, full control size
  Captions and metadata	13–16px	whether the text is genuinely secondary and still readable
  H3	20–28px	distinction from body copy and H2
  H2	26–40px	section hierarchy, wrapping, narrow screens
  H1	36–64px	comprehension, line breaks, viewport fit, actual title length

  These ranges are deliberately broad. A font with a small x-height may need more size. A dense dashboard may require a tighter scale than an editorial article. A short marketing headline can tolerate a larger display size than a 14-word technical heading. A Japanese, Arabic, Devanagari, or multilingual interface cannot be treated as Latin typography with different characters pasted in.

  Start with a defensible system. Then use evidence, not vibes in a turtleneck.

  Body text: start around 16–18px and adjust the whole reading system

  Sixteen pixels remains a useful minimum starting point for many body-copy systems because it aligns with common browser defaults and gives readers a reasonable base. That does not make every 16px design readable. A thin font, faint contrast, long lines, tight leading, and tiny link differences can make 16px fail spectacularly.

  For articles, detailed service explanations, pricing guidance, instructions, and other sustained reading, 18px is often a stronger starting point. Twenty pixels can work well when the typeface, column width, and content support it. Larger text is not automatically more readable either: oversized body copy creates short, choppy lines on narrow screens and can make dense information harder to compare.

  Evaluate body copy as a package:

  • Size: Is the text visibly comfortable without requiring immediate zoom?
  • Measure: Can the eye move from the end of one line to the start of the next?
  • Line height: Do lines feel separated without floating apart?
  • Weight: Do strokes remain visible on real screens and in glare?
  • Contrast: Does the text stand apart from the actual background?
  • Paragraph rhythm: Can the reader identify blocks and changes in thought?
  • Links and emphasis: Are they distinguishable without relying only on color?
  • Content: Does the writing deserve to be read, or is typography being asked to disguise a paragraph that says nothing?

  Our content-readability guide owns the writing and structure side of that last question. Font size cannot rescue corporate fog. It can only make the fog larger.

  Headings: build hierarchy, not a monument

  Heading sizes should reveal the structure of the page. The H1 identifies the main subject. H2s divide major sections. H3s explain subsections. Their HTML levels should represent that structure even when the visual design varies.

  A useful heading system has clear steps between levels, but the ratio does not need to be mathematically identical. Display type often needs optical correction. A very bold font may look larger than the numbers imply. An all-caps label may need different spacing. A long H2 may need a lower maximum size than a short hero headline.

  Use fluid sizing when it improves the transition between narrow and wide layouts:

  :root {
    --font-body: 1.125rem;
    --font-h3: clamp(1.25rem, 1.1rem + 0.7vw, 1.75rem);
    --font-h2: clamp(1.75rem, 1.35rem + 1.6vw, 2.75rem);
    --font-h1: clamp(2.25rem, 1.6rem + 3vw, 4rem);
  }

  clamp() sets a minimum, a fluid preferred value, and a maximum. MDN’s clamp documentation explains the function and its use for font sizing. The minimum and maximum still need to work with real titles. “Our Services” and “What Separates a Basic Website From a Serious Business Website?” are not the same layout problem.

  Avoid pure viewport-unit typography such as font-size: 5vw with no floor or ceiling. It can become microscopic on small screens, absurd on large ones, and hostile to user zoom. The W3C’s Resize Text guidance specifically identifies incorrect viewport-unit resizing as a common failure risk.

  Form labels, buttons, errors, and the text businesses love to shrink

  Typography becomes operational when a person must complete something.

  Labels, required-field instructions, input values, validation messages, prices, eligibility rules, shipping details, consent text, and confirmation messages are not decorative supporting actors. They determine whether somebody can finish the task and whether the business receives usable information.

  Do not shrink legally or operationally important text because the layout “feels cleaner.” Clean for whom? The person who designed the comp at 150% scale on a 32-inch monitor?

  For forms and controls:

  • keep labels visible rather than relying on disappearing placeholder text;
  • use readable text inside inputs, selects, date pickers, and buttons;
  • give errors enough contrast and space to wrap;
  • pair color changes with text, icons, or other understandable signals;
  • allow labels and controls to grow at 200% without clipping;
  • test long names, addresses, translated labels, validation details, and autofill;
  • make the entire control appropriately sized, not just the letters inside it;
  • state what happens after submission.

  The Scope Design UX pillar places typography inside the complete decision path. People must recognize, understand, trust, choose, act, and recover. Tiny errors and clipped labels break the path even if the homepage headline is magnificent.

  Line length: control the reading distance

  Line length is also called measure. For sustained Latin-script reading, roughly 45–80 characters per line is a useful working range. Shorter lines can suit compact instructions or narrow interfaces. Longer lines may work in tables, code, or specialized layouts where two-dimensional relationships matter.

  The important test is whether readers can track the line comfortably and return to the correct starting point. The U.S. Web Design System explains that controlling line length helps attention move naturally from one line to the next. WCAG’s Visual Presentation criterion, which is Level AAA, includes a mechanism for limiting blocks of text to 80 characters or glyphs, or 40 for CJK scripts.

  Do not misstate that AAA criterion as a universal AA requirement. It is useful design guidance and an accessibility outcome to understand, not permission to write a fake legal rule.

  A practical CSS limit:

  .article-copy {
    max-inline-size: 68ch;
  }

  The ch unit is based on the advance measure of the “0” glyph, so it is an approximation rather than a precise character counter. That is fine. The goal is a readable column, not a forensic investigation into line 37.

  Line height and paragraph spacing: give the text somewhere to breathe

  Body-copy line height often lands between 1.45 and 1.7. Larger display headings commonly need tighter leading because the letters already occupy more visual space. Small text, long lines, or typefaces with tall ascenders and descenders may need more.

  Avoid fixed pixel heights on text containers. They are a reliable way to clip translated, zoomed, or user-spaced text.

  WCAG 2.2 Text Spacing does not require every website to ship with a 1.5 line height, 2em paragraph spacing, 0.12em letter spacing, and 0.16em word spacing. It requires content to survive when a user overrides the author’s presentation to those values without losing content or functionality. That distinction matters.

  Use unitless line height so it scales with the element’s font size:

  body {
    font-size: 1.125rem;
    line-height: 1.6;
  }
  
  p + p {
    margin-block-start: 1em;
  }

  Then test overrides. Do headings collide? Do buttons clip? Do cards with fixed heights eat their last line? Does a navigation label disappear? Accessibility testing is where elegant little boxes meet actual words.

  Alignment, emphasis, and scanability

  For left-to-right languages, left-aligned body text is usually easier to scan than fully justified text. Full justification changes word spacing and can create visible rivers through paragraphs. Centered text can work for short headings or compact statements; it becomes tiring for long copy because every line begins in a different place.

  Use bold weight selectively to create emphasis. If everything is bold, the page has no hierarchy; it merely sounds like it is shouting from several rooms at once.

  Avoid long passages in italics, all caps, or condensed display faces. They can work as accents, labels, or brand moments, but sustained reading needs distinguishable, familiar forms and enough spacing.

  Underline links in body copy or provide another strong, consistent cue beyond color alone. A beautiful muted blue that nobody recognizes as interactive is not subtle. It is hiding the exit.

  Accessible font size: what WCAG and the ADA actually require

  Neit…449 tokens truncated…ch as headings and lists also needs programmatic structure.

Sixteen pixels is a sensible baseline recommendation for many websites because it gives the design a fighting chance. It is not proof of conformance. A 16px sentence can still fail through weak contrast, clipping, poor reflow, inaccessible structure, or a container that breaks when the user changes spacing.

Our website-accessibility guide covers the broader evaluation process. Typography is one part of access, not the entire legal department compressed into a font-size dropdown.

Is 12px too small for a website?

For important body copy, instructions, labels, form input, prices, and error messages, 12px is usually too small to use as the default. It creates unnecessary difficulty for many readers and leaves little room for imperfect screens, viewing distance, glare, low vision, or a typeface that renders small.

Twelve pixels can appear in genuinely secondary metadata or dense specialist interfaces if the context supports it, contrast is strong, zoom works, and users are not forced to decode essential information at that size. Even then, ask why it must be 12px. “The card component is too short” is a layout confession, not a user need.

If the information changes a decision, establishes a requirement, explains an error, or protects the user, do not hide it in mouse-print and congratulate the layout on its cleanliness.

Serif, sans serif, and the myth of the morally superior typeface

Serif and sans-serif typefaces can both be highly readable. Legibility depends more on the specific design, size, weight, spacing, contrast, rendering, language, and context than on the presence of serifs alone.

Choose a body typeface with:

• open, distinguishable letterforms;
• clear differences among characters such as I, l, and 1;
• enough weights for the hierarchy without loading a small family reunion;
• useful punctuation, symbols, numerals, and language coverage;
• strong rendering at the sizes and platforms that matter;
• fallback metrics that can be matched reasonably;
• a license and delivery method the organization can maintain.

Use display faces where their personality helps recognition and brand character. Keep them out of sustained reading when their novelty slows decoding.

Font psychology is often presented as a lookup table: serif equals trustworthy, geometric sans equals modern, script equals luxury. Context and learned association can influence perception, but those tables are not universal laws. The same typeface can feel established on a financial report, theatrical on a restaurant menu, or dated on a software product. Meaning comes from the complete visual and verbal system.

Do not ask the typeface to perform brand strategy alone. That is an unreasonable amount of emotional labor for a set of glyphs.

Is there a dyslexia-friendly font?

There is no single typeface guaranteed to work best for every person with dyslexia. Specialized fonts may help some readers and make little difference for others. Familiarity, letter distinction, spacing, line length, contrast, layout, language, and user control all matter.

Build flexibility instead of declaring a mascot font:

• choose distinguishable letterforms;
• avoid long italic or all-cap passages;
• use clear headings and short, meaningful sections;
• allow zoom and spacing changes;
• avoid justified paragraphs;
• keep line lengths manageable;
• preserve browser and operating-system preferences;
• test with people who use the experience.

Accessibility is not accomplished by installing a font called “Accessible” and going home early.

Responsive typography: adapt the system, not just the number

Mobile type should not automatically be smaller than desktop type. The screen is narrower, the device may be closer, the context may be shakier, and the reader may be dealing with glare or motion. Those factors push in different directions.

A responsive type system adapts:

• font size within sensible limits;
• column width and margins;
• heading wrap and line breaks;
• navigation and control layout;
• table and code presentation;
• spacing around sections;
• the amount and order of secondary information.

The W3C Reflow criterion explains why people should not have to scroll back and forth to read ordinary text at the 320 CSS-pixel equivalent. A responsive layout benefits mobile users and people who zoom a desktop viewport.

Do not disable zoom. Do not use fixed heights around live text. Do not shrink headings until they technically fit while destroying the hierarchy. Let text wrap. Rewrite a bad label when necessary. Change the layout before blaming the reader’s settings.

Web-font performance: the text has to arrive

Web fonts can delay text rendering, affect Largest Contentful Paint, and create layout shifts when the fallback and final fonts occupy different space. web.dev’s font best practices covers the relationship among font loading, delivery, rendering, and Core Web Vitals.

Use a small, intentional font set:

• load only the families, styles, weights, and character sets the site uses;
• prefer WOFF2 for modern delivery;
• subset carefully when language coverage is known and maintained;
• self-host when it improves control and the licensing permits it;
• preload only fonts needed immediately—preloading everything is just moving the traffic jam;
• use font-display deliberately;
• provide a fallback stack;
• match fallback metrics where practical to reduce layout shift;
• cache font files with appropriate versioning;
• test the first visit, not only a warm-cache victory lap.

MDN documents font-display and its values. swap displays fallback text quickly and swaps when the web font arrives, but the swap can move the layout if metrics differ. optional can avoid a late swap under some conditions, but it may mean the custom font does not appear during that visit. Choose based on the content and brand dependency.

@font-face {
  font-family: "Scope Sans";
  src: url("/fonts/scope-sans-regular.woff2") format("woff2");
  font-style: normal;
  font-weight: 400;
  font-display: swap;
}

Our web-development and performance pillar owns the deeper delivery work. The typography rule is simple: text that remains invisible is not on brand, and text that jumps after the visitor starts reading is not particularly gracious.

A practical CSS typography foundation

This is a starting system, not drop-in proof of accessibility:

:root {
  font-size: 100%;
  --text-body: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
  --text-small: 0.875rem;
  --text-h3: clamp(1.25rem, 1.1rem + 0.7vw, 1.75rem);
  --text-h2: clamp(1.75rem, 1.35rem + 1.6vw, 2.75rem);
  --text-h1: clamp(2.25rem, 1.6rem + 3vw, 4rem);
  --measure-reading: 68ch;
}

body {
  font-family: "Scope Sans", system-ui, sans-serif;
  font-size: var(--text-body);
  line-height: 1.6;
}

main p,
main li {
  max-inline-size: var(--measure-reading);
}

h1 {
  font-size: var(--text-h1);
  line-height: 1.05;
}

h2 {
  font-size: var(--text-h2);
  line-height: 1.15;
}

h3 {
  font-size: var(--text-h3);
  line-height: 1.25;
}

small,
.meta {
  font-size: var(--text-small);
}

Why these choices:

• 100% respects the browser’s root-size baseline.
• rem-based values create a coherent root-relative scale.
• clamp() lets selected sizes respond within tested limits.
• unitless line height inherits proportionally.
• ch constrains sustained reading measure.
• system fallbacks make text available while the brand font loads.

Then comes the part people skip: test it with the actual theme, content, languages, browser settings, components, and devices. CSS copied from an article does not know what your navigation does in German.

How to test website typography

Use this sequence:

1. Read the page at 100% without designer context. Can you identify the subject, hierarchy, important details, links, and next action?
2. Check representative devices and browsers. Include a narrow phone viewport, a common laptop, and a larger display.
3. Zoom text to 200%. Look for clipping, overlap, hidden controls, lost labels, and broken navigation.
4. Check reflow at 320 CSS pixels. Ordinary content should not require back-and-forth scrolling.
5. Apply WCAG text-spacing overrides. Confirm that content and controls remain available.
6. Test contrast using the actual foreground, background, weight, and state.
7. Turn off the web font or throttle the network. Confirm that fallback text appears and the final font does not cause disruptive shifts.
8. Try real titles, errors, prices, addresses, names, and translations. Placeholder Latin is an unusually cooperative customer.
9. Use keyboard and assistive technology. Visual hierarchy should align with semantic structure.
10. Observe representative readers. Ask them to complete realistic tasks and explain where they hesitate.

The website-strategy pillar explains why the task and business context come before the deliverable. Typography testing should connect to a real job: understand a service, compare options, complete an application, read instructions, or recover from an error.

Do not declare a typography win because the homepage looks nicer in a presentation. Verify that people can use it.

Frequently asked questions about website font size

What is the best font size for a website?

Start body copy around 16–18px and increase it when the typeface, reading task, audience, or environment needs more. Evaluate size with line length, line height, weight, contrast, zoom, and device context. There is no universal best number.

Is 16px always the correct body font size?

No. Sixteen pixels is a practical baseline for many websites, not a guaranteed optimum or legal requirement. Some typefaces look small at 16px; sustained reading or older audiences may benefit from 18–20px. Dense interfaces may use smaller supporting text while preserving readability and zoom.

Is 12px too small for a website?

It is usually too small for essential body copy, labels, instructions, errors, pricing, and consent language. It may work for genuinely secondary metadata in a carefully tested context, but important information should not be hidden at 12px to protect a cramped layout.

What font size does WCAG or the ADA require?

WCAG does not specify a universal minimum pixel size for ordinary web text, and the ADA does not provide a magic website-font number. WCAG requires outcomes including sufficient contrast, 200% text resizing, reflow, and resilience to text-spacing overrides.

What is an accessible font size?

An accessible size is large enough for the intended readers and works as part of a system that supports contrast, zoom, reflow, spacing changes, clear structure, and user preferences. Sixteen pixels is a common baseline, but accessibility cannot be proved by font size alone.

Should mobile text be smaller than desktop text?

Not automatically. Mobile screens are narrower and often used in glare, motion, or distracted conditions. Body text may remain the same size while the column, spacing, headings, and layout adapt. Test the complete reading experience instead of applying a desktop-minus-two-pixels formula.

Should website font sizes use px, em, or rem?

rem is a strong default for a consistent root-relative type system, while em is useful when a component should scale from its local context. CSS pixels can still participate in accessible designs because browser zoom scales them, but fixed assumptions around text and containers can break user resizing. Test outcomes rather than treating one unit as holy.

What line height should website body text use?

About 1.45–1.7 is a useful starting range for many body typefaces. Adjust for font design, size, line length, language, and content density. Use unitless line height and verify that user spacing overrides do not clip or overlap content.

How long should a line of website text be?

Roughly 45–80 characters is a useful range for sustained Latin-script reading. The best measure depends on font size, typeface, line height, language, and task. Control the reading column and watch whether readers can return to the next line comfortably.

How many fonts should a website use?

Use as few families and weights as the hierarchy genuinely needs. One well-designed family can handle an entire site. Two can create useful contrast between display and reading roles. More families add visual complexity, files, maintenance, and opportunities for the page to resemble a ransom note.

Are serif or sans-serif fonts more readable?

Both can be readable. The specific letterforms, size, weight, spacing, contrast, rendering, familiarity, and context matter more than the category alone. Test the actual typeface with the actual audience and content.

Is there one dyslexia-friendly font?

No single font works best for everyone with dyslexia. Distinguishable letterforms, manageable line length, clear structure, spacing, alignment, zoom, and user control are more responsible than claiming a specialized font solves dyslexia universally.

Do web fonts hurt page speed or SEO?

They can delay rendering, affect Largest Contentful Paint, and create layout shifts if poorly delivered. Search visibility is affected indirectly when performance and usability suffer. Limit files and weights, use WOFF2, strong fallbacks, suitable caching, and an intentional font-display strategy.

How should headings scale?

Headings should create an obvious hierarchy and fit real content at narrow and wide widths. Use tested minimum and maximum sizes, often with clamp(), and adjust line height as headings grow. Do not rely on a universal ratio or pure viewport units.

How do I test website typography?

Test real pages at 100% and 200% zoom, at the 320 CSS-pixel reflow equivalent, with WCAG spacing overrides, real devices, slow font loading, fallback fonts, long content, translations, keyboard navigation, assistive technology, and representative users performing actual tasks.

Make the words usable before calling the site beautiful

Website typography is not a finishing touch. It decides whether the message can be perceived, scanned, understood, and used.

Start with a practical size. Build the glyphs, words, lines, blocks, hierarchy, and system around real readers. Preserve user control. Load the type responsibly. Test the ugly edge cases. Then give the brand a voice people can actually read.

If your typography looks expensive but behaves like a tiny gray obstacle course, talk with Scope Design. We will fix the reading system, not merely make the font picker feel important.