Design brief for AI assistants

This is the Page Lemon design brief for AI assistants. You are designing a website for a person who asked you to "design this like a senior product designer". Read this brief before you design anything. The rules are ordered by importance: if you can only keep some, keep the top ones. Every rule is something you can check. Where a rule says "so", that is the reason; use it to decide edge cases. If the person asks for something different, their request wins; mention any accessibility rule it breaks.

The 12 rules that matter most

• R1. Ask, propose, wait. Before writing code, ask the questions you need (audience, goal, the one action a visitor should take, brand colours or fonts, content you have). Then describe the design direction in five bullets and wait for an OK.
• R2. One focal point per section. Each section has one thing that is clearly biggest or boldest, usually the heading or a single main button. So the eye knows where to start.
• R3. One primary button per screen view. Other actions are secondary (outline or text style). So the main action is obvious.
• R4. A fixed spacing scale: 4, 8, 12, 16, 24, 32, 48, 64, 96 px. Use no other values. So spacing looks deliberate.
• R5. Two fonts at most, and a fixed type scale (see Typography). Body text 16 px or larger, line height 1.5, lines 45 to 75 characters wide.
• R6. Contrast: body text at least 4.5:1 against its background; large text (24 px or bigger, or 19 px bold), icons, input borders and focus rings at least 3:1.
• R7. Mobile-first. Design for a 360 px wide screen first, then widen. No sideways scrolling at 320 px.
• R8. Tap targets at least 44×44 px (WCAG's floor is 24×24 px; aim higher), with at least 8 px between neighbouring targets.
• R9. Every interactive thing has visible hover, focus, pressed and disabled states. Focus is a 2 px or thicker outline at 3:1 contrast, offset 2 px. Never remove the outline without a replacement.
• R10. Real HTML. Use <button>, <a>, <label>, <nav>, <main> and headings in order (one <h1>). So screen readers and keyboards work for free.
• R11. Motion is small and purposeful: 150 to 300 ms, only transform and opacity, and all of it off under prefers-reduced-motion: reduce.
• R12. Fast: main content within 2.5 s on a mid-range phone, no jumping while loading (reserve space for images), total page weight under 1 MB where possible.

How to work

• Start from the subject. Ask what the business, person or event is, who visits and what they should do. Choose colours, fonts and imagery that suit that subject, not a generic template.
• Propose before building: five bullets covering layout, type, colour, imagery and motion. Wait for an OK.
• Think in greyscale first: hierarchy should work from size, weight and spacing alone. Add colour last, so it supports hierarchy instead of carrying it.
• After building, run the pre-flight checklist at the end of this brief and fix anything that fails before you show the result.
• Use plain HTML, CSS and a little JavaScript unless the person asks for a framework. Put colours, sizes and durations in CSS custom properties at the top so they are easy to change.

Layout and spacing

• R13. Text columns at most 70 characters wide (about 680 px at 16 px). Page content at most 1200 to 1280 px wide, centred.
• R14. Side margins: 16 px on phones, 24 px on tablets, 32 px or more on desktop.
• R15. Use CSS Grid or Flexbox: 12 columns on desktop, 4 on phones, with 16 to 24 px gaps. No absolute positioning for layout.
• R16. Space between sections: 64 to 96 px on desktop, 48 to 64 px on phones. Space inside a group is always smaller than space between groups, so related things look related. Start with generous white space.
• R17. Align everything to a few shared left edges. Centre only short blocks (headings, a hero, one call to action), never paragraphs longer than three lines.

Typography

• R18. One typeface, or two at most: one for headings, one for body. If two, make them clearly different (a serif heading with a sans-serif body). So the pairing looks intentional.
• R19. Type scale (px): 14, 16, 18, 20, 24, 30, 36, 48, 60. Use no other sizes. On phones, cap headings at 36 to 40 px.
• R20. Line height 1.5 to 1.7 for body, 1.1 to 1.25 for large headings.
• R21. At most three font weights (for example 400, 600, 700). No weights of 300 or less for body text.
• R22. Set font sizes in rem so text grows when the visitor enlarges it. The page must still work at 200% zoom.
• R23. Self-host fonts, or load at most two families with font-display: swap, and only the weights you use.
• R24. Sentence case for headings and buttons. Avoid ALL CAPS except for very short labels, with 0.05em letter spacing.

Colour and contrast

• R25. A palette is one brand colour, one accent at most, 5 to 9 neutrals tinted toward the brand, and status colours (success, warning, error). Four to six named colours plus neutrals is enough.
• R26. Check every text and background pair: 4.5:1 for normal text, 3:1 for large text and for non-text parts (icons, input borders, focus rings, chart lines).
• R27. Never use colour alone to carry meaning. Errors get an icon and words, links in body text are underlined, chart series get labels or patterns.
• R28. Text on photos needs a solid or gradient overlay that keeps 4.5:1 across the whole text area.
• R29. Dark mode, if offered, is a separate checked palette, not inverted colours: dark grey (around #121212 to #1c1c1c) instead of pure black, and slightly lighter brand colours.

Components and states

• R30. Design every state: default, hover (pointer devices only), focus-visible, pressed, disabled and, where relevant, loading, error and success.
• R31. Buttons are at least 44 px tall with 16 to 24 px side padding. Labels are one to three words starting with a verb ("Book a table", not "Submit"). A disabled button still meets 3:1 for its outline, or says why it is disabled.
• R32. One corner-radius family (for example 6 px for inputs and buttons, 12 px for cards) and one shadow style with two levels at most. So components look like one family.
• R33. Use cards only for repeated items of the same kind. Not every section needs to be a card.
• R34. Any action taking longer than 400 ms shows progress (a spinner on the button, a skeleton or a progress bar). Over 10 s, explain what is happening.
• R35. Empty states (no results, nothing yet) say what happened and what to do next, with one action.

Forms

• R36. Every field has a visible label above it. A placeholder is never the label.
• R37. Ask only what you need. Mark the few optional fields "(optional)" instead of starring required ones.
• R38. Inputs are at least 44 px tall with 16 px text (smaller text makes phones zoom in). Use the right type and autocomplete (email, tel, name, postal-code) so phones show the right keyboard and can autofill.
• R39. Validate when the visitor leaves a field or submits, not on every keystroke. Error messages sit next to the field, say what is wrong and how to fix it ("Enter an email like name@example.com"), and are linked with aria-describedby. On submit with errors, move focus to a summary of them.
• R40. Never ask for the same information twice in one journey, and never require a memory puzzle to sign in (allow paste and password managers). Split long forms into steps and show the count ("Step 2 of 3").

Navigation

• R41. Desktop: show five to seven main links in the header; don't hide them behind a menu icon.
• R42. Phones: a menu button labelled "Menu" next to the icon, at least 44×44 px. The open menu traps focus and closes with Escape.
• R43. The logo at top left links home. Mark the current page in the nav, visually and with aria-current="page".
• R44. Put help and contact in the same place on every page. Make "Skip to content" the first focusable item.
• R45. A sticky header is at most 64 px tall on phones and never covers the item that has keyboard focus (use scroll-padding-top).

Content and copy

• R46. The hero says what this is, who it is for and what to do: a headline under 10 words, a subline under 25 words and one button.
• R47. Write plain, active language that a 12-year-old could follow. Short sentences, one idea per paragraph, paragraphs of one to three sentences.
• R48. Headings say what the section gives the reader ("Opening hours and parking"), not clever labels ("Visit us"). Links say where they go ("See the full menu"), never "click here".
• R49. Use the person's real content. If you must use placeholders, make them realistic and mark them clearly so they get replaced. Never invent reviews, prices, awards or statistics.

Images, icons and drawings

• R50. Use real photos of the actual business, people or product when available; they build more trust than stock. Use stock only when it shows something specific and true, never generic handshakes or laptops.
• R51. Every image has width and height (or aspect-ratio) so the page doesn't jump, loading="lazy" below the first screen, modern formats (WebP or AVIF) with srcset, and the main hero image under about 200 KB.
• R52. Meaningful images have alt text that says what they show in context. Decorative images use alt="".
• R53. Use one icon set across the whole site, all outline or all filled, never mixed. A good default is an open-source outline set (Lucide, Heroicons, Phosphor or Tabler). Check the licence (MIT or ISC is fine) and keep the notice if required.
• R54. Icon spec: a 24×24 grid, a 1.5 or 2 px stroke used consistently, round caps and joins, fill="none" and stroke="currentColor" so icons take the text colour. Show them at 16, 20 or 24 px, matched to the text beside them.
• R55. Inline small SVG icons in the HTML (no icon fonts). Decorative icons get aria-hidden="true". An icon-only button gets an aria-label and still has a 44×44 px tap area. Icons support words; only universally understood icons (search, close, menu, play) may stand alone.
• R56. Never use a platform's system icons (such as Apple's SF Symbols) or another company's logo as your logo or as decoration; their licences forbid it.
• R57. Draw diagrams, spot illustrations, patterns and dividers as inline SVG. Use a photo when the subject is a real place, person, dish or product people will want to recognise.
• R58. Illustrations share one style: the same stroke width as the icons (or a fixed multiple), the same corner style, and only palette colours (two or three per drawing). Keep each SVG simple: a sensible viewBox, no embedded bitmaps, under about 20 KB, and a <title> when it carries meaning. At most one larger illustration per screen view.

Motion and micro-interactions

• R59. Every animation has a job: show cause and effect (a button press), show where something came from or went (a menu opening), or draw attention once to something new. Decoration alone is not a job.
• R60. Durations: 100 to 150 ms for hover, press and small colour changes; 200 to 300 ms for menus, dropdowns, accordions and small elements entering; 300 to 400 ms at most for large panels. Nothing over 500 ms except a deliberate one-off moment.
• R61. Easing: entering things use ease-out, for example cubic-bezier(0.2, 0, 0, 1). Leaving things use ease-in and are about 30% shorter. Never linear except for spinners and progress.
• R62. Animate only transform and opacity. Never animate width, height, top, left, margin or box-shadow; they force layout or painting every frame and stutter on phones.
• R63. Hover effects are subtle: a colour shift, a 1 to 2 px lift or a scale of at most 1.05. Pressed: scale to 0.97 or darken. Focus states appear instantly, with no fade.
• R64. Scroll reveals: once per element, moving no more than 8 to 16 px with a fade, triggered with IntersectionObserver, and content fully visible if JavaScript fails. Use them for one or two key moments, not every section.
• R65. Anything that moves by itself for more than 5 s (carousels, tickers, background video) needs a visible pause button; prefer no autoplay. Nothing flashes more than three times a second.
• R66. Respect reduced motion: put non-essential motion inside @media (prefers-reduced-motion: no-preference), or under reduce swap movement for a simple fade or nothing. Reveals show content immediately.
• R67. No parallax on body text, no animated layout shifts, and no hijacking of scroll speed.

Accessibility (WCAG 2.2 AA, beyond the rules above)

• R68. Everything works with a keyboard alone, in a logical tab order, with no keyboard traps. Anything done by dragging also works with a single click or tap.
• R69. Set lang on <html>, give each page a unique <title>, and use landmarks (header, nav, main, footer).
• R70. Content reflows to one column at 320 px wide and works with increased text spacing. Nothing important relies on hover alone.
• R71. Videos have captions and audio has a transcript. Status messages (form sent, item added) are announced with role="status" or an aria-live region.

Responsive and performance

• R72. Breakpoints follow the content, typically around 640, 768, 1024 and 1280 px. Use min-width media queries and clamp() for big headings.
• R73. Targets (Google's "good" thresholds): Largest Contentful Paint 2.5 s or less, Interaction to Next Paint 200 ms or less, Cumulative Layout Shift 0.1 or less.
• R74. Keep JavaScript small (under about 100 KB compressed) and deferred; the page should read fine before scripts load. Don't pull in libraries for things CSS does (smooth scroll, simple animations, accordions with <details>). Preload the hero image and the main font, and avoid render-blocking third-party scripts.

Pre-flight checklist

Answer each item yes or no before showing the design. Fix every "no" first.

1. Did I ask my questions, propose five bullets and get an OK?
2. Does each section have one focal point and each screen view one primary button?
3. Are all spacings from the 4 to 96 px scale and all font sizes from the type scale?
4. Two fonts or fewer, body 16 px or larger, lines 45 to 75 characters?
5. Does every text pair pass 4.5:1 (3:1 for large text, icons, borders, focus rings)?
6. Does it work at 320 px and 360 px wide with no sideways scroll, and at 200% zoom?
7. Are all tap targets 44×44 px or larger with 8 px gaps?
8. Can I reach and use everything with the keyboard, with a visible focus ring never hidden by a sticky header?
9. Do all buttons and links have hover, focus, pressed and disabled states?
10. Does every form field have a visible label, the right input type and a helpful error message?
11. Is there one icon set, one stroke width, currentColor, and labels on icon-only buttons?
12. Do all images have size attributes, sensible alt text and lazy loading below the fold?
13. Are animations 100 to 400 ms, transform and opacity only, and off under reduced motion? Is anything moving over 5 s pausable?
14. Is the copy plain, specific and real, with no invented reviews, numbers or logos, and no buttons labelled "Submit" or "Click here"?
15. Is it free of the generic AI look: purple-to-blue gradients and glowing blobs, identical rounded cards, fade-up on every block, emoji as icons, tiny grey text, centred long paragraphs?
16. Would the main content load in about 2.5 s on a mid-range phone without layout jumps?