Speed as a design principle

Fast is not a feature

When product teams talk about speed, they usually mean performance. Faster load times, snappier animations, reduced latency. These matter, but they are engineering concerns.

The speed I care about as a designer is decision speed — how quickly an operator can go from seeing information to acting on it. This is a design problem, and it should be treated as a first-class principle, not an afterthought.

Why decision speed matters

In defense contexts, the gap between information and action is where outcomes are determined. The OODA loop — observe, orient, decide, act — is not just a military framework. It is a design brief.

Every interface element either accelerates or decelerates this loop. There is no neutral.

  • A poorly labeled button decelerates.
  • A confirmation dialog that interrupts flow decelerates.
  • A data visualization that requires interpretation decelerates.
  • A clear status indicator that maps directly to an action accelerates.

If your interface forces the operator to think about the interface, you have already lost time.

Designing for speed

Here are the principles I apply when speed is a primary constraint:

1. Reduce decision points, not information.

The instinct is to simplify by removing data. This is often wrong. Instead, structure the data so that the decision is obvious. A well-designed table with clear visual hierarchy can be faster than a minimalist card that requires three clicks to reach the same data.

2. Make the default action the right action.

If 90% of the time the operator will take the same action in a given state, that action should require zero clicks. Design the system to pre-select, pre-fill, and pre-stage. Let the operator confirm rather than construct.

3. Design for muscle memory.

Consistency is speed. When interactions are predictable, operators build motor patterns that bypass conscious thought. This means:

  • Consistent placement of actions
  • Consistent keyboard shortcuts
  • Consistent visual patterns for similar operations

4. Treat every modal as a failure.

Modals break flow. They force context switches. Every time I see a modal in a high-stakes interface, I ask: "Could this be inline? Could this be a state change instead of a new layer?" The answer is almost always yes.

Speed is not about moving fast. It is about removing everything that makes people move slowly.

The compound effect

A hundred milliseconds saved on a single interaction means nothing. A hundred milliseconds saved on an interaction that happens a thousand times a day changes how an operator relates to their tool. It becomes an extension of their thinking rather than an obstacle to it.

That is the goal. Design that disappears.