Studio

Design and engineering are one job

The usual arrangement is that one group draws a thing and another discovers what was undrawable. The interesting parts of a digital product — how it responds, how fast it feels, what happens on a bad connection or an old phone — are the parts that fall between those two groups and get decided by whoever is left holding them at the end.

We do both, so those decisions get made deliberately. A composition is designed against what the browser can actually do; a build is written by someone who cares whether the spacing survived.

The interesting constraint is never the effect

Anyone can make a page that is beautiful on a new laptop with a fast connection. The work is making it beautiful there and complete on a four-year-old phone, legible to a screen reader, and safe for someone who gets motion sick — without shipping three different products.

So a still edition is designed alongside the moving one rather than generated by switching the animation off, and a device that cannot run the heavy version gets a considered page rather than an apology.

Measured, not asserted

Claims about performance and smoothness are the easiest thing on a studio site to write and the hardest to check, so we build the instruments. This site’s camera can be stepped headlessly at any frame rate and differentiated; its scene can be photographed at any point in the journey; its layout can be measured rather than eyeballed.

That is why the case study quotes degrees per second rather than adjectives. If we cannot measure an improvement, we try not to claim one.

What we will not do

• Ship an experience that excludes people who need reduced motion.
• Present a concept as a commission, or a mockup as a running thing.
• Quote a result we cannot point at.
• Hand over a codebase your team cannot read, or one that needs us to keep running.