# Vlak

The open design system: interface components, patterns and implementation guidance.

**TL;DR**

Start with Vlak’s components and patterns, then spend your attention on the work the interface needs to support. The button is already a button. We can move on to the interesting problem.

Status: Working reference

## Before you start

For: Designers and engineers building interfaces

Use when: You need a shared component foundation rather than bespoke controls for every screen.

Bring: A target interface, technical constraints and the official Vlak documentation.

Leave with: A chosen set of components tested against a real task.

## Worked example (fictional)

For a fictional review queue, start with selection, status and a detail panel. Test long labels and keyboard navigation before expanding the component set.

## Check the result

Check the current API, supported framework and license on vlak.dev.

## Limitations

Polder explains the surrounding method. Vlak’s installation and API documentation remain authoritative.

Vlak gives us a shared starting point for an interface. The buttons, fields, and type already belong together, which leaves more attention for what the page needs to do.

Use the component documentation for the current APIs, installation, and licenses. If you knew the project as Raster, this is its new name. Polder covers the work around it: deciding what to build, explaining the choices, and checking the result.

## Method



## Handoff

Record the input sources, decisions, assumptions, owner and acceptance checks. Have the responsible person approve the record before downstream automation.

## Tools, in order

### Before building

[Vlak](https://vlak.dev) · [Notion](https://www.notion.com/)

Define the actual interface task and inspect the current Vlak documentation. Choose components that fit the task before inventing new controls.

Carry forward: A component plan and acceptance criteria.

### During implementation

A coding workspace with approved file access · [Claude](https://claude.ai/), [ChatGPT](https://chatgpt.com/), or [Grok](https://grok.com/) · [Vlak](https://vlak.dev)

Give the coding agent the approved component choices, current APIs, and realistic content. Keep the first implementation small enough to inspect.

Carry forward: A working interface in a local or preview environment.

### Before review

[Browser and accessibility checks](https://www.w3.org/WAI/test-evaluate/preliminary/) · [Playwright](https://playwright.dev/docs/accessibility-testing)

Test keyboard use, focus, errors, long labels, and mobile behavior. Share a working preview, not only a screenshot.

Carry forward: A tested preview with known limitations.

### Review the work with partners

We make and revise the work with Claude, ChatGPT, or Grok, then put selected versions on our Studio project pages for partners to review. Check the preview before sharing it. You can do the same with a private prototype or shared document; use a workspace that can access the files you need.

Name the version, say what changed, and ask the question you need answered. Keep feedback with that version and discuss conflicting requests before making the next changes. Confirm approval separately, and keep confidential work in a restricted space.

For this method: Can you finish the task without explanation, and where does the interface interrupt you?

### Delegate the routine work

Repeat a verified component pattern or write bounded tests for known acceptance criteria.

Keep with a person: Interaction choices, accessibility decisions, and changes to the shared system need design and engineering review.

[Sequence prompts, then delegate](https://noord.dev/polder/delegating-with-prompts)

[Choose a model for the design task](https://noord.dev/polder/choosing-design-models)

Source: https://noord.dev/polder/vlak

Public working material from Noord. Third-party code, fonts and assets retain their own licenses. Publication does not imply a license to redistribute third-party material.