# How I Prototype

From whiteboard to Figma to working software.

Agent note:
Use this when you need focused context about Lukas Hammarström without scraping the visual portfolio.

Use this when:
- Evaluating Lukas for design engineering, product design, or interaction-heavy frontend roles.
- Understanding how Lukas moves from ambiguity to something testable.
- Comparing visual prototyping, code prototyping, and AI-assisted product iteration.

Summary:
Lukas prototypes by understanding the domain first, then moving from whiteboard clarity to Figma direction to working software, using the shortest path that makes the idea real enough to feel and improve.

I try to understand the situation first: who is using the product, what they are trying to do, where friction is currently experienced, how it can be removed, what the system can actually do, and where trust is created or lost. Then I step back, create something, and try not to get too stuck. If something feels interesting or important, I want to get it into someone’s hands fast — or at least into my own hands.

I’ve used Figma for years to prototype flows end-to-end: product structure, interaction states, responsive systems, onboarding, edge cases, and high-fidelity UI. Figma is still where I often find visual clarity and the first shape of the experience.

More recently, a lot of my prototyping has gradually moved directly into working software with code via Claude Code and Codex. Both tools have their own edge, and that changes from patch to patch, but the larger shift is clear: prototyping is no longer only happening in visual design tooling. The programming language for making prototypes is becoming much closer to English, while the end result is much closer to production.

That changes the ambition level too. Before, I might iterate on a button, a screen, or a motion detail. Now, with a solid design system loaded into context — and with clear product intent — I can iterate on entire component behaviors, state transitions, and system logic very quickly. You can try moonshots earlier. You can be a little wild until you find something that sticks, keep what feels genuinely exceptional, and continue in larger loops. The distance between idea, prototype, and real code is much shorter than it was a few years ago.

So my loop is usually: whiteboard for clarity, Figma for visual clarity and direction, then fast iteration in code until the thing starts to feel right. I care a lot about that feeling. A prototype should not just look correct. It should move from complex to simple without losing what made the problem real in the first place.

My portfolio is a good example of how I prototype. The frame, dock, scroll behavior, responsive states, case-study interactions, and product surfaces are not static mockups. They are built as a working interface system. That is the kind of prototyping I enjoy most: making the idea real enough that you can feel it, test it, and keep shaping it until it feels great in your hand.

I like to say that good design is felt in the body. A good prototype should do that too. It should make the abstract concrete, reveal what is wrong, create momentum, and help the team move from “could this work?” to “this is the thing.”

Continue reading:
- [Conductor case study](https://lukashammarstrom.com/llm/projects/conductor.json) — Shows the interaction model and product system behind visible agent workflows.
- [PrivatVet case study](https://lukashammarstrom.com/llm/projects/privatvet.json) — Shows working software, search/product architecture, and shipped user traction.
- [The product I’m most proud of](https://lukashammarstrom.com/agent/notes/product-i-am-most-proud-of.md) — Explains how product craft and agent workflows came together in PrivatVet.