# Adam Hickey

> Senior product designer in Minneapolis, Minnesota, for complex enterprise software: enterprise design systems, modernizing legacy products, agentic workflows and embedded senior product design. 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, and now building working software with coding agents and asking what product design becomes as agents take on more of the work. Open to a senior product design role: in-house, remote, 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-two pages with a last-modified date.

## How I work

Four things I bring to a product team, 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.

- [Carry the direction into something that works](https://adamhickey.com/engagement/working-product-prototype.html): a working prototype in days, built with coding agents, engineers for leverage rather than rescue, and a build, kill or park call made on evidence.
- [Set standards other teams adopt](https://adamhickey.com/engagement/design-system-foundation.html): one design system across 40+ SAP apps, quality checks written into the release process, and teams trained until UX was their own job.
- [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, one at a time, and a direction tangible enough to argue with.

## Writing

Nine articles in three collections named for what a team is hiring for: designing with code, enterprise and operational software, and AI as the material. 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.

Designing with code:

- [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 Agent Review's two reds, which pass every check whichever token is used, 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 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 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.

Enterprise and operational software:

- [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 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.
- [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.

AI as the material:

- [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 Second Look 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.
- [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.

One more article keeps its address but is no longer on the index:

- [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.

## 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 as an enterprise design consultant](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, with the AI tools run from a terminal instead of a chat window. 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 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-two pages of plain HTML with no framework and no build step, three token files under four normative specs, and ten checks that measure the rendered page before anything ships.

## Lab

Design systems for humans and agents: experiments 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 and lists the two prototypes 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. Agent Review is an interactive prototype for knowing when an AI coding agent should proceed on its own, ask a person to decide, or wait for approval, so a team can supervise its work without reviewing every action. It tells three kinds of work apart: routine work the agent handles and records; missing intent, where more than one answer is reasonable and no test can say which the product means, so a person decides; and a permission boundary, where the agent knows how to make a change that is beyond its authority, so the right owner approves it. It shows results first (what was done, what the checks verified, what is unresolved), job boundaries written in plain words rather than confidence scores, completed work that can be inspected and reverted, and answers a person can keep as rules with a scope, a reason and an owner. It plays two simulated runs, static scenarios and not an integration: one red that means a failure on one screen and a replaced value on another, where the agent proposes two defensible fixes, recommends one, says what it can't determine, and a person decides the trade-off and leaves a decision record with their reason; and a fix in a table forty screens share. 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.

- [Second Look: 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.
- [Rollcall: a broken deploy the developer can read and roll back](https://adamhickey.com/prototype/deploy-console.html): a multi-service deploy console for the moment something broke, built around one hypothesis: arrange the screen in the order developers ask their five questions (what is live, what failed, what changed, what depends on it, can I put it back) and they stop reconstructing the story from the parts. The deploy serving traffic kept apart from the deploy most recently attempted; a failed build gathered into what failed, on which line, what changed since it last built with the commit that touches the named file marked as a suspect, what depends on it, and the one thing to do, with the log one step down; a deploy that succeeded and is erroring treated as a reading rather than a refusal, its figures set beside the figures before it; a rollback previewed as a coordinated act, every service a row whether it changes or not, with Undo where the button was and a record of who decided, when, from what to what and on which figures; an empty row that says why it is empty, and a first deploy taken from that row to its first successful run, step by step; a map of how the services connect and depend on each other, with the line into a failing service marked; a project-level feed of what happened, newest first, filterable by environment and resource, with a staging environment that shows the same commit healthy; and every service always on screen. The interface is functional and the project is one object at the top of the script; no platform is connected. Every service, commit, author and figure is invented, and it has not been tested with a developer.

## Optional

- [Homepage](https://adamhickey.com/): the person, selected work (three client case studies, then Agent Review from the lab), how he works inside a product organization, what changes when agents can build, products 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 and components behind the site, documented from the stylesheets.
- [Other things I make](https://adamhickey.com/other.html): the book, and identity and illustration work for clients.
- [Résumé (PDF)](https://adamhickey.com/Adam%20Hickey%20Resume.pdf)