About Peter Wilder
I close the gap between what a product is
and what it could feel like to use.
UX/UI & Product Designer. Nearly 5 years of embedded work across agency, enterprise, and independent practice. The common thread: products that had real users with real needs that the UI wasn’t serving — and a process for figuring out why, and doing something about it.
How I got here
“The shortest explanation: I studied computer science and sociology at the same time. That combination — how systems are built and how people behave within them — turns out to be exactly what design requires.”
I didn’t come to design through a traditional path. Computer science coursework gave me fluency in how products are built. A sociology minor gave me a framework for understanding why people behave the way they do. A structured design apprenticeship tied it together. The result is a designer who thinks in systems, tests against behavior, and has worked closely enough with engineers to know which design decisions create three tickets and which ship in an afternoon.
My career has moved through three contexts that I think of as a deliberate arc: agency work (RKS Design) gave me breadth — healthcare, enterprise, fintech, consumer, all under deadline pressure. Enterprise in-house work (GIA) gave me depth — understanding a domain, its users, and its constraints well enough to make structural decisions rather than surface ones. Independent practice (Wildr Design) gave me ownership — the full responsibility of advising clients on problems before proposing solutions.
Currently I’m based in San Diego, designing at GIA. I’m actively looking for my next role — ideally a team where design has real influence on product direction, not just execution.
Experience
Skills & Tools
The stack.
UX/UI & Product
Software & Platforms
Emerging Workflows
How I think about design
Six principles. Each one learned the hard way.
These aren’t design blog maxims. They’re things I believe because something happened that made me believe them.
The research shapes the problem, not just the solution
I’ve thrown away a month of design work because a single user interview revealed I’d been solving the wrong thing. That experience is now the reason I build research into the contract before I build anything else. The research isn’t there to validate what you already think. It’s there to correct it.
If users have to think about the interface, the interface has failed
Not metaphorically — literally. In usability testing, the moment a participant pauses and says “hmm” before interacting with something, that’s a design defect that needs to be fixed. The best interfaces are invisible. The experience is all that remains.
Data overrides preference. Every time.
I’ve iterated away designs I was genuinely 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 improve design when you respect them early
The Hamilton engagement taught me this. The WPF rendering constraint I encountered in the first sprint produced a more disciplined visual system than I would have built without it. Constraints are not obstacles. They’re the edges that give the design its shape.
Accessibility is a quality signal, not a checklist
Every product I’ve built with rigorous accessibility standards has been a better product for everyone — not just for users with disabilities. Contrast ratios, focus management, semantic hierarchy: these are good design, not accommodations.
The handoff is a design deliverable
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.
Let’s connect
Ready to build something remarkable?
If this reads like the kind of designer your team needs, let’s talk about it.