There was a deliberate decision made early in this process about how to prototype. The conventional route would have been Figma. It is the industry standard, it is what most students use, and it is what most lectures reference. But Figma prototypes have a ceiling. They are interaction flows between static screens. They can show what something looks like and roughly how it navigates, but they cannot show how something feels. They cannot animate. They cannot respond. They cannot surprise you.
Pane OS is a concept that lives entirely in behaviour. The way it moves, the way it splits, the way it arrives when summoned and retreats when dismissed. None of that could be communicated in a Figma prototype without either building a highly complex component library or accepting a version of the concept so simplified it would misrepresent the idea entirely.
I had recently had a glimpse into how working design teams are approaching this problem and what I saw was telling. Increasingly, designers are turning to tools like Claude to prototype directly in code rather than in Figma. The reasons are practical. A coded prototype running in a browser is not constrained by what a prototyping tool allows. Interactions can be genuinely fluid. Animations can have physics. Sound can be layered in. The experience can be deployed and shared with a URL rather than requiring someone to navigate a specific tool. It is, in short, closer to the real thing.
That is why I chose this approach. Not because it was easier, but because it was more honest to the concept.
The prototype was built iteratively over multiple sessions using Claude as a collaborative development partner. I provided the design direction, the concept decisions, the visual references and the critical feedback. Claude translated those into working HTML, CSS and JavaScript. The process felt less like using a tool and more like working alongside a developer, which in many ways is exactly what it was.
The build went through fifteen distinct versions, each one responding to a specific set of feedback and design decisions. What follows is a record of that process.
The first pass established the core visual language. Seven screens were identified as the minimum required to communicate the concept. Standby, home, draw, media, music, home control and photos. Early screens were built against the brand palette with the correct typeface and the glass card visual language beginning to take shape. Feedback at this stage identified that the home screen was too congested, that white text on the warm background needed recalibrating, and that the proportions of the container were too vertical for a product that lives on a wall.
The container was resized to a landscape rectangle, significantly wider than tall, referencing the glass block proportion that runs through the Pane OS brand. Four scene backgrounds were introduced, living room, kitchen, desk and child's bedroom, to communicate the core promise of the product. Pane OS does not belong to one room. It travels. Switching scenes immediately showed how the same interface reads differently depending on its environment and demonstrated that the glass container needed to be genuinely transparent rather than tinted to work across all four contexts.
