# Adam Hickey

> Senior product designer in Minneapolis, Minnesota, who builds what he designs, for complex enterprise software: enterprise design systems, modernizing legacy products, agentic workflows and embedded senior product design. He designs the infrastructure behind great design: design systems that people and AI coding agents build from, working prototypes built with coding agents to find out what is worth building, and the line between what software does alone and what a person decides. Product design for software that got complicated, plus identity and illustration made end to end. Twenty years inside enterprise platforms, design systems, and products that outgrew their original shape: eight as a hybrid designer and developer, thirteen designing the systems other teams built from, and now both at once, with coding agents. Open to a senior product design role: in-house, remote or hybrid in the Twin Cities, with a team that can hire in Minnesota. Also available for select independent engagements.

Contact: adam@adamhickey.com. LinkedIn: https://www.linkedin.com/in/adamdhickey/

Every page is plain HTML with its content in the markup; nothing is rendered by script. Each page carries a canonical URL, an Open Graph card and a schema.org graph (Person, ProfessionalService, WebSite, WebPage, Article, FAQPage, BreadcrumbList), and https://adamhickey.com/sitemap.xml lists all thirty-four pages with a last-modified date.

## How I work

Four things I bring to a product team, now that agents build too, one page each: the situation, how it goes step by step, and the account that shows it. The same work is also on offer as an independent engagement, in one sentence at each page's close.

