Design Principle
Good UI patterns are not collections of visual screenshots. They are reusable evidence about task flow, state flow, constraints, and feedback.
Large Theory
Interface patterns should support decisions: where users enter, how they know the next step, how they recover from failure, and how completion is confirmed. A single screenshot loses states and paths.
Small Points
- When researching a pattern, record entry point, main task, key states, error states, completion feedback, and exit path.
- Compare three to five real products for one pattern instead of learning from one brand.
- Copy, control density, defaults, and permission boundaries are pattern evidence too.
- Extract structure, not brand visuals.
Design Judgment
A pattern can enter the knowledge base when it explains why users click, how they correct mistakes, and when they are done. Color and radius alone are not enough.
Implementation Notes
Each pattern entry records task name, applicable page, key states, component parts, mobile behavior, accessibility requirements, counterexamples, and source links.
Counterexamples/Risks
Treating a Dribbble still as flow evidence, ignoring error/empty states, copying brand styling, and failing to separate iOS, Android, and web conventions.
Case Study
Mobbin's public homepage emphasizes searchable real-world screens, UI elements, flows, and screenshot text, with large numbers of apps, screens, and flows. The lesson is that RAG should retrieve by task, control, and flow evidence, not only by style keywords.
Source Links
Mobbin: https://mobbin.com/
Agent Directive
Pattern intake must record task, states, components, mobile changes, and sources; do not store only single-image style descriptions.