Designing for Real People

Imagine two websites for the same small business. One opens with sweeping animations, tiny gray text, and a clever menu nobody can find. The other loads promptly, explains what the business does, and makes the phone number, prices, and next step obvious.

Which one is better designed? The answer depends on what its visitors can actually accomplish. A dramatic homepage might win a first impression and still lose the customer who cannot find the hours, use the checkout, or read the text.

For anyone comparing web design in Fort Smith, Van Buren, or Sallisaw, this is a more useful question than “Does the website look expensive?”: Can a real person use it without needing instructions? You do not need to be a designer to ask it.

In this chapter, you will learn to separate appearance from usability, check a site on mobile, understand the basics of accessibility, interpret speed metrics, and test a website before approving the final invoice.

Design is not decoration

Visual design matters. Color, typography, spacing, photography, and personality can make a business recognizable. But usability asks another question: can visitors understand what is happening, find what they need, and complete a task without confusion?

A striking website is not automatically usable. A plain website is not automatically good. The best result combines an appropriate appearance with a clear path for the people it serves.

Usability specialists use principles such as consistency, recognition rather than memory, visible feedback, and prevention of avoidable mistakes. These are established design heuristics, not a magic formula that guarantees every visitor will succeed.^[1]

These are illustrative comparisons, not scores from an audit. The useful test is not whether a page follows a fashionable style. It is whether the people who visit understand and trust the next step.

A design can be intentionally confusing

Not every confusing interface is an accident. The U.S. Federal Trade Commission describes manipulative design practices, often called dark patterns, including disguised advertising, buried charges, difficult subscription cancellation, and choices that push users toward sharing information they did not intend to share.^[2]

A visitor should be able to tell what a button does, what a purchase costs, whether a subscription renews, and how to decline an optional offer. If the “No thanks” option is nearly invisible while “Accept” fills the screen, ask why. That is not a measure of sophisticated design.

Make the next step obvious

Start with the visitor’s task. A site owner may want to show every product, award, photograph, and announcement at once. A visitor might only want to find out whether the business is open on Saturday.

A practical information hierarchy puts the most useful information first. Good headings tell visitors what is in each section. Consistent navigation reduces the need to relearn a website on every page. The Nielsen Norman Group's usability heuristics support matching the interface to familiar expectations and keeping the experience consistent.^[1]

Try the five-second explanation as a simple editorial exercise, not a scientific pass/fail test: show someone the homepage briefly and ask, “What does this business do, and where would you go next?” If they cannot answer, investigate the headline, navigation, and visual priorities.

Useful defaults include:

• A plain-language statement of the product, service, or purpose near the top.
• Familiar menu labels such as Services, Shop, About, and Contact, when those match the site.
• Readable section headings and generous enough spacing to separate topics.
• Obvious links and buttons with words that describe their destinations.
• Contact, pricing, hours, or location details where visitors expect them.
• Predictable feedback after submitting a form, adding an item, or changing a setting.

You do not need to hide half the site behind an elaborate animation just to make it feel premium. Sometimes an ordinary “Call us” link is the most useful thing on the page.

Build for phones, not just desktops

A responsive site changes its layout to suit different screen sizes. A mobile-first design process starts with the constraints and priorities of smaller screens, then expands the layout for wider screens. A website can be responsive without having been thoughtfully designed for phones.

Google's responsive design guidance emphasizes fitting content into the viewport rather than forcing people to pan sideways or zoom out to see a page.^[3]

What a phone exposes

On a desktop, a three-column product grid may look spacious. On a phone, the same design can make the text tiny, squeeze buttons together, and push essential information far below the first screen. A mobile layout should not simply be a miniature desktop layout.

Check that:

• Menus open reliably and have recognizable names; a menu icon alone should not hide the only path to critical information.
• Text is comfortably readable at its ordinary size and remains usable when enlarged.
• Buttons, close controls, and links are large enough and far enough apart to tap intentionally.
• Images fit without cutting off important content or creating horizontal scrolling.
• Forms present labels, relevant field types, clear errors, and a manageable number of steps.
• Checkout shows the important order details, totals, and payment step without surprise distractions.