- [Build to find out](https://adamhickey.com/engagement/working-product-prototype.html): a working prototype in days, built with coding agents, engineers deciding with something real in hand early, and a build, kill or park call made on evidence.
- [Build the system everyone builds from](https://adamhickey.com/engagement/design-system-foundation.html): one design system across 40+ SAP apps, rules written down so new teams and agents follow them without asking, and checks on every change so quality holds without me in the room.
- [Own the design inside the team, not beside it](https://adamhickey.com/engagement/embedded-senior-product-design.html): learn the job before redesigning the tool, engineering in the room from the first sketch, and a change of course when users prove the first idea wrong.
- [Turn ambiguity into a decision](https://adamhickey.com/engagement/product-clarity.html): the problem in one sentence everyone recognizes, the decisions in order and which ones stay with a person, and a working version to argue with rather than a deck.

## Writing

Ten articles: one to start with, then nine in three collections named for its three words: the system people and coding agents build from, the build, and the judgment of where a person decides. Each answers in its first paragraph a question people ask about complicated software before they know who to ask. The index is at https://adamhickey.com/writing/index.html.

Start here:

- [What makes a good product designer now?](https://adamhickey.com/writing/what-makes-a-good-product-designer-now.html): the position the rest of the site argues, the infrastructure behind great design. Coding agents made building fast, so a bad decision travels further and the designer's work moved to what the building is made from: a design system that says what each part means to builders who can't ask, told through Agent Review's quiet cancel link, where the agent's fix would have let any later agent play down any action and the designer knew what the code didn't; building to find out rather than to produce more, told through Lucy Learns's three tries at moving a session forward, the third not built yet; a clear line between what software does alone and what a person decides; and twenty years in three eras, craft, systems, agents, that put quality into checks. Its one outside source is Netflix's design system team.

The system:

- [What changes when AI agents join the product team?](https://adamhickey.com/writing/what-changes-when-ai-agents-join-the-product-team.html): the design system stops being a library people consult and becomes the instructions a builder follows, and an agent cannot ask what you meant. So a system writes down what each part means as well as how it looks, builds a paved road with marked exits rather than a fence, gives an AI draft its own state until a person owns it, and reviews a rule as carefully as a screen, because a rule repeats on every screen an agent builds. Credited to Netflix's design system team, worked through Agent Review and the SAP program.
- [What a design system needs to explain to an agent](https://adamhickey.com/writing/what-a-design-system-needs-to-explain-to-an-agent.html): components and tokens tell a coding agent what to build with, and it also needs what each part means, how it behaves, where the usual answer holds and where it does not; worked through a hand-built cancel link in Agent Review's simulated run, which passes every check whichever direction is chosen, and an account of where a reviewer's answer belongs, a better test, a clearer rule or a written condition, not always a new rule.
- [What does a design system need once AI is in the product?](https://adamhickey.com/writing/what-does-a-design-system-need-once-ai-is-in-the-product.html): six things a system built for facts needs once AI hands it claims: a slot for a value's source and age, a pending state rather than a spinner, a refusal that can never be mistaken for a suggestion, a reversible action whose pattern says what reversing means, an ink for text the system wrote, and checks that can reach the new states.

The build:

- [What is a product designer for, when anyone can build?](https://adamhickey.com/writing/what-is-a-product-designer-for-when-anyone-can-build.html): understanding why something matters, making it real fast enough to find out, and knowing when it isn't good enough. The handoff and the walls between roles coming down, a working prototype as a question whose value is the assumption it breaks, when to stop generating and go get evidence, what a prototype should hand on to the next builder, and why knowing enough engineering to test an idea is not owning production. Credited to Ryan Brownlow's Korl, worked through Door County Found and Faunaform.
- [What should a working prototype actually prove?](https://adamhickey.com/writing/what-should-a-working-prototype-actually-prove.html): whether the idea is worth building, in real code on real inputs with the people who would use it, ending in a build, kill, or park call.
- [How should you test a product now that AI can help?](https://adamhickey.com/writing/how-should-you-test-a-product-now-that-ai-can-help.html): let agents find what's broken, let people show you what they misunderstand, and let the numbers say how often. What an AI agent checks well and what only a person can tell you, why a synthetic user agrees with everything and is better used as rehearsal, watching a few people on real tasks where they'd do them, analytics that say where to look rather than why, and a loop of feedback at three speeds. Drawing on Nielsen Norman Group's research on synthetic users, worked through Lucy Learns and Agent Review.

The judgment:

- [Who decides when software can act on its own?](https://adamhickey.com/writing/who-decides-when-software-can-act-on-its-own.html): the person accountable for the outcome, and the design work is making sure they really can. An interface as the terms of a delegation, from answering to acting alone; a nudge and a push that look the same in the metrics; confidence in AI that quietly replaces checking it; appropriate reliance rather than maximum trust; an approval that is oversight only when a no costs no more than a yes; and what a system says when it does not know, as a pattern in the design system. Drawing on Microsoft Research and Carnegie Mellon, worked through Dispatch Cockpit.
- [Enterprise AI should help people decide, not just answer](https://adamhickey.com/writing/enterprise-ai-should-help-people-decide-not-just-answer.html): the evidence beside the recommendation, calibrated rather than maximal trust, controls that have a real effect, and the decision rather than the acceptance rate as the measure, worked through the Dispatch Cockpit dispatch prototype.
- [What does a person need to supervise an AI agent?](https://adamhickey.com/writing/what-does-a-person-need-to-supervise-an-ai-agent.html): an agent is a run of decisions rather than one, so the person supervising it needs the line between what it does alone and what it asks about, drawn where a mistake gets expensive; an approval that carries its evidence; a record the run can be reconstructed from by someone who was not there; three kinds of stop, including handing a half-done queue back; an instruction they can test on last night's cases before it runs; and a measure of what they caught rather than what the agent finished.

Five more articles keep their addresses but are no longer on the index:
- [What makes an interface feel finished?](https://adamhickey.com/writing/what-makes-an-interface-feel-finished.html): type on a scale, color as a measured pair, motion as a duration and a curve with a rule about interruption, a decision for every state, spacing from tokens, and the checks that hold all of it; craft as a list you can name and measure rather than a mood.

- [What does a product design engineer actually do?](https://adamhickey.com/writing/what-does-a-product-design-engineer-actually-do.html): the component as the deliverable, tokens that flow one way, pull requests as design reviews, prototypes on a branch, motion you can review, and the checks that hold the system, worked through Agent Review, with a plain account of what one project does and does not show.
- [What does a developer need from an interface on a bad day?](https://adamhickey.com/writing/what-does-a-developer-need-from-an-interface-on-a-bad-day.html): the screens a developer opens most are the ones that open when something broke, so the error message, the empty state, the log and the first ten minutes are the product; what happened, to what, why and the one thing to do next, in the five-question order developers ask, on a page dense enough to scan in a hurry.
- [Designing for the moment the workflow breaks](https://adamhickey.com/writing/designing-for-the-moment-the-workflow-breaks.html): what an operational user needs when an order stalls or a transaction fails; separating what the system knows from what it assumes, and designing the recovery rather than the warning alone, followed through one illustrative order.
- [What I learned standardizing UX across 40+ SAP Fiori apps](https://adamhickey.com/writing/standardizing-ux-across-40-sap-fiori-apps.html): one style guide and component library, feedback loops, checks in the release process, and teams that own it; design-to-development time down by about a third and production UI defects by roughly half while the program ran, with how each was counted and what it cannot show.

## Case studies

- [One real-time view of a 450+ truck fleet](https://adamhickey.com/case-study/dispatch-complexity.html): lead product design for Midwest Couriers, a research-led dispatch cockpit.
- [Making 40+ enterprise apps feel like one product](https://adamhickey.com/case-study/sap-product-maturity.html): lead UX for a global corporation's SAP Fiori suite, under a governed design system and an accessibility standard.
- [Grant tools unified into one trusted platform](https://adamhickey.com/case-study/usda-operational-overhead.html): lead product design for the USDA-backed Nutrition Incentive Hub.
- [A global innovation network on one brand and platform](https://adamhickey.com/case-study/innovators-studio-visual-identity.html): identity and a multi-year internal platform for a worldwide innovation network.
- [13 years designing enterprise software](https://adamhickey.com/case-study/enterprise-consulting.html): the RBA years, 2013 to 2026, for CBRE, Toro, Banner Bank and International Trucks.
- [8 years as a hybrid designer / developer](https://adamhickey.com/case-study/hybrid-designer.html): three Minneapolis studios, 2005 to 2013, the last five years at Pixel Farm.

## Built end to end

Products designed, built and illustrated alone.

- [How I built Door County Found](https://adamhickey.com/case-study/door-county-found.html): a curated travel guide where every place is structured data, built on Astro and edited through a web form. The guide itself is live at https://doorcountyfound.com.
- [How I built Lucy Learns](https://adamhickey.com/case-study/lucy-learns.html): a dog-training app that works offline, built for one household, told as three tries at its session screen: voice commands that the dog heard as hers, a timer that broke on the pauses of real sessions, and a teleprompter that is the next version and not yet built. The app itself is live at https://adamdhickey-collab.github.io/lucy-learns/, and the write-up embeds it at a phone's width.
- [How I'm building Faunaform](https://adamhickey.com/case-study/faunaform.html): a screen-print studio for Minnesota wildlife art, in progress: seven animals, each drawn for one hour of one day, to be printed by hand in four flat inks. An AI image model draws from written briefs, studio software built with Claude Code makes every drawing printable (exact inks, every shape too thin for a screen marked at six inches, curves, film-ready screens), and every call about the art is his. The seven prints simulated on paper, and the black bear from museum and Cosmos references to its four screens. Nothing is printed yet, and the page says which pictures are simulations.
- [How I built While We're Here](https://adamhickey.com/case-study/while-were-here.html): a 300mm square hardcover of essays produced from HTML and CSS through a paged-media engine.
- [How I built this site](https://adamhickey.com/case-study/this-site.html): thirty-four pages of plain HTML with no framework and no build step, three token files under four normative specs, and eleven checks that measure the rendered page before anything ships.

## Lab

Design systems for humans and agents: experiments in what design has to supply once coding agents build, in React, AI-assisted prototyping, component systems and interfaces where design decisions survive into code. Self-directed, on synthetic data, built end to end. The index is at https://adamhickey.com/lab/index.html; it opens with the position article above as its introduction and lists the prototype below as well.

- [Agent Review: where design judgment goes when coding agents join the team](https://adamhickey.com/lab/agent-review.html): a case study with a working prototype and a public Storybook, asking what a product designer does all day once a coding agent can build the interface. The prototype follows one feature, archiving customers in a made-up product called Relay, through six stages, each saying what the designer does and what the agent does: Discover, where the agent summarizes the evidence and marks each line an observation, interpretation or assumption, and its claim that archiving deletes data is contradicted by an engineering note (records are kept 90 days); Define, where the designer sets what wins when speed and safety conflict; Explore, three working archive screens built from the design system (archive then undo, confirm first naming active customers, review the batch), tried on one batch; Evaluate, where findings become requirements and the designer can choose against the agent's recommendation with a reason; Delegate, where the brief is written from those choices and the agent builds inside written boundaries, says what each check established, and stops once (for approval of a new pattern, or for judgment on what "active" means); and Learn, what was verified, what is unknown, what to measure, and a rule kept only if the designer keeps it. Two more simulated runs show the stops in detail: a small gray "Cancel subscription" link built by hand among the system's Buttons, where the agent recommends a quiet Button variant and the designer chooses, against it, an exception that ends in two weeks and a change of its own, owned by product design; and a fix in a table forty screens share, which needs the table owner's approval. Everything in the scenarios is simulated and labeled so, and none of it has been tested with users. It grew out of a real experiment: Claude Code was asked to add bulk actions to a customer table inside a React component system with tokens, stories and twelve design rules, once with the rules and once without, and an intentionally flawed version tested whether the automated checks (a token lint, axe on every story, a viewport check, visual baselines) caught planted defects. The prototype is at https://adamdhickey-collab.github.io/agent-review/, the Storybook at https://adamdhickey-collab.github.io/agent-review/storybook/, and the source, design rules and experiment record at https://github.com/adamdhickey-collab/agent-review.

## Prototypes

Self-directed, interactive, on synthetic data. Design work, not client work and not shipped software.

- [Dispatch Cockpit: an AI recommendation the dispatcher can check and overrule](https://adamhickey.com/prototype/dispatch-cockpit.html): human-in-the-loop AI decision support for freight dispatch, built around a hypothesis: a dispatcher spends less time reconstructing a recommendation when the interface shows what needs checking. The factors weighed with their values, where each stands and when each was last true, a close call that names its tradeoff and flags a stale figure rather than picking, outcomes on similar loads with the late ones open to inspection rather than a confidence percentage, a federal hours-of-service limit the system enforces before it scores and nothing on the screen can argue past, a one-click override of the ranking that asks why afterwards and says what it does with the answer, and the whole fleet always on screen. The interface is functional and the ranking is computed on the page; no model or dispatch system is connected. Informed by the Midwest Couriers cockpit; every figure invented, and it has not been tested with dispatchers.
- [Designing motion with Claude Code](https://adamhickey.com/lab/designing-motion.html): an exploration of motion and interaction, last in the lab. A three-step scroll story that sat on the homepage until 2026-10-21: as the reader scrolls, a blueprint is handed off, a tree grows every branch at once, then it is pruned and bears fruit, the argument of the position article drawn as one anime.js timeline whose playhead is the scroll position. Each step holds on a finished state; reduced motion jumps between those states, and without JavaScript the finished drawing stays.

## Optional

- [Homepage](https://adamhickey.com/): the person, selected work (three enterprise case studies (SAP, USDA, then dispatch), then the lab, introduced by the position article and tested by Agent Review), how he works inside a product organization (four cards, one page each), four things built end to end, and About. The four things he brings to a team have pages of their own, listed above.
- [Design system](https://adamhickey.com/design-system/index.html): the tokens, type, spacing, corners, motion and components behind the site, every value read live from the stylesheets; component states cloned from the CSS, the eleven checks that hold every page to it, a decision log of the audits behind each part, and a tokens.json export in the W3C format.
- [Other things I make](https://adamhickey.com/other.html): the book, and identity and illustration work for clients.
- [Résumé, detailed (PDF)](https://adamhickey.com/Adam%20Hickey%20Resume%20%28detailed%29.pdf): every role, project, capability and tool in one column. The shorter two-column copy the site links is [here](https://adamhickey.com/Adam%20Hickey%20Resume.pdf).