How we design in production
Speed without quality erodes trust, and quality without speed is guesswork. Our approach to design is built around resolving that tension, so that shipping faster leads to higher quality.
The foundation
There are two core tools we rely on to ensure speed and quality are not at odds with one another: a purpose-built component library, and feature flags.
The component library is owned by design engineering. It contains basic components you’d find elsewhere (e.g. buttons, inputs, menus, etc), and custom elements that are unique to our product. For example, a token display, which incudes the logo, ticker, network of a token. Or an Ethereum address that communicates trust (e.g. ENS, Farcaster, contacts, past interactions). The purpose of our component library is not to reduce complexity, but to isolate it in a single, polished, performant place.
Feature flags, on the other hand, are added and removed regularly. Their half-life is directly correlated to the speed at which we’re focused on that feature, and they allow us to introduce entropy that’s contained to specific customers.
Component discipline
We are disciplined about using the component library. Specifically, all new features use existing components by default. We don’t update or add components until after an internal launch (i.e. in production behind a feature flag turned on for ourselves).
Design’s role here is to draft technical drawings so engineers know which components and props to use. As engineers become more attuned to the components, the need for design at this step decreases.
This means most flows ship to production as suboptimal. This is great, because it lets us optimize based on actual usage. We can ship quickly and consistently, while learning which components and flows need to be improved.
Continuous feedback
When building, engineers share work-in-progress (i.e. demos, previews, screenshots) to internal channels for async feedback. If a demo isn’t ready for feedback, engineers are expected to say so up front; otherwise, feedback is assumed to be welcome.
It's up to the owner to drive clarity on what we're solving for (i.e. is this an issue related to being fast, reliable, intuitive, or visually consistent), how that aligns with other constraints (e.g. technical, product, timeline), and to incorporate those decisions back into the product spec.
Staged rollouts
All projects launch internally behind a feature flag, then expand to beta customers, and then to the public. There is no explicit design review gate to ship behind a feature flag internally or to beta customers. As long as we’re using existing components, we’re confident the design is “good enough” to ship to this audience.
The only “design gate” that exists is before removing the feature flag and expanding to everyone. We’ve found this gate exists more in theory than practice, since by the time we open the feature to everyone we’ve been using it ourselves and iterating with early customers.
Quality doesn’t come from pre-launch certainty. It comes from change grounded in real usage, and production is the only place where that learning happens consistently.