Build Your Environment to Train Taste

How I Design With AI Today

Recently, I have been thinking a lot about what actually makes someone better at design, especially now that AI can produce interfaces, code, images, and variations much faster than any individual designer could manually.

The answer sounds almost too simple, but I keep coming back to the same three things:

Good foundations, good data, and a good feedback loop.

In many ways, this is not very different from training an AI model. A strong model architecture matters, but architecture alone is never enough; the quality of the training data, the environment the model operates within, and the feedback it receives all shape what the model eventually becomes capable of producing.

I think design ability develops in much the same way, which is why I do not believe there is any real shortcut to developing taste.

You can find hundreds of websites that collect beautiful interfaces, bookmark great products, follow designers whose work you admire, or browse Refero, Mobbin, Varriants, and whatever other inspiration platforms fit the kind of work you are doing.

These tools are useful, but I increasingly think of them as high-quality database plugins rather than the learning system itself. They give you fast access to good data, which can be incredibly effective for a short project: find a reference, identify the pattern, adapt it to your context, and continue building. But that is very different from creating a long-term learning pipeline that keeps improving over time. The harder, and ultimately more important, question is:

How do you create an environment that continuously produces good training data for your own brain?

My Current Design Workflow

I increasingly think about my design workflow as a loop rather than a linear process with a clear beginning and end:

Taste → Context → System → Exploration → Build → Review → Feedback

The feedback from one project eventually becomes part of your taste and judgement for the next, which means every project is also contributing training data back into the system.

1. Taste

I work closely with teams building reinforcement-learning environments for AI models, so over time I naturally started thinking about my own learning process through a similar lens.

If I wanted to improve a model, I would never give it ten beautiful examples once and expect that exposure alone to suddenly make it intelligent or capable of consistently producing good results.

Instead, I would think much more carefully about the environment surrounding it.

• What kinds of examples does it see every day?
• How diverse is the data it learns from?
• How does it learn to distinguish good outcomes from bad ones?
• What happens after it makes a mistake?
• Does the feedback it receives actually help it improve?

I think almost exactly the same questions can be applied to designers and to the environments we create around ourselves.

Your everyday environment is already part of your training dataset. The products you use, architecture you walk past, games you play, fashion, photography, films, typography, conversations, physical objects, badly designed interfaces, beautifully designed interfaces — all of these gradually become input, whether you deliberately study them or not. This is why I still believe

life is one of the best sources of design inspiration.

Good taste is partly the result of continuously exposing yourself to good information while developing the ability to understand why one thing works better than another. The goal is not simply to collect more references or build a larger inspiration folder; it is to create a personal learning system that continuously improves the model inside your head.

2. Context

Every project starts from a different situation, and I have found that trying to force all of them into the same design process usually creates more unnecessary work than consistency.

Sometimes a colleague gives me a clear requirement and I simply need to understand it well and build it. Sometimes I notice that an existing experience is weak and decide to go back and rethink it. Other times the product itself is fine, but the tools, systems, or workflows I use to build it have become the part that needs improvement.

And sometimes a new model capability changes what I believe is technically or creatively possible, which can make me reconsider the workflow itself rather than only redesigning the output. Because of this, I do not really believe in following one fixed design process for every problem.

The first thing I try to understand is therefore the context surrounding the problem:

• What are we actually trying to achieve?
• What already exists?
• What is genuinely worth changing?
• What should remain untouched?
• What is unique about this particular product?
• What information does the model need in order to make useful decisions?

When working with AI, context is no longer only background information for the designer; it becomes part of the design material itself.

The quality of the final result depends heavily on how well that environment has been prepared before generation even begins, because anything you fail to specify becomes something the model has to infer for itself.

3. System

One thing I have increasingly come to believe is that design should usually begin with a system, and this is also one of the distinctions I personally make between design and art.

Design often moves from large to small.

You first define the system, constraints, hierarchy, behaviours, relationships, and rules, and then compose individual interfaces within that larger structure.

Art can often work in the opposite direction, beginning with a small observation, emotion, object, or personal discovery and expanding outward into something larger. For product design, I therefore prefer to have some form of design.md before I start building, although it does not need to become a complicated specification document.

It can define things such as:

• typography
• spacing
• visual direction
• surfaces
• borders
• layout principles
• colour behaviour
• interaction principles
• component rules

The important part is not really the file itself. What matters is forcing both myself and the model to establish a shared design language before we start producing dozens of screens that individually look acceptable but do not belong to the same system. For references, I commonly use:

• Refero
• getdesign.md

These are useful starting points when I want to translate a loose aesthetic direction into something more explicit and systematic before implementation begins.

4. Exploration

Before producing any UI, I normally bring several different kinds of context together so that the model understands not only what the product is, but also what deserves attention within it:

• the product or PRD
• reference screenshots
• the design.md
• the specific thing that makes the product interesting
• the content or functionality that actually deserves attention

I then use AI to help me distil all of this information into a clearer view of what is actually worth showing and what can remain secondary.

Instead of immediately asking the model to generate polished screens, I usually begin by working through the content hierarchy and page structure, because a visually attractive interface is not particularly useful if the product story underneath it is still unclear.

For example:

• What should users understand immediately?
• What is the hero?
• Which product capability deserves the most space?
• What should be secondary?
• What should be explained with text?
• What should be demonstrated visually?

I often ask for several possible structures before deciding which direction to take. At this stage, I am not looking for polished screens; I am trying to understand how the product should tell its story and how the information should be prioritised. Once that structure feels right, I move into visual exploration.

I provide the model with:

• the design.md
• reference screenshots
• the product structure
• relevant product context
• existing visual assets where appropriate

For visual exploration, I currently like using ChatGPT image generation because it allows me to move through very different directions quickly. Instead of asking for one supposedly final design, I normally generate several alternatives and treat them as a search space. The goal is not for the model to decide what the product should look like; the goal is to expand the search space quickly so that I can make better decisions. I might take the layout logic from one version, typography from another, reject a third entirely, or discover a visual direction that I probably would not have explored manually.

5. Build

Once the visual direction becomes clear, I translate it back into a system so that what initially emerged through exploration can be implemented consistently. Colour is a simple example of this.

Rather than selecting slightly different hex values independently across dozens of components, I prefer to define a proper colour scale and let the interface inherit from that system.

I frequently use OKLCH: npx skills add jakubkrehel/oklch-skill

This is also where specialised agent skills become particularly useful. I do not think a good skill should simply be another long prompt; ideally, it should contain some of the judgement, principles, and working knowledge of someone who is genuinely good at that domain. Once the system, references, structure, and visual direction are established, I can move into implementation with much less ambiguity.

The model is no longer receiving a vague instruction like Build this website. Instead, it is working inside a much richer environment:

Product context
+ PRD
+ design.md
+ reference screenshots
+ visual direction
+ page structure
+ existing codebase
+ specialised skills

For implementation, I currently use coding models such as GPT-5.6 Sol or Claude Opus depending on the task. I do not really think of this workflow as simply image-to-code, because the image is only one small piece of the information the model is using. Implementation quality comes from all of the context accumulated before the coding step, and the more clearly that environment is specified, the less the model has to invent or guess on its own.

6. Review

This is the point where human judgement becomes especially important, because AI can generate a huge number of solutions that are technically valid without necessarily producing something I would consider good design.

I review things such as:

• visual hierarchy
• spacing
• composition
• typography
• information density
• interaction
• empty states
• responsive behaviour
• visual rhythm
• unnecessary complexity
• whether the product actually communicates what matters

Sometimes there is no obvious technical problem and nothing I can immediately describe as incorrect, but the result simply feels wrong. I think that feeling is also part of accumulated design training: years of seeing, making, comparing, and correcting things eventually become judgement that is difficult to compress into a single rule. This is why I never treat the first AI output as the finished product.

Generation is becoming increasingly cheap, while good judgement — knowing what to keep, what to remove, and why something is not working — is still expensive.

Human in the Loop

When something is wrong, there are many different ways I can intervene, and the right intervention depends on what kind of failure I am actually looking at.

I might:

• change the prompt — rewind the query and approach the problem differently
• add more context — include related project code, product information, or existing design
• switch models — use a stronger and more expensive model when the task genuinely requires it
• simplify the requirement — use a stronger model to decompose a complex task into smaller pieces first
• manually edit the code — yes, I still do this when direct intervention is the fastest and clearest option
• use an annotation tool to pinpoint the exact component or area that needs to change, while keeping the larger system and overall design direction under my control
• change the design direction entirely and explore another prototype instead of trying to repair a weak direction indefinitely

