What it is
A design system is only worth building if it helps people do real things. The research and interaction-design side is where I make sure the components map to actual tasks, not just to a tidy component sheet.
How I approach it
I’m comfortable at every stage of the handoff: running user interviews, turning what I hear into wireframes and prototypes, testing them with real users, and then writing the front-end code to build what tested well. Working across that whole range means the research findings don’t get lost in translation on the way to the interface — I’m usually the one doing the translating.
Common problems I solve
- Interfaces designed around the org chart instead of the user’s task.
- Prototypes that look finished but were never tested with anyone.
- Research insights that stall because no one connects them to the build.
- Design and engineering treating each other as a black box.
For a podcast network I ran user interviews and built responsive analytics views from the findings — research and implementation in the same pair of hands.
