How I use AI in my design practice

An assistant could correct a spacing value in one session and choose the wrong value again in the next. I needed a way to carry the correction into later work.

I wrote standing guidance for visual design and implementation, with separate instructions for each project. The visual guidance names the spacing values, type weights, corner relationships, and motion choices I use. When a project has an established design system, that system takes precedence.

“Use good spacing” leaves the decision open. A written scale records the values I want and gives me something to check.

Instructions still need verification. I added a check that examines new edits for unsupported values and reports them while the assistant is working. It looks at the change itself so an unrelated problem elsewhere does not block every edit.

The component library also has a separate verifier that I run before publishing. It checks properties I can define precisely, including typography relationships, contrast, and the order of colors in the gray palette.

I added those checks after review exposed problems. One gray was in the wrong position, changing the hierarchy of surfaces. A translucent panel was difficult to distinguish from its background. I could check for both problems in later work.

This verification work belongs to the wider library.

Blueprints began as an offline publishing tool. Later, other designers needed a shared place to publish specifications and discuss revisions. The assistant resisted internal hosting because the project guidance still described the original offline goal.

I updated that guidance to account for both needs. Local exports still served people working offline; internal publishing supported teams discussing the work together.

I update the instructions as the product changes. For larger projects, I document features separately, including the decisions they depend on and the responsibilities that belong elsewhere. Each task gets the context it needs, and I can revise earlier decisions when they no longer fit.

I find myself repeating fewer visual instructions in my daily work. I have not measured that change.

I still review the composition and try the interactions myself. A check can identify an unsupported color or a weak focus ring. I need to decide whether the page gives the right information priority, whether a control belongs there, and whether someone can finish the task.

I review what happens when someone presses again, changes direction, enters an incomplete value, or returns from another view. I use Rauno’s interaction examples and Apple’s fluid-interface session to guide that review: response, interruption, continuity, and commitment.

In Agentic UI, I check whether clearing search leaves the field ready for another query, whether an invalid number remains available to correct, and whether Back returns to the same expanded section and control. I review every part of the control, then repeat the review where it is used.

Each iteration now starts by giving specialists a named component, its consumer, and the problem to resolve. Their findings must lead to a specific decision and an observable check before I change the UI. I save that kickoff with the unchanged source, then compare the implementation with the decisions that started it.

I keep a review tree with the component source. For each part, I record its web references, Apple comparison, relevant states, and design decision. Source hashes identify when evidence is out of date, and each acceptance condition has its own result. Kit measurements stay unresolved until they can be checked.

The reference repository records the twelve resources linked by Rauno, including which texts were read and which media could not be reviewed. These working examples establish what the prototype does. They do not establish adoption or measured usability gains.