The Align has one button. Not as a design flourish — as a consequence of where the device sits. This note is about what a single control has to carry once you commit to it, and the places where that decision costs you something.

Why the constraint is real

The device attaches to an instrument that is already in someone's hand, during work that requires precision, close to a patient. That rules out most of what an interface designer would normally reach for.

A second button is not a small addition. It is a new opportunity to press the wrong one without looking, at a moment when looking is exactly what you cannot do. It is another mechanical part on a device that gets wiped down between uses. It is more surface area on something that must not change how the handpiece balances in the hand.

Every control you add has to earn its place against that. In practice, none of the candidates did.

What one button can actually express

A single button gives you two primitives: a short press and a long press. Everything else is context — what the device does with a press depends on which state it is in.

That produces a workable vocabulary:

  • Short press — advance. Step the value, move to the next option, cycle through a range.
  • Long press — commit. Accept the current value and move to the next stage.

Two gestures across a handful of states is enough to set a deviation limit, establish a reference, and start working. It is not enough for anything more elaborate, which turned out to be a useful forcing function: features that could not be expressed this way were features we had to justify much harder.

Cycling instead of scrolling

The deviation limit steps up one degree per press and wraps around at the top of the range back to the bottom. There is no way to go backwards.

This looks like a limitation and mostly is not, because of the size of the range. Sixteen settings means the worst case — overshooting by one and having to go all the way round — is fifteen presses. Annoying, but rare, and it happens while you are setting up rather than while you are working.

The alternative was a long press to reverse direction, which would have collided with long press meaning commit. Overloading the only unambiguous gesture in the vocabulary to save fifteen presses in an uncommon case was a bad trade.

The debounce problem is a design problem

Distinguishing a short press from a long one sounds trivial and is where most of the fiddly work went.

Set the threshold too short and ordinary presses register as holds, so people commit values they meant to step past. Set it too long and holds feel unresponsive — the user presses, nothing happens, they press again, and now they have stepped a value they meant to accept.

Underneath that sits mechanical bounce: a physical switch does not close cleanly, it chatters for a few milliseconds. Without filtering, one press reads as several, and a step-per-press control becomes unpredictable in a way that feels like the device is broken rather than like the button is imperfect.

Neither of these is interesting engineering. Both are the difference between a device people trust and one they do not.

Feedback is what makes it survivable

The single button only works because the device answers every press. A short tone confirms a step; a different tone confirms a commit. The screen shows the value changing.

This matters more than it sounds. With one control and no labels, the only way a user knows what a press did is that the device told them. Take away the confirmation and the same interface becomes guesswork — press, look, work out what happened, adjust. That is fine at a desk and useless mid-procedure.

The tones are also the fallback when the screen is not being looked at, which is most of the time the device is actually in use.

What it costs

Being honest about the trade-offs:

  • Setup is sequential. You cannot jump straight to the setting you want. Everything is reached by stepping through it.
  • There is no undo. Overshoot and you go round again.
  • The interface is invisible. Nothing on the device tells a new user what a long press does. It has to be learned once, from someone or from documentation.
  • It does not scale. Any feature needing more than step-and-commit does not fit, and we would need to add a control or drop the feature.

We think these are the right costs to accept for something held during precise work. They are real costs, though, and if the device ever grows a genuinely more complex mode, this decision is the first thing that will have to be revisited.

The general lesson

The useful part of this was not the button. It was that a hard physical constraint, accepted early rather than argued with, forced clarity about what the device actually needed to do. A richer interface would have let us defer that question, and the device would probably have been worse for it.