Context engineering for designers: one-shotting design for fun and profit

You probably seen one of those demos: someone types something into an AI tool and gets an incredible interface done in record time. Hyped like heck, you install Claude, pay $200 for the 20x Max plan, and... you get slop.

Been there, done that. This article is aimed to be a list of ideas I tried – some failed, some succeeded – and hopefully help you not wade through a metric ton of slop.

LLMs 101

Ok, let's get real for a second here. While the Xitter AI bros will tell you that every model is basically a god in a zip file, the reality is that no matter how you slice it, it's basically a glorified autocorrect. Give it a task with no prior context existing in the training data and it will confidently fill every gap with sensible "next token prediction" garbage.

If you're lucky (and whatever you're doing is close to commonly retrieved training data), you'll get pretty close to what you wanted. If you're unlucky, on the other hand, you're going to get inundated with slop.

That's partially because the last 20% in this particular 80/20 rule is about decisions that came from you and your design team.

Laying the groundwork

Before you involve a tool, build the vocabulary.

In my experience, inside design organizations, some decisions live in documentation, Figma frames or code, but most survive as muscle memory, inherited knowledge, and ad-hoc decisions made during design crits and product reviews. The problem here is: nobody writes those down, ever.

A language model works on language, so it works best with whatever it can read. And designers, in my experience, are generally not great at documenting decisions. You'll see those scattered across Figma artboards or review decks, but encoding them as metadata requires building a habit many of us have never had to build.

This missing documentation tends to shows up in small ways. Something scales wrong. A card uses a completely valid surface color for completely wrong purpose. The typography just feels a bit off, but you can't put a finger on why. It's uncanny.

The damn next plausible token

You have a design system. A defined spacing scale explain how the sizing and spacing works. Semantic colors explain how raw values relate to the surfaces of your interface. This is a relatively solved problem.

The remainder of it is a hodgepodge of ad-hoc decisions over time. A designer might prompt the model and remember why something was designed in a certain way. Or they might not. Or they might leave. Are we willing to roll the dice on that?

Reliability improves the moment those decisions are made visible.

Creating a structure

For decisions that need prose, I personally default to Markdown. Simple format, easy to edit, easy to maintain, already well understood by language models. Principles, intent, interaction rules, content guidance, and exceptions live here.

The exact values – spacing, sizing, color, typographic scale, radii, etc. – on the other hand, go into structured formats: TOML, YAML or JSON.

If you're feeling spicy, you can take it a step further and use Nathan Curtis's "Components as Data" approach, encoding decisions for entire components in a structured format. Or even entire pages. I won't tell you what to do, I'm not your dad.

No matter if you do it or not, go read Nathan's article. It's very much "design metaphysics", but it's great.

Also, general rule of thumb is: more, smaller files. That way the model can load and unload things on demand without losing the plot, blowing the context, or getting into the dumb zone.

To help you understand what the hell do I mean, here's an example of a cut down version of what I mean from one of the apps I am working on:

design/
  principles.md
  writing.md
  components/
    card.md
    dialog.md
    ...
  tokens.toml
  breakpoints.toml
  ...

I also have a components.json repository that I built as a proof of concept at one of the jobs. Feel free to take a gander, it's public.

The goal here is to make anything defined well enough that the model can't really hallucinate a plausible next token that isn't plausible after all.

Fix it where the agent can find it

A simple rule: every time a design decision appears more than once, move it into the context files.

Maintaining this metadata is design work. Token files and component notes need the same attention as the rectangles we draw.

So what's the point?

Very good one-shots tend to have a ton of durable context behind them. The agent can read up on the metadata, and retrieve exact values without trying to rebuild the world. The prompt stays short because the decisions already live elsewhere.