A useful technical reference: WCAG 2.2 Level AA's target-size criterion generally specifies a pointer target of at least 24 × 24 CSS pixels, with defined exceptions including sufficient spacing. It is a minimum with exceptions, not a promise that every 24-pixel button is comfortable to tap. Larger targets are often a better design choice.^[4]

Responsive and accessible are not synonyms

A mobile page might fit the screen but still trap keyboard users, use poor contrast, or block text resizing. A mobile-first process helps prioritize information, but it cannot replace accessibility work or real testing.

Accessibility is part of the design

Accessibility means that people with different abilities can perceive information, navigate, understand controls, and complete meaningful tasks. It is not only about screen readers, and it is not a decorative menu added at the end of a project.

The Web Content Accessibility Guidelines (WCAG) organize accessibility around four ideas: content should be perceivable, operable, understandable, and robust enough to work with the tools people use.^[5]

Here is what that means on an ordinary small-business website.

Contrast, color, and readable text

Light gray words on a white background may fit a visual theme, but they can also be hard to read. Under WCAG 2.2 Level AA, the usual minimum contrast ratio for normal text is 4.5:1; for large text it is 3:1, subject to defined exceptions. Certain meaningful user-interface indicators and graphics also have a 3:1 non-text contrast requirement.^[6][7]

Color should not be the only way an error or status is communicated. For example, “The email address is missing” beside a field gives more information than turning its border red. Avoid relying on color alone to distinguish important links or choices.^[8]

Keyboard and focus

Put the mouse aside and press Tab. Can you tell where you are? Can you reach the menu, buttons, dialogs, and form fields? Can you move backward with Shift + Tab, activate controls, and escape any open dialog? WCAG requires keyboard-operable functionality and a visible focus indication for keyboard operation.^[9][10]

If you cannot see the active control, a visitor who navigates by keyboard has a much harder time. Keep a clearly visible focus indicator. If you replace the browser's default outline, make sure the replacement remains easy to see.

Headings, menus, and screen readers

Headings should describe real sections, not merely look big. Proper heading levels and semantic markup help assistive technologies understand the page. Navigation built with meaningful lists and links can adapt to small screens and other browsing methods.^[11][12]

Use real links for navigation and real buttons for actions. The words on a control should explain what it does. These choices are invisible to most sighted visitors but fundamental to how a site works.

Images, forms, and feedback

Meaningful images need equivalent text, sometimes called alt text. Decorative images usually do not need a spoken description. The correct description depends on what the image contributes in context, not on filling every image field with keywords.^[13]

Forms need labels that remain available when someone starts typing. Error messages should identify the actual problem and, when possible, explain how to fix it. W3C explains how to associate labels with their form controls; GOV.UK design guidance recommends specific error feedback.^[14][15]

Motion and zoom

Some visitors are distracted or physically affected by animation. Avoid unnecessary movement, honor the operating system's reduced-motion preference where relevant, and provide controls to pause or stop moving content when the applicable criteria require them. WCAG's animation-from-interactions criterion is Level AAA, while other motion-related requirements may apply at lower levels.^[16]

Except for captions and images of text, text should be usable when enlarged to 200% without losing content or function. WCAG's reflow criterion addresses avoiding two-direction scrolling at widths equivalent to 320 CSS pixels for ordinary vertical content, with exceptions for content that truly needs two dimensions, such as certain tables and maps.^[17][18]

Understand WCAG without becoming an expert

WCAG 2.2 is a W3C technical standard for accessible web content. Its success criteria have three levels. Meeting a higher level means meeting the lower levels too; it is not a menu where a designer can choose whichever individual checks are convenient.^[5][19]

A claim such as “WCAG 2.2 AA compliant” is a claim about the full page and its relevant states, not just its homepage screenshot. Ask what was actually reviewed, which pages and workflows were included, and what limitations the reviewer found.^[19]

What an automatic scan can do: identify some common problems, such as certain missing labels, detectable contrast issues, or markup errors.

What it cannot do: reliably decide whether an image description conveys the right meaning, whether a purchase is understandable, whether keyboard use is genuinely manageable, or whether the entire website meets a conformance level. W3C warns that accessibility evaluation tools cannot determine accessibility by themselves; human judgment is required.^[20]

A score from a scanner is evidence of what that scanner checked, not a legal certificate.

What accessibility law does and does not say

