Words for a design

An AI design tool such as Stitch gives you a first mockup of your portfolio in a minute or two. It looks finished, and it often looks like everyone else's. It has the same plain sans-serif font everywhere (a font whose letters have no small strokes at their ends), a purple-blue gradient, rounded cards, everything centred and a stock illustration. These are the tools' defaults. Vague requests such as "make it pop" or "more modern" only give you another version of the same thing. Precise words and your reference sites help you escape these defaults. The same words also work with a human designer.

The first word is hierarchy: what you see first, second and third. A designer sets it with size, weight (how bold the text is), colour, position and the space around each element. To check it, step back from the screen, or squint (half close your eyes) until the details blur. What still stands out is what visitors see first. Then say what should come first, and why, with these words. For example: "The project titles are the same size as the body text, so nothing stands out. After my name, a recruiter should see the projects."

Layout is where things are placed on the page. Most pages are built on a grid. A grid is a set of columns, separated by gaps called gutters, and every block is aligned with it. Elements that share the same left edge look intended. A title that starts a few pixels to the right of its photo looks like a mistake, even to people who can't say why. The order of the sections is part of the layout too. On your portfolio, do the projects come before the "About" text or after it?

Spacing is the empty space between things, often called white space. It tells the eye what belongs together. A project's title should be closer to its own picture than to the next project. When every gap is the same size, nothing seems to belong to anything. Designers pick each gap from a short list of sizes called a spacing scale, such as 4, 8, 16, 24 and 32 pixels. They use the same few values everywhere, which keeps the page consistent. Feedback that uses these words is easy for a designer to follow. For example: "The gap between a title and its photo is the same as the gap between two projects, so I can't tell which title goes with which photo."

Type is the look of the text. A type scale is a short set of sizes, each with a job: your name, the section titles, the project titles, the body text and the captions. If you use it consistently, it does half the work of the hierarchy. Most good sites use one or two typefaces (font families), often one for titles and one for reading, with two or three weights (levels of boldness).

Paragraphs also need a good line length and line height. About 60 to 75 characters per line is comfortable to read. Text stretched across a wide screen tires the eye on every line. Line height, the space between lines, should be large enough for the eye to find the start of the next line.

Colour works best as a small palette where each colour has a role: text, background, an accent colour for links and buttons, and a colour for errors. Body text needs a contrast of at least 4.5 to 1 with its background. On this scale, 1 to 1 means no difference between the two colours, and black on white is 21 to 1. The browser's developer tools measure it for you. Colour should never be the only signal, either. About one man in twelve is colour-blind, and may not notice that a form field turned red because it's wrong. So the field also needs a written message.

A site is built from components, such as a project card, a button or the navigation bar. Each one is designed once and reused everywhere. So when you change the card, every project changes at once. A component can have variants, such as a main button for "Download my CV" and a more discreet one for "See it on GitHub".

Each component also has states: the ways it looks, depending on what's happening. Hover is when the mouse is over it. Focus is when the keyboard has reached it. A component in focus needs a visible outline for people who use the Tab key to move through the page. Active is the moment it's pressed. Disabled is when it can't be used. Whole areas have states too: loading, empty, error and success. Take your contact form. What does it show while the message is sending, when the email address is typed wrongly, and once the message is sent? Mockups usually show only the case where everything goes well, with perfect content, on a large screen.

Two words from the lesson "Look and layout" complete the list. Responsive means the page rearranges itself to fit a phone, and it's best to design the phone version first. Tokens are the named values for colours, type and spacing. The mockup and the site both use them.

"I don't like it" and "make it pop" give a designer nothing to work on. An AI tool answers them with a random change. "Make the text darker" is more precise. But it chooses the fix before naming the problem, and there may be a better fix.

Useful feedback says what you observe, the effect it has, and what you want. For example: "The grey text on white is hard to read, so older visitors will have trouble. It needs more contrast." The designer can then choose how to fix it, for example with darker text or a lighter background. The same method works with Stitch. Describe one change at a time, in these words, and compare the result with what you asked for.

Then sort your remarks. What blocks people comes first: text they can't read, a contact link they can't find, a page that breaks on a phone. Next comes what's off-brand, meaning it doesn't fit the image you want to give, such as a playful look on a serious engineering profile. Matters of personal taste come last. Ten small remarks about shades of blue can hide the one blocking problem in the list. If needed, send the blocking problems on their own.

Ask these questions whenever you receive a mockup, from an AI tool, a designer or an agency, before anything is built.

Ask to see the phone version first, and judge it on a real phone in your hand. A design that only works on a large monitor fails most visitors. Ask to see the design with your real content: the longest project title, the project with no picture, the full "About" text. Ask what each component looks like in its other states: a button reached with the keyboard, a form with an error, a list with nothing in it yet.

Ask for the design's values as tokens, written down: the colours with their roles, the type scale and the spacing scale. The coding agent that builds the site can then use the same values, instead of guessing them from a picture. When something seems wrong and you can't say why, ask the designer to describe the hierarchy: what a visitor should see first, second and third. Then compare the answer with what you see on the page.