Applied design lab

A backlog makes every idea look like work waiting to happen. Before adding to it, walk through what someone is trying to accomplish with the product. Where do they stop? What do they do outside it?

Open the page on your phone and try to finish the task. Then try it with the keyboard. The layout that looked finished in a screenshot may become difficult the moment you need to correct a mistake or read a long name.

1. Choose one journey: Record the candidate version, primary task, supported environments, and relevant states. Use realistic safe data. Include an error and an empty state; a page that works only with ideal content is not ready simply because the happy path looks good.
2. Run the tests: Use the project’s tests and browser checks. Playwright’s accessibility guidance shows how to integrate axe-core scans, but these do not detect every accessibility issue. Keep raw results and record what was not covered. Do not turn a zero-violation report into a claim that the whole site is accessible.
3. Complete the task by hand: Use keyboard navigation and verify visible focus, sensible order, labels, dialogs, and escape behavior. Review headings and meaningful image alternatives. Check contrast for actual text/background pairs and make sure meaning does not depend on color alone. Include a screen-reader pass where the task requires it and involve relevant users for consequential flows.

Start with the post someone will see on their phone. Can they read it? Is the crop doing anything useful? Does the date survive when the image gets small? Settle those questions before making twenty sizes.

1. Choose the formats in your brief and check the destination requirements.
2. Gather the approved copy, brand files, and licensed images. Use the production prompt as a checklist or paste it into your assistant.
3. Keep editable masters in your design app. Export the files, open them, and review the actual result before publishing or sending it to a supplier.

A new project can acquire a database, accounts, and an email service before anyone has made its first useful screen. Each addition brings something to configure and something to maintain. Start by deciding which of them the work actually needs.

1. Make the first slice small and testable: Describe one user journey from entry to a useful result. List the data it reads and writes. Mark public content, personal information, and secrets separately. Decide who owns the project and who may approve infrastructure or costs.
2. Inspect before scaffolding: In an existing repository, read its instructions, scripts, dependency versions, and environment example. Preserve its package manager and design system. For a new repository, follow the selected framework’s current setup docs. Do not paste version-specific commands from an old project without checking them.
3. Run locally with harmless data: Build the smallest journey with fixtures. Keep real credentials out of source control and browser bundles. Document environment variable names with placeholders, plus which are required. Add a database or mail service only when the first slice needs persistence or delivery.

A brand guide has to keep working after the designer leaves the room. Someone should be able to open it, choose the right file, and make a page without calling you to ask what the rules meant.

1. Start with a short account of the organization, its audience and the promise the identity must support.
2. Document voice, logo usage, color roles, typography and layout. Explain exceptions as well as the normal case.
3. Include accessible color pairs, font licensing information, minimum sizes and examples at realistic content lengths.

Suppose someone changes a color in Figma while an engineer changes its counterpart in code. Which one should the sync keep? Until you can answer that, a two-way connection is just a faster way to lose a decision.

1. Choose which source leads: Choose code or Figma as authoritative for the pilot and name the approver. Freeze a source version. Limit the first pass to values both sides can represent. Keep typography and other composite tokens out until you have defined how they map to variables, styles, or separate fields.
2. Write the mapping before the importer: Map source names to Figma names and stable variable IDs when available. Record aliases and mode names. Explain unit conversion explicitly: a number alone does not mean the same thing as a CSS rem value. Mark unsupported data rather than dropping it silently.
3. Test in an isolated collection: Create a sandbox variable collection using Figma’s supported types. Test colors and spacing on real components, including both themes if your account and setup support the required modes. If using a plugin or API, check its current format support and permissions; do not assume every token JSON file imports unchanged.

At Noord, we use AI to help us do more of the work ourselves. We can move from a conversation to something a partner can try, make changes while the questions are still fresh, and spend more time looking at whether the result is any good.

Follow a piece of work through the diagram: a conversation becomes a brief, the brief becomes something to look at, and the review changes what gets made next. Expect to go around that middle part more than once.

If the next agent has to rediscover what you meant, you have handed over a conversation rather than a task. Decide what needs deciding first, then give it something small enough to finish and specific enough to check.

Write down the chosen direction before splitting up the work. Each agent should receive the part it needs, including any decision it must leave alone. Keep the original conversation available for reference rather than copying it into every task.

Ask five people what the company should sound like and you may get five reasonable answers. The useful part of the workshop is finding where those answers would lead to different work.

The identity should help you recognize the work without getting in its way. At Noord, that means a clear page, careful type, and enough room to look at the image or decision in front of you.

1. Noord is an applied design lab building interfaces that bring human judgment into visual model training.
2. Use plain language, sentence case, clear hierarchy and a restrained palette. Interface structure should support the work rather than compete with it.
3. Preserve readable line lengths and accessible contrast in both themes. Reserve interaction for things people can act on.

We gave ChatGPT, Claude, and Grok the same three design jobs. Build an app for reviewing photographs. Build a capacity planner. Then build the review app again, this time from a detailed layout. Each used Vlak, our design system. We wanted to see where each model helped—and what we’d still have to fix.

A Review room is a shared place to look at work and decide what happens next. A partner opens a photograph, inspects it, then approves it or asks for a change. The feedback and decision stay with that image, so the person doing the next revision knows what to do. Less hunting through a chat for which “that one” someone meant.

“This looks like slop” is a reaction, not a useful brief. Which bit? What is wrong with it? What does it stop someone from seeing or doing? We built a small review tool to make ourselves answer those questions.

We look for decisions that feel unconsidered and get in the way of the work. A familiar pattern is not automatically slop. Neither is a plain interface. The question is whether a choice serves this task, in this context.