Accessibility standards, legal duties, and good design practices overlap, but they are not interchangeable.

For U.S. businesses open to the public, the Department of Justice explains that the Americans with Disabilities Act applies to accessibility of websites and online services in relevant circumstances. That guidance should not be converted into an unsupported claim that every private small-business website is legally required to meet WCAG 2.2 AA. The precise obligation depends on the law, the organization, and the facts.^[21]

For state and local governments, a separate federal ADA Title II web-and-mobile-app rule generally adopts WCAG 2.1 Level AA, not WCAG 2.2 AA. As described in the DOJ's updated 2026 guidance, covered government entities with populations of at least 50,000 generally have an April 26, 2027 compliance deadline; smaller governments and special districts generally have an April 26, 2028 deadline. Exceptions and other ADA duties matter, and this rule is not a blanket deadline for private retailers or restaurants.^[22]

For a small-business owner: do not buy a “100% ADA-proof” badge or accept a promise that installing an accessibility widget settles every issue. Ask what standard was used, what manual testing was performed, which barriers were fixed, and what remains to be checked. When legal compliance is a concern, get qualified legal advice relevant to the business; this chapter is consumer education, not a legal opinion.

Make reading and thinking easier

People do not all read or process a website in the same way. A crowded page can demand extra attention and memory. Dense wording, inconsistent controls, motion, and unclear next steps may create particular barriers for visitors with ADHD, dyslexia, other learning or cognitive disabilities, reading difficulties, or sensory sensitivities.^[23]

The W3C's cognitive accessibility guidance recommends familiar patterns, clear page purpose, logical structure, understandable wording, and reducing unnecessary memory demands. It also notes that some useful cognitive-accessibility guidance goes beyond WCAG's testable success criteria.^[23]

A practical foundation is straightforward:

• Use descriptive headings, short sections, and direct language.
• Keep one primary action prominent where that makes sense.
• Break complicated tasks into understandable steps with clear progress and recovery options.
• Group related controls; do not make people remember information from another screen unnecessarily.
• Avoid moving backgrounds, flashing attention-grabbers, and unexpected sound.
• Do not make important information available only through a video, image, or tooltip.
• Let visitors enlarge text and use their preferred browser and operating-system settings.

Should a website offer an ADHD mode or dyslexia mode?

Optional preferences can be helpful: a quieter layout, fewer animations, wider spacing, or a familiar readable font might improve the experience for some visitors. But nobody should be forced into a special mode to read a properly designed website.

Do not assume a single “ADHD layout” or “dyslexia font” will suit every visitor. Offer choices and ask people what helps them. A feature called “dyslexia mode” should not imply that it treats dyslexia or guarantees better reading. A simple name like Reading preferences or Accessibility preferences may describe the controls more accurately.

The sensible order is accessible defaults first, optional personalization second. Offer settings that can be turned on and off, avoid surprising changes to navigation, and verify that every setting still supports keyboard access, contrast, zoom, and readable text. Ask actual users whether the preference helps rather than assuming it does.^[23]

Make the site feel fast and stable

Speed is not an abstract developer trophy. People notice when a picture takes a long time to appear, a button seems unresponsive, or the layout jumps just as they try to tap a link.

Google's Core Web Vitals measure three aspects of that experience. The following are Google's “good” thresholds, evaluated at the 75th percentile of page visits, separately for mobile and desktop when field data are available.^[24]

A lab tool such as Lighthouse can help diagnose problems during development. Real-user or field measurements describe visits under different actual conditions. Do not treat one lab run as a guarantee of what every customer experiences.^[25]

What to improve first

Common practical improvements include optimizing large images, reserving space for media so the page does not jump, limiting unnecessary animations and heavy scripts, and keeping important buttons usable while other content loads. The right fixes depend on what was measured.

Google states that its ranking systems use Core Web Vitals, but good reports or a perfect Lighthouse score do not guarantee high rankings. Relevance, content, and other factors also matter.^[26]

When reviewing a contractor's work, ask for the actual tested page, device category, test date, tool, and conditions, not just a cropped screenshot of a green number. If a designer quotes a speed improvement, ask what changed and how it was measured.

Design around the visitor's actual job

