Reuse, with constraints.
Search within canonical libraries. Use an existing component and a verified variant. Apply the relevant product pattern.
Workhuman / Recognition / AI-assisted design
Before the output,
get the context right.
I built a context system that helps an AI assistant work with the product we actually have: the right components, documented patterns and decisions that survive the next session.
Explore the context gate ↓
Context decision map
A good answer can be
“I need a reference.”
The available context determines the next step. Both outcomes are shown below.
01 / RequestDesign a product interaction.
A plausible layout is not enough. It must belong to the product.
Designer correctionsCanonical foundationsProduct patterns
Ask for a reference.
The assistant explains what it does not know and asks for a reference or confirmation. A hypothesis does not silently become a design rule.
Architecture illustration based on the skill and decision records. The diagram explains the documented rules; it does not connect to company systems.
The starting point
Plausible design.
Wrong product.
Early AI-assisted work exposed three different problems. A better prompt alone could not resolve all three.
Wrong source
An unrestricted component search could surface archived libraries ahead of the current system.
Constrain where the agent looks.Wrong construction
The assistant could recreate a component or choose a variant without checking that it existed.
Verify before instantiating.Wrong interaction
Correct-looking components could still be assembled into a flow that did not match the product.
Make product patterns explicit.I built on existing foundations owned by another team. The new work was the Recognition-specific context: how components are used, which decisions apply and where the assistant must ask rather than infer.
Learning through use
Media was the pilot.
The structure changed with it.
Applying the system to a real feature exposed where reusable rules and application-specific behaviour were mixed together.
- 01 / Build
Establish the gate.
Read the relevant context before design work begins. Constrain component search and stop when a required pattern is missing.
Documented implementation - 02 / Apply
Work through Media.
I tested the approach on Media within Recognition. A real feature gave the context structure something concrete to support.
Applied in my practice - 03 / Reorganise
Separate responsibilities.
I reorganised the context after the pilot, separating reusable feature knowledge from how it behaves in a particular application.
Reorganisation completed - 04 / Refine
Make it easier to extend.
I am continuing to improve context selection, durable decisions and the structure needed to support more design work.
Ongoing refinement
What changed after the saved planning snapshot?
The September planning document describes the intended reorganisation. I subsequently confirmed that I completed the reorganisation after testing on Media. That updates the planning snapshot; it does not mean every proposed phase or distribution mechanism has been completed.
Plugin distribution, shared review processes and index-size targets remain separate roadmap items in the available evidence. No measured time saving or wider team adoption is claimed here.
Architecture
One feature.
Different places to use it.
The context needs to explain both what a capability does and where it lives. These responsibilities should be independently understandable.
Existing foundationsTokens · components · accessibility guidance
Consumed as source material; not recreated or claimed as my invention.
Feature contextWhat the capability does
Media, captions and their behaviours across states. Knowledge that can apply in more than one product surface.
Application contextWhere the capability lives
The container, layout and interaction constraints of the surrounding flow. A modal and a full screen can share a capability without sharing a layout.
Component contextWhat can be reused
Verified component identity and properties, paired with curated guidance explaining when and why to use it.
Decision records
Why a choice was made, its scope, its status and what remains unresolved.
Conceptual view of the context responsibilities. Updating the written context does not automatically update existing Figma frames.
Why a routing index needs more than filenames
An index helps the assistant choose what to read. The useful instruction includes a condition: open the component guidance before choosing a variant, or consult the application context before placing a feature.
The initial index had accumulated long descriptions and session history. The evolution plan moves detail into the relevant documents and keeps the routing layer focused. The goal is selective reading, not an invisible indexing engine.
Durable design judgment
A correction should outlive
the conversation.
The system distinguishes extracted facts, confirmed decisions and hypotheses. The assistant should know which kind of statement it is using.
Extracted
A property or variant read from the source component. Keep its origin clear; do not replace it with an assumption.
Confirmed
A design rule validated by the designer and recorded with its scope. This can inform subsequent work.
Hypothesis
An interpretation that still needs confirmation. If it is the only basis for a design choice, ask before proceeding.
A concrete decision
One component.
Two supported flows.
An existing modal contained both confirmation and approval/rejection behaviours. I chose to expose the differences through properties rather than remove them or split the component into separate families.
The record preserves why the choice was made, how the mobile actions were reorganised and which defaults still required a decision.
Decision record · Modal
- Choice
- Retain one component; expose the supported behaviours.
- Reason
- Keep the shared structure maintainable without separate sets drifting apart.
- Still open
- A secondary-action default and inherited visual differences.
- Recorded state
- Edited in the design file; not published in that record.
The value is not just remembering the final answer. It is preserving the trade-off and the uncertainty, so the next session does not start from the same assumptions.
Evidence and next steps
Built locally.
Refined through practice.
The gate, context documents and dated decision records provide the foundation for this story. My Media pilot and subsequent reorganisation describe the next stage of the work.
What the saved records establish
The August verification record describes scoped component-search results and a blind test in which the assistant requested a reference instead of inventing a pattern. These are historical checks documented at the time, not tests repeated for this page.
The source package also contains curated component guidance, product patterns and dated decision records. I designed the context system with AI assistance for writing and execution.
What I am continuing to refine
How to keep routing instructions concise, preserve the distinction between reusable and application-specific knowledge, and make reviewable decisions easier to carry into subsequent tasks.
The broader roadmap includes distribution and shared review. Those require their own implementation and validation; the documents do not establish company-wide adoption or production outcomes.
Sources: design-context specification and gate verification record, August 2026; modal decision record, August 2026; context evolution plan, September 2026; my subsequent account of the Media pilot and reorganisation. Diagrams are portfolio illustrations, not company interface screenshots.
From the source
The rule, as written.
Context gate — RCS design
Before any visual decision, run the steps below in order. Do not skip. Do not draw before finishing.
1. Read Bruno’s context first
Read in this order:
• [internal path removed] — how he works (stable)
• [internal path removed] — dated log of specific corrections (append-only)
If either is missing, continue and note this in the response.
This layer comes first on purpose: an explicit correction from Bruno overrides any documentation, including Terra and this gate. When decisions.md contradicts preferences.md, the latest entry in decisions.md takes precedence.