Adam Hickey Minneapolis, most days.

Senior Product Designer

Product design for software that got complicated.

Twenty years in enterprise software taught me where judgment matters. Now I design how people and coding agents build together.

See selected work Start a conversation

Design systems that people and agents build from
Prototypes working ones, built with Claude Code
Accessibility built in, not bolted on
Complex workflows operational software, up close
Agent boundaries what it does alone, what needs a person
Research through to shipped product

Selected work

Three accounts that show the whole job: understand a complicated system, find the real decision, get product and engineering around it, and carry it into something that works.

Making 40+ enterprise apps feel like one product

Systems, governance and scale: one design system and one accessibility standard across 40+ apps, with the numbers to show for it.

Enterprise software Design systems Governance

One real-time view of a 450+ truck fleet

A complicated operation learned from the floor: cards built for the speed of the dispatchers, and the map I was wrong about.

Logistics Real-time data Operations software

Grant tools unified into one trusted platform

Research, accessibility and a measured change: one portal replacing spreadsheets, and a 45-to-55-hour process down to just over ten.

Public sector Accessibility Platform consolidation

Lab · current exploration

When coding agents join the team, where does design judgment go?

Into the rules, the boundaries, and the decisions that still need a person.

As agents do more of the work, human judgment becomes the design challenge. Agent Review is a working prototype for supervising coding agents without reviewing every action: it tells apart what an agent can finish on its own, what needs a person’s judgment, and what needs explicit approval.

Read the case study Open Agent Review (opens in a new tab)

Automation found no errors. Judgment found a question.

Automated checks Lint Pixels Accessibility All passed. Nothing on the screen moved.
Still open One red means a failure and a replaced plan. The checks can’t choose the fix.
Needs judgment Replaced valuePlan ~~Starter~~ , now Growth FailurePayment failed Separate them, or keep the familiar red? Separate the meanings Recommended Keep the red for now
Kept, with its reason The decision and why stay with the work. Three more changes follow it.

Also in the lab: Deploy Console · Dispatch Cockpit, and the lab index.

How I Work

What I do inside a product organization

Nearly all of this was done with product owners, engineers, analysts and executives, on products none of us owned alone. Four things I bring to a team. Each has a page: how it goes, step by step, and where it is shown.

Tangled cords on the left, three straight parallel lines on the right: an ambiguous problem sorted into decisions taken one at a time.

Turn ambiguity into a decision

The problem in one sentence everyone recognizes
The decisions in order, one at a time
A direction tangible enough to argue with

A loose pile of hand-sketched index cards beside a tidy grid of identical stamped ones: one design system every team builds from.

Set standards other teams adopt

One design system across 40+ SAP apps
Quality checks written into the release process
Teams trained until UX was their own job

Loose, unclaimed pages beside the same pages squared into one stack under a paperweight: the design owned by one person inside the team.

Own the design inside the team, not beside it

Learn the job before redesigning the tool
Engineering in the room from the first sketch
Change course when users prove the first idea wrong

Dozens of sketched sticky notes thinning out toward one paper airplane on a drawn runway: many ideas narrowed to one working prototype.

Carry the direction into something that works

A working prototype in days, built with coding agents
Engineers for leverage, not rescue
A build, kill or park call made on evidence

What changes when agents can build

For most of my career, design ended at the handoff.

I drew the blueprint. Someone else built it. Months later, we found out what survived the translation.

Now the building is the fast part.

I build what I design, with coding agents. Working software in days, not months. And an agent grows every branch it’s asked for, plus a few it wasn’t.

The judgment didn’t go away. It moved.

Growing is easy. Pruning is the craft. My work now is deciding what stays: the rules an agent reads first, the checks every change must pass, and the calls only a person should make.

See it in Agent Review

Built end to end

Real products, not concepts: designed, built and handed over, each left with the person it was made for and a way to keep it current without me. Both built with coding agents. This site is built the same way.

For my sister

Door County Found

A regional travel guide where every place is structured data rather than a blog post, so dog-friendly and vegetarian work as real filters instead of tags. I built the product, the identity, and the editing workflow my sister uses to keep it current.

Visual identity
Information architecture
Astro build

How I built it Open the site (opens in a new tab)

01 Built for one dog in particular
02 Today’s session, already chosen
03 End on a win, next one queued

For Lucy

Lucy Learns

A mobile app that turns a professional trainer’s handouts into guided sessions you can run with a leash in one hand. One instruction per screen, a live rep tally, and progress in the levels the trainer already uses. Installs to the phone and works offline.

Product design
Illustration
Mobile / PWA

How I built it Open the app (opens in a new tab)

Working on something like this? Start a conversation. There are other things I make, too: a book, and identity and illustration for clients.

About

Adam Hickey is a senior product designer in Minneapolis, Minnesota, who works on software that has grown complicated: enterprise platforms, design systems, operational workflows, and how people and AI agents work together, after twenty years in enterprise consulting and studio design.

Complicated software is my favorite kind of problem. It took twenty years and two careers to be able to say that.

Craft · 2005-2013I started in graphic and digital design and spent eight years as a hybrid designer / developer across three studios, the last five at Pixel Farm. Two iOS apps, a boat configurator for Lund, and the front end under a lot of it. Designing and building weren’t separate jobs yet, so I did both, in a room where whoever shipped it sat close enough to argue with.

Systems · 2013-2026The work grew into UX and product design, and then into thirteen years at RBA consulting on large enterprise products, for CBRE, Toro, Banner Bank, International Trucks. That’s where I learned that most design problems are communication problems, and that coherence at scale takes systems: design systems, governance, shared patterns, honest measurement. The longest engagement was building and operating a UX practice inside a global enterprise — some of it explained in public, to a user group with the same problems.

Building with agents · 2026–nowAfter thirteen years at RBA, I’m building independently with coding agents: two products in use, client work, and an exploration of what happens when AI becomes an actor inside the product and inside the team that makes it. Agent Review asks where an agent’s autonomy should stop, what a design system needs to tell it, and how a person’s judgment becomes structure it can reuse. It feels less like a departure from twenty years of UX than the place those years were leading. What I want next is one team and a product complicated enough to be worth years.

What I still look for is whether the work keeps guiding people long after the project ends. Not whether the deliverables were good, but whether the team is better at this than it was. That’s the test.

Lucy (Lucy approves of this message from her curled-up spot nearby)