Design Patterns
Building a design architecture to train internal AI tools and write SKILL files.
Intro
With the introduction of AI-assisted development, we as a design system team wanted to keep pace with the product teams, to give them the velocity they needed without losing consistency or drifting away from our design system principles and guidelines. Now, typing “build me a booking screen” into a coding environment or a tool like Cursor, even with all guidelines provided, resulted in a screen that’s correct conceptually, but not aligned with our UX and development standards and guidelines. Figuring out how to “train” AI to match how things are done at Wix became the goal of this project.
generated
ours
Visual plan: show a plausible generated booking screen beside the same screen resolved through the design system. The output should look nearly right, because that gap is what makes it expensive.
The challenge
Each Wix vertical has its own representation on mobile. Bookings, Stores, Events, Restaurants and others. Different teams, different roadmaps, different designers, all relying on a single design system. In order for the AI to rely on a defined ecosystem, this system itself must be clear and follow a structural approach so it can learn and memorize. Throwing guidelines and libraries at it resulted in inconsistent outputs, since it couldn’t correctly understand context or the intent of a screen. What was seen as a design system by designers and developers looked like an array of elements to the model.
The idea
I realized that we needed another level of structuring for our design system. It must rely on actual logic of how screens are built in context. Something structured and yet flexible and abstract. Sounds contradictory, but this is what we already used in the form of design tokens. If a color can be described by its role instead of its value, a whole screen can be described the same way — broken into building blocks and resolved by the system rather than drawn from scratch every time.
Entity
An entity can be seen as an atom in an atomic design system: the smallest thing the rest of the screen is built around. A contact or a site member, a product, a service, a session, an event. It’s what the screen is about — the components that identify it, like an Avatar, a thumbnail or a product image, are how it’s shown, not what it is.
The formula works through three main slots: Entity, Action, and User. Entity describes what the screen is built around. Action describes what is being performed. User describes who is performing the action: business owner, staff member, customer, or seller. An additional layer, the actual product ecosystem, makes this abstract pattern more precise.
The 3×3 grid
Columns: List, Details, Creation. Rows: Person, Product, Service. Nine simplified frames. The identifier slot — Avatar, thumbnail, service image — should land in the same position across every row. The axes make the architecture readable in a few seconds.
Mapping
To test the Entity approach, my colleague and I gathered 80+ production screens across Wix products. To keep it manageable, we used Figma Make to build a categorizing tool that took the entire screenshot collection in bulk and let us sort it with tags. It was never a deliverable. It was the instrument that made the analysis possible, and more importantly, it made the framework cheap to adjust.
Writing it for a model to read
With the abstraction in place, the original goal became writable. A SKILL file is an instruction set an assistant loads to do a specific job the way your organization does it. Which means it can only ever be as good as the description underneath it — you can’t write a useful instruction for a system whose behavior you can’t state. The name is the address, not the content: entityListOwner tells an assistant which frame it’s working in, but the uplift comes from the structure behind the name.
Reflection
The value here was never the screens. Anyone can draw a list. The value was deciding that “a list of things” is a type — and that products own entities, not screen designs. What surprised me was how much writing for a model improved the writing for people. A designer reads a vague guideline, guesses what you meant, and usually guesses right. A model doesn’t guess. Every place where a rule was really a habit, or a structure was really someone’s preference, had to be resolved before it could be written down at all.
The discipline that makes a system legible to a machine turns out to be the same discipline that makes it legible to a designer who has never seen the product.