Different businesses need different starting points. A visitor trying to order dinner has different questions from someone trying to schedule a roof repair. These examples are hypothetical, not reviews of real companies in Arkansas or Oklahoma.

A restaurant in Fort Smith should not need a labyrinth of promotional pages to show its hours. A Van Buren contractor might care more about clear service-area details and completed work than a cinematic hero. A Sallisaw shop might need a simple product-and-contact experience rather than an expensive custom checkout. These are editorial examples of visitor intent, not claims about named businesses or local search behavior.

Where a good professional adds value

Hiring a qualified designer or developer can be worth the money. A professional may help research actual customer tasks, organize complicated information, implement accessible interactions, test mobile workflows, improve performance, integrate commerce systems, and support the site as needs change.

The value is not necessarily how many effects they can add. It is whether they can explain their choices, show meaningful tests, identify remaining limitations, and hand over something the owner can maintain. Conversely, a carefully chosen low-cost template can be excellent for a straightforward website. Complexity should have to earn its place.

Test the website before you pay

You can perform a useful first review without being a programmer. Use a real phone if possible and ask someone who has never seen the site to try one or two natural tasks. Observing realistic users attempt tasks is a standard usability-testing method, although an informal review is not a substitute for a controlled study.^[27]

Ten practical checks

• Understand the homepage: Can someone unfamiliar with the business explain what it offers and identify the next step?
• Find the essentials: Can you locate hours, address, service area, contact information, price or quote process, and key policies as applicable?
• Try a phone: Does the navigation work, does content fit, and can you read it without zooming just to compensate for tiny text?
• Put away the mouse: Use Tab, Shift + Tab, Enter, Space, and Escape as appropriate. Can you reach and use controls and see focus?
• Enlarge the page: Try 200% text enlargement and high zoom. Is important content still available without overlap or unusable sideways scrolling?
• Check contrast and meaning: Are words readable, controls distinguishable, and errors understandable without depending only on color?
• Inspect images and labels: Do meaningful images have appropriate descriptions and form fields have lasting, clear labels?
• Complete the main task: Submit a test inquiry, use a demo checkout or staging payment flow, or complete the site's central interaction without triggering a real purchase.
• Review loading and movement: Test more than the homepage. Look for slow responses, unexpected layout jumps, and motion with no pause/reduction option.
• Ask an unfamiliar user: Give them a realistic goal, avoid coaching, observe where they hesitate, and record what needs fixing.

W3C offers a free Easy Checks guide for an introductory accessibility review. It explicitly warns that these checks are not complete proof of accessibility.^[28]

A simple acceptance exercise

Before you approve an invoice, write down three real tasks that matter to the business. For example: “Find today's hours,” “Request an estimate,” and “Check shipping and returns.” Then have an unfamiliar person attempt them on a phone and another available device. Record whether they succeeded, where they got stuck, and what the designer changed afterward.

A test that finds a problem is useful. A test with no recorded setup, outcome, or limitations is not proof of perfection.

Questions to ask a designer

A good conversation before signing a contract can prevent an expensive disagreement after launch. Ask:

1. Who is the primary visitor, and what three tasks are we designing around?
2. Can you show the mobile version and demonstrate the complete contact or checkout flow?
3. What accessibility standard and level are you targeting, and what does your testing include?
4. Will someone test keyboard navigation, screen-reader use where relevant, resizing, forms, and important workflows?
5. How will you show performance results, including which pages and devices were measured?
6. What happens when a visitor encounters an error, including after launch?
7. Can we review real task outcomes and fix important problems before final acceptance?
8. Who controls the domain, hosting, content, and access after the project ends?
9. What is included in ongoing fixes, maintenance, and new-feature requests?

No single list replaces a contract. The point is to turn vague claims such as “modern,” “SEO optimized,” and “fully accessible” into concrete deliverables with a scope, evidence, and responsibility.

For more on ownership and costs, start with the Pocketbook directory. The editorial standards explain how this series approaches claims and evidence.

The bottom line

Good website design helps the visitor complete the job they came to do. An attractive look can support that goal. It cannot substitute for understandable navigation, legible content, accessibility, functional mobile workflows, and trustworthy behavior.

Before paying for a website, ask the designer to show how it works, not just how it looks. If the visitor can find, understand, and accomplish what matters, the design has earned its place.