Case study
Enaia
Enaia is a commercial real-estate CRM used by teams at CBRE and JLL. I worked directly with the CEO and CTO on design cleanup, an agentic design system, working prototypes and the mobile app.
Design Cleanup
The design and workflows needed an update to provide a trustworthy, modern and professional look & feel.
Agentic Design System
An agentic design system takes a redesign from weeks to hours. Shared foundations, contracts and journey guidance keep both the interface and its workflows consistent with Enaia.
A human instructs the agent or edits any tool directly. Shared foundations and tokens support contracts for components, patterns, behaviors and templates. Journey guidance covers flows across steps and screens. Tools propose changes and conform to approved rules. Mappings identify implementations and their adoption status. Validation returns actionable feedback. Governance reviews proposals before the system changes; the decision journal records the reasoning.
Human
Sets the intent, reviews proposals and decides what becomes part of the system. A human can instruct the agent or edit any design or code tool directly.
“Make this Button feel native on mobile.” The edit can start in any tool; changing the shared rule still needs an explicit decision.
AI agent
Reads the relevant foundations, contracts, journey guidance, mappings and decisions before editing. It composes the appropriate components, patterns, behaviors and templates for the task.
Adoption status tells it to use the current Button, migrate legacy uses only within the agreed scope, and leave protected exceptions alone.
After editing, it runs validation and follows the feedback. A gap in the contract becomes a proposal; the agent does not rewrite the rule just to make its output pass.
Foundations, contracts & guidance
The shared model spans individual controls, screen composition and complete workflows. Product context supplies who the product is for, what people need to do and the constraints they work within.
- Foundations & tokens
- Principles, color, typography, spacing, responsive behavior, elevation, platform conventions and iconography. Foundations define the rules; tokens hold the concrete values.
- Components
- Individual building blocks such as Button, Field or Card: purpose, anatomy, variants, states and accessibility.
- Patterns
- How pieces work together to solve a recurring task. A multi-step form coordinates its fields, progress, validation and navigation.
- Behaviors
- Shared interaction policies such as focus, disabled state, selection, disclosure and field validation. Each implementation declares what it conforms to.
- Templates
- Reusable screen structure: regions, slots, hierarchy and composition constraints. For example, an app shell or a record detail layout.
- Flows & journeys
- Guidance across steps and screens: Next validates before advancing; Back retains recoverable input. Exact steps and business outcomes stay with the product.
- Rules & relationships
- Which pieces compose, conform to or refine others. Detectable requirements become checks; contextual conflicts go to human review.
Enaia keeps journey guidance separate from artifact contracts. Shared behavior contracts have explicit adoption status; a separate flow-contract type remains deferred.
Example: the Button contract
- Purpose & boundaries
- A labeled action. When to use it, when to choose a link, tab, toggle or Icon Button, and what is outside its scope.
- Anatomy & variants
- A required label, optional leading icon, sizes and action hierarchy.
- Appearance
- Blue primary fill, typography, spacing and a radius token. Platform differences must be explicit, approved mappings.
- Behavior & accessibility
- Default, hover, focus and disabled states; accessible names, keyboard activation and focus treatment.
- Composition & content
- How it fits beside other actions, handles long labels and responds to its available space.
- Verification
- Stable requirement IDs, examples, testable expectations and the decisions behind them.
Figma
The mapping connects the Button contract to a component set, its properties, variants and variables. Validation compares that representation with the approved contract.
A designer changes a corner radius. The difference is either repaired to conform or submitted as a proposal to change the rule.
Paper
A canvas is another place to explore and edit the same design intent. Its nodes and styles need a mapping to the contract, just like a code component does.
Trying a rounder Button on the canvas proposes a direction. It becomes shared guidance only after review and approval.
LiveView · production codebase
The contract maps to the Phoenix component, its API and its usage in production. Existing code can contain several implementations with different adoption rules.
Illustrative Button inventory
- Current
- Use for new work; validate against the contract.
- Legacy
- Migrate when its surface is in scope; do not add new uses.
- Protected exception
- A known mismatch. Leave it unchanged until the recorded constraint is resolved and its owner approves.
React · prototyping mirror
A separate implementation for fast prototypes, using the same semantic contract. The React mapping translates properties, tokens and states into its own API.
A prototype Button and a Phoenix Button can use different code while satisfying the same requirements. A prototype does not become the production authority by accident.
Any other tool
Another canvas, framework or native platform can join through a mapping and a way to check its output. The contract does not depend on one vendor.
A native Button can follow platform conventions where an approved mapping allows it. Unsupported or unverified requirements stay visible; they do not silently count as passing.
Mappings & adoption status
Mappings connect a stable contract ID to real files, functions or design nodes. They translate properties and states and identify how each requirement can be checked.
Alongside them, the adoption manifest records which implementation is current, which needs migration, whether new usage is allowed and which exceptions must be preserved.
action.button → Figma component set · Phoenix function · React component. One meaning, with an explicit address and status for each implementation.
Validation & feedback
The checker reads the relevant foundations, contracts and mappings, then inspects the implementation or rendered result. It checks composition and behavior as well as individual components. Feedback names the requirement, location, expected value, observed value and next action.
Example · Button / disabled state
- Expected
- A disabled Button cannot activate.
- Observed
- It looks disabled, but still responds to a click.
- Action
- Use native disabled behavior in the mapped implementation; re-run the check.
Evidence is tied to the checked contract and mapping versions. Missing or stale evidence is not a pass. Changes to the rule itself go through governance.
Journey checks validate rule references and their links to feature tests. Whether guidance fits the task, or conflicts with other guidance, still needs review.
Governance
Decides who can approve a change, which surfaces adopt it and how exceptions expire or get revisited. Validation supplies evidence; human review decides whether to repair the implementation or change the contract.
A different Button radius may be drift or a valid platform convention. An accepted proposal updates the rule and mapping, defines migration scope and triggers fresh validation.
Decision journal
Records what was decided, by whom, when and why, with alternatives, evidence and any decision it supersedes. Entries distinguish design decisions from business or technical constraints.
Example · design decision
“Use the shared Button radius on web. Follow native platform conventions where explicitly mapped, instead of prescribing one fixed radius everywhere.”
Rationale: preserve a familiar native interaction. Record the affected platforms, approver and evidence with the decision.
The journal preserves the reasoning. Current mappings and readiness records say what is approved and usable today.
Read about the process in Building an Agentic Design System and From Pipeline to Governed Artifacts.
Prototyping
JEV, Enaia’s AI command bar, turns plain-language requests into interfaces and actions.
Mobile app
Five desktop sections, five tab slots, and requests to give search and reminders more room. I used session data to question the proposed navigation and work through the alternatives.
“I wish we’d had you when we started this.”
“Josef works across visual design, UX and front-end, and takes his own work from idea to shipped rather than handing off mockups. That combination is genuinely rare, and ideal for startups.”