Poi Flowers.

I spin poi. So when I couldn't find a tool that let me explore flower patterns the way I actually think about them, I built one, even though I'd never written code before. Poi Flowers turns the geometry of poi spinning into something you can dial in by feel and watch take shape in real time.

This is the story of a passion project: where the idea came from, the product decisions behind it, what it took to design an interface around a physical skill, and what I learned about being a designer in a moment when the gap between “I wish this existed” and a working thing has nearly closed.

01, The spark

You can see the trail.
You can't see the cause.

Poi are weights on the end of tethers that you swing in circles. With LED or fire poi, you spin in the dark, so all anyone sees is a bright trail hanging in the air. The flower shapes are beautiful, and notoriously hard to learn.

The trouble is that the trail hides the mechanism. A five-petal flower and a three-petal flower can look almost identical mid-spin, yet they come from completely different things your hands are doing, opposite spin directions, a different number of poi rotations per beat, a different starting position. When you're learning, you're trying to reverse-engineer an invisible cause from a glowing effect.

The references I could find didn't help much. They were either static diagrams that froze the motion, or they were the underlying mathematics, these patterns are epicycloids, the same family of curves a Spirograph draws. But no spinner stands in a dark room thinking set P = 3. We think in petals, in antispin and inspin, in timing and direction. I wanted a tool that spoke that language.

And there was a second, more personal barrier: I'm a designer, not a developer. For years, a tool like this was something I could only imagine, sketch, and wish for. What changed was access, with an AI coding assistant, I could finally build the thing I kept wishing existed, and put my actual poi experience to work as the spec.

02, The core decision

Design it in the language of the body.

The whole product rests on one reframe: a poi flower is just geometry, but the person making it isn't doing geometry, they're moving their arms. So the interface should map, one-to-one, onto the choices a spinner actually makes with their body.

Underneath, every pattern is the same parametric equation: the hand travels one circle while the poi travels P circles around it. I kept that equation in the tool, but only as a quiet line of text in the header, a nod for the curious. It is the one thing I deliberately refused to make you think about.

Because I spin, I already knew the vocabulary that mattered and, just as important, which controls would feel wrong if they were missing. That domain knowledge became the backbone of the information architecture. Every control on the panel is a decision a real spinner makes, named the way a spinner would name it.

03, The control model

One panel, grouped the way you'd build a move.

I organized the controls into the order you'd actually think through a pattern: first its identity, then its proportions, then what your two hands are doing, then how it plays back and how much you want to see.

Two interaction decisions did a lot of quiet work. The first is progressive disclosure: the dense two-hand options simply don't exist until you ask for two hands, so a beginner exploring single-poi flowers never has to look at them. The second is a readout in the corner of the canvas that translates your current settings back into plain language, 5-petal antispin · two hands · 4 poi rotations. The controls let you build by feel; the readout teaches you the name of what you built. The tool talks back in the vocabulary it wants you to learn.

The presets follow the same philosophy. Tapping “Triquetra” or “5-petal anti” sets the base flower but keeps your hand settings, they're starting points to mess with, not a locked gallery of finished outputs. That mirrors how spinners actually learn: grab a shape you recognise, then push on it until it becomes something else.

04, The teaching layer

Make the invisible cause visible.

This is the feature I'm proudest of, and it comes straight from the original problem: in the dark, you only see the light. So I built a way to turn the mechanism back on.

Flip on Show mechanics and the hidden cause appears, a dashed ring for the path your hand travels, a line for your arm and tether, and the bright head where the poi actually is. Suddenly the trail has an explanation. Turn it back off and you're left with just the glow: the way the pattern looks to an audience. The same screen serves the spinner learning the move and the spinner performing it.

A companion toggle, Ghost full path, traces the complete flower as a faint outline so you can see where the bright head is heading before it gets there, the difference between watching a line being drawn and knowing the shape it's drawing. Small as they are, these two switches are the bridge between the abstract equation and the thing your hands have to do.

05, Designing for how poi is seen

Make a pixel look like a light.

If the on-screen pattern didn't feel like a real light trail, my own muscle memory wouldn't recognise it. So the visual language isn't decoration, it's doing a job.

Everything keys off how poi is genuinely experienced. The canvas is near-black, because you spin LEDs and fire in low light. The trail is a fading comet with a blooming head, rendered with additive blending so overlaps glow brighter, the same look as the long-exposure light-painting photos the poi community shares. And the two poi are jade and coral, distinct enough that even a tangled two-hand pattern stays readable as two separate paths.

The color choices double as the interface's wayfinding. Jade is the accent throughout the panel, on the active states and focus rings; coral marks the “second hand” territory. The palette ties the controls to the canvas, so the thing you're adjusting and the thing you're watching feel like one object.

06, Building it without knowing how to code

The barrier was implementation, not ideas.

I'll say it plainly: I have no coding background. This tool exists because an AI assistant handled the parts I couldn't, the canvas rendering, the parametric equation, the animation loop, while I did the part I could.

And the part I could do turned out to be most of the work. I knew exactly what control I wanted and exactly what output to expect, because I spin. I could look at a result and say, instantly, “that antispin should have one more petal” or “the trail decays too fast to read the shape.” I was the domain expert, the target user, and the designer at once, which made the loop of describe → generate → judge → refine extremely tight.

What surprised me is how much of it was a specification problem, which is to say, a design problem. The clearer I described a behaviour in real poi terms, the better the result came back. Vague prompts produced generic sliders; precise ones, grounded in how the move actually feels, produced controls that behaved correctly. My years of spinning weren't a side note to the project, they were the research.

So my effort went where a designer's effort should: the feel of the controls, the wording of the readout, the warmth of the glow, deciding what to hide and when to reveal it. The syntax was never the point. Taste, judgment, and knowing my user, even when my user was me, were.

07, Craft & access

The details that don't announce themselves.

A passion project is no excuse for sloppy fundamentals, and getting them right was part of the learning.

The tool respects reduced-motion preferences: if you'd rather not have things moving, it pauses the animation and shows the full ghost outline instead, so the pattern is still completely legible as a still image. Every control is keyboard-navigable with a visible focus ring, the readout announces the current pattern to screen readers, and the whole layout stacks gracefully on a phone, which matters, because the most likely place to actually use this is on your phone at practice, checking what a move should look like before you try it.

08, What I took from it

What it taught me as a product designer.

I set out to build a toy for myself. I came away with a sharper sense of what the job actually is.

09, Where it could go

Next moves.

A few directions I'd explore if I keep pulling the thread:

More pattern families beyond flowers, hybrids, weaves, and CAP-style sequences. A way to export a pattern as a light-painting still or looping GIF to share. Save and share configurations by link, so a teacher could hand a student an exact pattern. And a slow-it-down practice mode that walks a single flower through its beats. But the most important next step isn't a feature, it's getting it into other spinners' hands and watching where their instincts diverge from mine.