The Design Intelligence Framework is a knowledge and reasoning layer that keeps the evidence, assumptions and trade-offs behind design decisions explicit. It’s how I bring AI into design work: I built it, tried it on a real brief, and checked what actually helped.
documents across seven layers
real decisions turned into reasoning cases
gaps it caught in a real brief
behaviours only users could show
Teams already have research, principles and benchmarks. What gets lost is the reasoning that connects them, and AI without that context gives advice that’s right in theory and wrong for the product.
So I built what the model reasons with, not more prompts.
I designed the architecture and the quality bar; AI helped me write, compare and check consistency. The highlighted layers turned out to carry most of the value.
One source of truthEarly on, three documents described the same process slightly differently, so the model had several “correct” orders at once. I split them so each rule lives in one place.
The fare bundle brief from Pegasus. I ran it after the usability test, so I could check what the framework saw against what users actually did. See the bundle case →
Used: the short core rules and one brief-review file. Readiness: needs clarification.
The trial showed the short core did most of the work. Before adding anything, I measure.
Ten real requests: brief reviews, design reviews, decisions, research plans.
Run them with and without the framework; score against the gold standards.
Keep the core and the decision cases; merge each domain into one file.
Same ten requests. Quality must hold with less.
Only then, a real project at work.
Read the storyWhy and how I built it, in Turkish: On Medium ↗
“AI helps me ask better questions early. Users still answer them.”
It’s most useful on the brief: naming the real decision, the missing measure, the risk.
No model predicted the misclicks or the overconfidence. The test did.
I spent too long optimising a system I hadn’t proven. Now I measure first, and keep less in one place.