72 lines
3.6 KiB
Markdown
72 lines
3.6 KiB
Markdown
---
|
|
name: frontend-design
|
|
description: Make deliberate visual design choices for new UI or a reshaping of an existing one, and run the mock-then-decide workflow before touching real components.
|
|
---
|
|
|
|
# Frontend Design
|
|
|
|
Distinctive UI comes from decisions made on purpose. Templated UI comes from decisions made
|
|
by habit. This is about catching the second kind before it ships.
|
|
|
|
## Start from the thing itself
|
|
|
|
If the brief does not say what the product is, who it is for, and what the screen is
|
|
supposed to accomplish, work that out first and confirm it before designing anything. A
|
|
dashboard for people reconciling invoices and a booking page for a surf school want
|
|
different palettes, different type, different density, and pretending otherwise is how you
|
|
end up with the same page twice.
|
|
|
|
Name the subject in one sentence, name the audience in one, name the job of the screen in
|
|
one. Design against those three sentences. When a choice cannot be justified from them, it
|
|
is decoration.
|
|
|
|
## Choices to make deliberately
|
|
|
|
**Type carries the personality.** Pick the family on purpose rather than reaching for the
|
|
usual one. Decide a scale up front and hold to it, so a heading is a heading everywhere and
|
|
not a heading in one place and a slightly larger paragraph in another. You rarely need more
|
|
than two families.
|
|
|
|
**Colour is a system, not a pick.** Name the roles before the values: what is background,
|
|
what is surface, what is text, what is the one accent. The accent is the only one that gets
|
|
to be loud, and it earns that by being used sparingly.
|
|
|
|
**Structure is information.** Borders, rules, labels, numbering, eyebrows and dividers
|
|
should be telling the reader something about the content. If a device is only there to fill
|
|
a gap, it is ornament. Numbered markers in particular only make sense when the content is
|
|
genuinely a sequence.
|
|
|
|
**Motion answers the user.** Motion that reacts to what somebody did is useful, because it
|
|
shows what changed. Motion that runs on its own is filling space. Do not use continuously
|
|
repainting effects such as pulse, shimmer, blur or spinners. They peg the GPU on high
|
|
refresh displays and read as generated.
|
|
|
|
## Tells to avoid
|
|
|
|
These are the shapes that show up again and again in generated UI, and they are the fastest
|
|
way to make a page look like nobody chose it:
|
|
|
|
- A cream background with a serif display face and a warm terracotta accent.
|
|
- A near-black background with one acid green or vermilion accent.
|
|
- A headline with exactly one word italicised, bolded or coloured.
|
|
- All-caps labels used as decoration rather than because the label is short and needs it.
|
|
- A label above every block of content, naming what the content already makes obvious.
|
|
- The same fade-and-slide entrance applied to every section, and a hover lift on every card.
|
|
- A hero that is a big number, a small label and a gradient, when the subject has something
|
|
more characteristic to show.
|
|
|
|
## Workflow
|
|
|
|
This is the rule from my preferences, spelled out:
|
|
|
|
1. Build several genuinely distinct directions, not three variations of one idea. Different
|
|
palettes, different type, different structure. If two mocks would be described the same
|
|
way in one sentence, they are the same mock.
|
|
2. Build them as static pages. Real content, not grey boxes labelled "image here", because
|
|
the content is where most of the design decisions turn out to matter.
|
|
3. Publish them with a simple http server, report the URL, and stop.
|
|
4. Wait for a decision before implementing anything in real components.
|
|
|
|
Do not edit real components first. Do not keep polishing past the point where a choice
|
|
could be made, and do not pick a winner yourself and build it.
|