Prototypes, built to learn, not to impress.

Prototypes are the cheapest way to be wrong on paper.

I use wireframes and prototypes as thinking tools first, deliverables second. A rough sketch shared in a workshop often does more to align a team than a fully rendered comp shared a week later. The fidelity I bring is tuned to the decision the team is trying to make, not the screenshot the team wants to show leadership.

From sketches on a wall to Figma prototypes wired into research recruitment, I'll match the artifact to the question.

What I prototype, and at what fidelity.

• Low-fi wireframes: Quick black-and-white layouts that focus the conversation on hierarchy, flow, and content priority, before visual debate kicks in.
• Mid-fi wireframes: Component-level wireframes with real content and clear interaction notes, suitable for stakeholder review and engineering scoping.
• High-fi visual prototypes: Pixel-tight comps that capture the intended look and feel for design system contribution, marketing review, or hero-moment validation.
• Interactive prototypes: Clickable Figma or Framer prototypes wired for usability testing, sales demos, or executive walkthroughs.
• Motion & micro-interaction specs: Documentation of transition timing, easing, and feedback cues so engineering implementation matches design intent.
• Design system handoff: Annotated specs, redlines, and component documentation that keep design quality intact through implementation.

Prototypes earn their keep when…

• The team is debating an idea without anything concrete to point at
• A research round needs a stimulus more real than a static comp
• Stakeholders need to feel the product before they'll fund the build
• Engineering needs unambiguous reference for a complex interaction

Prototypes in practice.

On Infiniti VRS I produced wireframes and interactive prototypes that drove stakeholder alignment and informed the production design system. On NissanUSA.com, prototypes anchored the mobile shopper research that validated the redesign direction.