Web Design Best Practices for Business Websites (2026)

Short answer: a business website in 2026 is judged in the first phone screen. Put the offer, the proof and the button there, write half the words you think you need, keep body text at 16 pixels or larger with 4.5 to 1 contrast, use motion only in response to a tap, and meet the WCAG 2.2 Level AA floor. Each rule below has a measurable threshold and a source.

How should a home page be structured?

The home page answers four questions in order: what is this, is it for me, can I trust it, what do I do next. On a phone that is 5 or 6 screens of scrolling, so the order is the design.

Recommended block order:

1. Headline and support line: who you serve and what you do, with the first WhatsApp or enquiry button beside it.
2. Proof: 3 figures or names a buyer can check, such as years operating, licences, client count or a known project.
3. Services: 3 to 6 cards, each linking to its own page.
4. How it works: 3 or 4 numbered steps from first contact to delivery.
5. Pricing or starting price. A range beats silence; buyers who cannot see a number leave to find one.
6. One or two client quotes with names and companies, if you have permission to use them.
7. Contact block: WhatsApp, phone as a tap-to-call link, address, hours, UEN.

Rules that hold across industries:

• One primary button per screen. Two competing buttons split the click.
• Navigation of 5 to 7 items. Everything else goes in the footer.
• No slideshow in the hero. Visitors see one slide; the rest cost load time.
• The phone layout is approved before the desktop one, per the mobile-first guide.

Service pages follow the same shape with the service in the headline, the outcome in the proof and the price range before the FAQ.

How much text should a page have?

Less than a brochure, more than a slogan. Nielsen Norman Group's reading study found 79% of test users scanned every new page and 16% read word by word, and recommended roughly half the word count of print writing. Later eye-tracking of 232 users showed the F-shaped scanning pattern: two horizontal passes near the top, then a vertical scan down the left edge.

What that means in practice:

• Lead with the answer. The first sentence of each section carries the conclusion.
• A subheading every 100 to 150 words, written as the fact it covers, not a tease.
• Paragraphs of 1 to 3 sentences. Bullets for any list of 3 or more items.
• Numbers instead of adjectives: "14 days" not "fast", "S$2,000" not "affordable".
• Front-load the left edge. The first 2 words of a heading or bullet are what the scan catches.

Word count guides by page type, from our own build practice rather than a published study: home page 300 to 600 words, service page 500 to 900, article 900 to 1,400. Longer pages are fine when every section answers a distinct question. The same structure serves AI search, which extracts facts from headings and the sentences directly under them; see SEO and AI search.

Which colours and fonts read well on phones?

Phones are read outdoors, at arm's length, often at 50% brightness. The thresholds below come from WCAG 2.2 and Google's Lighthouse audits.

Design choices that meet them without effort:

• One brand colour for buttons and links, one dark text colour, one background. Grey text on white is the most common contrast failure; test it.
• Two typefaces at most. System fonts or one web font with 2 weights load faster than 4 weights of a display face.
• Line length of 45 to 75 characters on desktop; phones handle this by default.
• Line height of 1.5 for body text.
• Dark mode is optional. If offered, test every colour pair again.

Check contrast with any free checker before approving the palette, not after the site is built.

Do animations help or hurt?

Motion helps when it confirms an action and hurts when it delays content. Three rules keep it on the right side.

• Motion follows a tap or scroll. A menu that slides open, a button that depresses, a form that confirms. Autoplaying hero animation and parallax backgrounds add weight and show nothing new.
• Motion is short. 150 to 300 milliseconds for interface feedback. Anything over 500 milliseconds reads as lag.
• Motion respects the reduced-motion setting. iOS, macOS and Android expose a system setting that the browser passes to the site as prefers-reduced-motion. web.dev documents vestibular disorders that make large movement cause dizziness and nausea; the site should drop decorative motion when the setting is on.

Two measurable costs of heavy animation:

• Load time. Animation libraries and video backgrounds push Largest Contentful Paint past the 2.5-second good threshold on 4G.
• Layout shift. Elements that animate into position after load count toward Cumulative Layout Shift, where 0.1 is the ceiling for a good score.

A site that passes Core Web Vitals on the Mobile tab of PageSpeed Insights with animation on is fine. One that passes only with animation off has too much.

Which accessibility basics apply?

Accessibility is the floor under all of the above. WCAG 2.2 Level AA is the reference used by Singapore government sites and most procurement checklists, and the basics cost nothing when built in from the start.

• Every image has alt text that states what it shows, or an empty alt attribute if decorative.
• Headings follow order: one H1, then H2, then H3. Screen readers navigate by them.
• Every form field has a visible label, not only placeholder text, and errors are described in words next to the field.
• Everything works by keyboard: tab through the page, and the focused element is visible.
• Links say where they go. "Read the pricing page", not "click here".
• Colour is never the only signal. A red border and the word "required" together.
• Video has captions; audio has a transcript.
• Language is declared in the page code, including for Chinese or Bahasa versions.

Lighthouse's accessibility audit in Chrome catches about a third of these automatically. The rest take 20 minutes with a keyboard and a screen reader such as VoiceOver on iPhone. Add both to the website audit checklist you run before launch and once a quarter after.

What cense does

cense designs the phone layout first and checks contrast, tap targets, reduced motion and Core Web Vitals before handover. Sites are built in Next.js with HTTPS, security headers and no plugins, hosted on Vercel or Google Cloud. See web design in Singapore for scope and pricing.