There is no universal workflow for this, and different designers will naturally intervene at different stages depending on their strengths and the tools they use. For me, the important part is understanding what kind of problem I am looking at before choosing how to fix it, rather than repeatedly prompting the model without understanding why the previous result failed.

7. Feedback

Every serious review produces new training data, whether that knowledge is eventually written down or simply becomes part of my judgement.

If a particular approach works consistently, I want to understand what made it work so that I can reproduce the principle rather than only remembering the individual example.

If an AI-generated interface repeatedly fails in the same way, I also want to understand that pattern and turn the observation into something reusable rather than correcting the same problem project after project.

That might become:

• a rule in design.md
• a prompt pattern
• a reusable component
• a code convention
• an agent skill
• a checklist
• a better reference library
• a change to the workflow itself

This is where the process loops back into taste and gradually changes how I approach the next project.

The feedback from one project becomes part of the environment for the next one. One thing I would not recommend, however, is delegating the entire reflection process back to an agent and letting it write all of your feedback for you. I tried doing this for quite a long time, and eventually realised that I almost never went back to read what the agent had written. Over time, a gap started forming between what I actually understood from the project and what the agent had documented on my behalf. At that point, the notes had effectively become another external plugin database: potentially useful information, but knowledge that did not really belong to me because I had never processed it myself.

Skills as Compressed Expert Judgement

I increasingly use skills created by other designers and engineers as part of this process, but what makes them valuable to me is not simply their ability to automate more work. The best skills compress some of the working principles and judgement of someone with genuine domain expertise into something that can become part of the environment the model is operating within.

Interaction and motion are good examples, because many of the differences between an average implementation and a strong one come from small timing, easing, hierarchy, and behavioural decisions that are difficult to communicate through a generic prompt.

For this, I like Emil Kowalski's design engineering skills:

• Emil Kowalski's Skills

I also use Transitions as a reference when I am exploring more subtle interaction and motion patterns. These tools do not replace taste or remove the need for judgement; instead, they introduce more specialised expert knowledge into the environment I am already working inside.

The Workflow Is Still Changing

I do not consider any of this a finished methodology, and I would probably be suspicious of it if the process stopped changing while the tools around me continued to evolve.

It is simply a snapshot of how I currently build things and how I think about designing with AI today.

Six months from now, I expect parts of this workflow to look completely different, because the capabilities and limitations of the tools are changing too quickly for the process around them to remain static.

Models will improve, which will change both what I delegate and the amount of context I need to provide manually.

Tools will disappear, merge into other products, or become unnecessary once the underlying models can handle more of the workflow directly.

New interfaces will emerge as we find better ways for humans and models to communicate beyond the current combination of prompts, chat windows, screenshots, code editors, and annotation tools.

Some steps that currently require five different tools may eventually collapse into a single interaction, which will probably change where the designer needs to intervene and where judgement becomes most valuable.

I am also not trying to invent an entirely new collection of skills yet, because I think it is more useful for me to understand the workflow before trying to formalise every part of it.

Right now, I am still developing the process itself: understanding what should remain human judgement, what can be delegated safely, what is repeated often enough to become a skill, and what should remain flexible because forcing it into a system would remove more value than it creates.

What I think will remain valuable, regardless of how individual tools change, is the ability to deliberately build a good learning environment around yourself.

Use AI to increase the number of directions you can explore without confusing exploration with decision-making.

Use systems to remove repetitive decisions so that more of your attention can go toward the parts of the work that actually require judgement.

Use specialised skills to bring domain expertise into the process without assuming that borrowed expertise can replace your own understanding.

Keep yourself inside the feedback loop, particularly when the feedback is what teaches you why one solution is better than another.

And continue improving the quality, diversity, and relevance of the data you expose yourself to, because that environment gradually becomes part of the way you see and make decisions.

Because whether you are training an AI model or developing your own ability as a designer, the underlying principle is surprisingly similar:

better output comes from better taste, better context, better systems, and better feedback.