Performance Is a Design Material
7 min read
Frame rate, latency and load time are not engineering leftovers — they are part of the design language. What rendering two million rows taught me about treating speed as a first-class material.
Most teams treat performance as a cleanup phase: build the thing, then make it fast. After shipping Atlas — an analytics tool that renders two million rows — I’ve come to believe the opposite. Performance is a design material, the same way glass or timber is. You design with it, not after it.
The observation
Every interaction pattern in Atlas was decided by what the machine could do in under 100 milliseconds. Brushing a scatter plot feels like touching a physical object because the feedback loop is shorter than conscious perception. That feeling isn’t polish added on top — it’s the architecture.
When the data layer can’t answer in time, no amount of skeleton loaders or spinner animations recovers the trust that’s lost. Users don’t think “slow query.” They think “broken tool.”
Three rules I now follow
1. Budget before drawing. Every screen gets a latency budget before a single wireframe. If the interaction can’t hit it, we redesign the interaction — not the backend, first.
2. Motion is information. The flame-lag detail in my game Ember & Vow (the candle trails the player by 120ms) is the same idea as chart animation easing: motion communicates state. Never animate decoratively when you can animate meaningfully.
3. Measure at the edges. Median load time is a vanity metric. The p95 — the slowest readers, the worst connections — is where your design philosophy actually lives.
The takeaway
Speed is not the absence of slowness. It’s a texture, a rhythm, a voice. Designers pick typefaces for exactly the reasons engineers should pick render pipelines: because they change how the thing feels to hold.