A visual-only designer.
I don’t chase the screenshot. The work has to be defensible on research, on accessibility, and on engineering cost, or it isn’t the work.
About
№ 4 · 2026 Edition
I design for how a product should feel to use, then check that it does.
Computer science and sociology by training: how systems are built, and how people behave inside them. Since then, five years of product and UX design in four kinds of seat. Inside a design agency and its enterprise clients, freelance and through a practice of my own, in-house at an institution, and now on contract in education. The rooms have ranged across life sciences, financial services, luxury and verification, medical devices, e-commerce, travel, and education.
I’ve kept changing rooms. A designer who has only worked in one tends to bring one tool to every problem; the principles below are what the different rooms had in common.
Positions
Operating principles.
Each one came from a specific project where something happened that made me believe it. The project is noted beside each.
-
Research reshapes the problem, not just the solution.
I’ve thrown away a month of design work because one user interview revealed I was solving the wrong thing. That experience is why research now comes before the contract, not after it. Research is there to correct what you already think, not to validate it.
-
If people notice the interface, something needs fixing.
In usability testing, the moment a participant pauses before acting, that pause is a defect to fix, not a quirk to note. My first treatment of one affordance was minimal because I’d optimized for hierarchy; one in four people missed it. The version that tested clean was not the one I’d have shipped on taste alone.
-
Evidence outranks preference — including mine.
I’ve iterated away designs I was proud of because the test results were clear. It never gets easier. It’s always the right call. Personal preference has no seat at the table when you have behavioral evidence pointing the other way.
-
Constraints, taken early, sharpen a design.
The Hamilton engagement taught me this. The WPF rendering constraint I hit in sprint one produced a more disciplined visual system than I would have built without it. Constraints are the edges that give a design its shape.
-
The handoff is part of the design, not cleanup.
Running sprint ceremonies at GIA while designing showed me exactly what happens to vague annotations: engineering makes judgment calls. The handoff should leave no questions the designer would have answered differently than the person implementing it.
Decisions
The decisions ledger.
Six turning points and what each one cost and paid. A career is less a timeline than a sequence of decisions about what to optimize for. This is the shape of mine.
-
UX/UI designer, Freddie Mac’s DPA One NDA
Led UX research and designed dense tabular-data experiences for the national down-payment-assistance platform, inside Freddie Mac’s enterprise design system. A multi-year engagement, concurrent with the agency period.
Cost / paid No public case study possible; the depth of the work lives in private files.
Taught How to design credibly inside legal, compliance, product, and engineering simultaneously.
-
UX/UI designer & developer
Joined a 45-year firm to get breadth across healthcare, enterprise, fintech, consumer.
Cost / paid Owned fewer full-cycle projects; shipped more variety of first-draft work.
Taught Why one tool doesn’t fit every problem, and how to spot which one fits.
-
Visual designer, design system
Designed from WPF constraints backwards after first sprint revealed render cost.
Cost / paid Dropped visual treatments I liked for ones engineering could ship.
Taught Early-respected constraints produce better design than late-discovered ones.
-
Founder, independent practice
Ran an independent practice alongside a full-time role.
Cost / paid Six-day weeks for stretches; every scope, contract, and pricing decision owned end-to-end.
Taught To scope work like the person paying for it.
-
In-house designer + interim PM
Took interim PM responsibilities while designing through a PM hire.
Cost / paid Split focus for most of the tenure; full visibility into the decisions I was handing off.
Taught How to write a handoff an engineer can ship without asking.
-
Contract designer within a larger team
A current client engagement, held under NDA — exploration through high-fidelity UI in a PM-led agile process, with documentation that feeds the platform’s design system. Specifics are available in conversation.
Working with me
Working with me.
The calls I make when the inputs conflict and someone has to decide: the questions that usually come up in a second conversation, answered here so the first one can go further.
- When research and the deadline disagree
- I ship the smallest version I can defend and write down what I’m still unsure of. The mistake is treating that as a loss. A plain “here’s what we don’t know yet” is more useful to a team than a confident guess. The handoff names the risk; it doesn’t hide it.
- When I’m the senior person and still unsure
- I say so, and I make the smallest decision that lets the team keep moving while the uncertainty resolves. Seniority isn’t having the answer faster. It’s knowing which unknowns are cheap to defer and which ones will be expensive at handoff if they’re left open.
- How I handle engineering disagreements
- Disagree in the ticket, commit in the sprint. I take engineering constraints at face value and redesign around them; in return I expect the same clarity on what’s hard and why. Most “design vs. eng” conflicts resolve when someone writes down what we’re actually optimizing for.
- What I do when the brief is wrong
- Flag it early, in writing, with a specific alternative. A brief that’s wrong in the first week costs a sprint; a brief that’s wrong at handoff costs a quarter. I’d rather be the person who slowed the start by a day than the person who shipped the wrong thing on time.
- How I decide what not to design
- Most teams under-scope the unglamorous states and over-scope the showcase screen. I spend the budget where the product is most likely to fail unnoticed, and I’ll argue to cut a polished feature if its states aren’t funded. What you leave undesigned is a decision, so I make it one.
- What I need from a team
- Design influence on product direction, not just execution under it. Engineering partners who argue. A PM who’ll say “I don’t know yet.” Users I can actually talk to. Everything else is negotiable.
- Where AI fits in how I work
- As leverage on the unglamorous parts: synthesizing research notes, scaffolding prototypes, drafting handoff annotations. I use Claude, v0, and Framer AI the same way I use Figma: a tool that earns its place when it saves hours I’d rather spend on the call that needs human judgment. The output gets reviewed; the judgment is still mine.
Boundaries
What I’m not.
A few things the work won’t be, said plainly so we don’t have to discover them at month three.
A framework designer.
I don’t lead with named methodologies or double-diamond diagrams in the first meeting. Process is internal scaffolding; the output is the product.
A lone-wolf designer.
The best work I’ve shipped came from being close to engineering, PM, and users simultaneously. I don’t want to be protected from the room; I want to be in it.
An anti-data designer.
I push back on data when the measurement is wrong. I don’t push back on it because I’m attached to a design. Preference doesn’t beat evidence.
A title-chasing designer.
I’ve taken roles below my title to work with people I wanted to learn from, and roles above my title to own outcomes. The role follows the problem, not the other way around.
A designer who needs a hero feature.
My best craft shows up in empty states, error copy, loading transitions, focus management. The product gets better in the unnoticed places, and I’d rather spend a week there than a day on the home page.
Correspondence
If that’s the designer the role needs.
That’s how I work, what I optimize for, and what I won’t be. If it’s a fit, the next step is a conversation.