Design Brain

Overview

Design Brain is the shared knowledge base of the UX/UI team at SkillLane. It holds our standards, product context and team decisions in one place that both designers and AI read from, together with ready-made AI workflows for the jobs we repeat every week.

I designed the system, built it, rolled it out through an AI bootcamp I ran for the team, and I maintain it today. Since July 2026 it has grown to 131 documents and 23 workflows, with contributions from 12 people.

The problem

Before building anything, I asked the team where their time actually went. Everyone logged one week of real work in a shared FigJam board: time spent, how hard each task was and how often it repeated, then a heat map and three follow-up questions.

• The team named about 190 hours a week of work that was both hard and repetitive, roughly the capacity of five full-time designers.
• About 80% of the logged time sat in two themes: high-fidelity UI and design system work, and research plus wireframing.
• Every designer said the same thing about AI: they had tried it, and it did not help, because it did not know our products, our design system or our standards. One designer put it simply: importing a whole Figma project just failed every time.

So the problem was not “use AI more”. It was that the knowledge AI needed lived only in people’s heads.

The idea: one brain before more tools

• Markdown in git. Easy for AI to read, reviewable through pull requests, with full history of who decided what and when.
• Shared rules plus team layers. Brand, voice and tone, accessibility and design system rules are written once and shared by everyone. Each business unit adds only what is different for its own products, so nothing is copied and left to drift.
• Workflows, not prompts. Common jobs became ready-made workflows anyone can run in plain language.
• Evidence by default. Every answer points back to the file it came from, so a designer can check it in seconds.

Every repeated job, one command away

Each workflow encodes how our team does a job, not how a textbook does it: which rules to read, what to check, and what the output must prove. Designers can simply ask in their own words, and the brain picks the right one.

Knowing who is asking

Eight designers each look after different products, and nobody should have to explain that every time. Each person registers once, and from then on the brain knows which team and product they work on, and answers in that context by default. It always says which context it is answering in, because a wrong default nobody notices is worse than asking.

How work flows through the brain

The loop is the point. Every finished piece of work leaves the brain a little more accurate, so it gets better the more the team uses it, instead of staying the same like a tool you buy.

Designing for trust

A system like this only works if people trust it, so I designed the guardrails as carefully as the features.

• Guards that actually run. A scan checks for personal data and secrets before anything is shared, and a second guard stops anyone from changing shared rules without a review.
• Trust, then verify. AI output is always a draft. Anything that goes to a developer or a client is checked by a person who puts their name on it.
• Clear roles. File owners look after their own areas, anyone except the author can review a change, and one maintainer (me) can make the final call, but must record why and tell the owner.
• Freshness is visible. Every document shows its status and a last-reviewed date, and a monthly maintenance pass flags anything going stale.
• Built for designers, not engineers. Team members never type git commands. They start and end their work with one sync, and the system works out what can be saved directly and what needs a review. When git gets stuck, the brain saves their work first and hands it to the maintainer.

What AI does not do here

The team agreed on the boundaries together, and they are written into the brain itself:

• No spatial work on real files. Arranging UI or flows in the real Figma files stays with designers. AI can scan, report and suggest.
• No final visual sign-off. The last judgement on anything delivered is a person’s.
• No invented user needs. The part of a PRD that describes what users actually need is written by people. AI can help structure and check it.
• No personal or confidential data, even when it would make the work faster.

Rolling it out: an AI bootcamp

A tool nobody adopts is just a repository, so I designed the rollout as a hands-on bootcamp.

• Session 1, Claude 101 and Setup Clinic (about 2 hours). Data rules first, then a mental model of how AI works and why it fails, then everyone set up their own machine in the room until all three smoke tests passed.
• Session 2, Design Brain in depth (half a day, three parts). Structure and sync, with a sync drill run three times. Importing each designer’s own product context, asking the brain questions and practising what happens when two people edit at once. Then a full dry run on a real ticket: requirement, research, flow and wireframe, and UI.
• Working agreements. Written together by the team: what AI may and may not do, how AI work is checked before it ships, and what data never goes in.

The result

• 131 knowledge documents covering shared standards and 4 business units.
• 23 team workflows, from UI copy and critique to QA, handoff and design system releases.
• Every designer can set up, sync and run a workflow on their own, and every business unit has its own space.
• In the bootcamp, the team went from a real product requirement to a mockup where every decision traced back to a source, within half a day.

What is next

• Measure it properly. The 190-hour baseline was taken before the bootcamp on purpose. The same audit runs again after one quarter of real use, so the team can compare with numbers instead of impressions.
• Protect the upkeep. One to two hours a month per product owner to review and fill gaps. Without it, the brain goes stale and people wrongly conclude that AI does not work.
• Session 3: working with developers. Handoff and pre-delivery checks, where information falls through the cracks most often.

What I learned

The hardest part of bringing AI into a design team is not the AI. It is getting the team’s knowledge out of individual heads and into a shape that both people and machines can use, and then making it safe and easy enough that people keep it alive.