Choosing a typeface for a product interface is one of those decisions that looks small at the start of a project and turns out, six months in, to have been deciding everything else as well. Once a typeface is in, it shapes hierarchy, density, voice, the size of buttons, the rhythm of forms — and changing it later costs much more than choosing it well in the first place.
A few practical notes from work we've done recently.
Pick a text face, not a display face
The single most common mistake we see is a UI built on a typeface drawn for headlines. They look beautiful in the brand deck and brittle in a settings panel. A good UI typeface needs to be legible at 13–15 px on a non-retina screen, hold up in dense tables, and stay neutral across forty different content lengths. Most display faces fail one of those tests, and the failure shows up gradually.
We almost always start with something drawn explicitly for screen text — Inter, IBM Plex, Source Sans, or one of the newer humanist grotesques. The goal is a face that disappears into the work. The product is the figure; the type is the ground.
Two sizes do most of the work
It's tempting to build a type scale with eight or ten steps. In practice we find that any given screen uses about three: a body size, a smaller meta size, and a heading size. The other steps in the scale are mostly there to handle special cases (empty states, marketing pages, a chart axis). When we audit a finished product, the body size accounts for roughly 70% of the rendered text. So that's where most of the care should go.
A useful exercise: pick the body size first, then derive everything else from it. If your body size is 15 px with a 1.5 line-height, headings tend to want to be 19/22/28/36, not whatever a tooling default suggests. Building outward from the body size gives you a scale that reads as a family rather than a collection.
The rare moment display type belongs
The exception is the seam where the product touches the brand: marketing pages, onboarding flows, empty states with personality, the occasional dashboard hero. Here a display face can do real work — it sets the temperature of the room before the product has earned the right to be quiet.
The trick, when you do reach for a display face, is to keep it geographically contained. Use it for one or two roles, never as a fallback for headings inside the app, and never below a size where its quirks turn into legibility problems. We tend to draw a hard line: display type lives at marketing-page sizes only. Inside the product, it shows up exactly once, in the wordmark.
Pairing
A single, well-chosen typeface is almost always enough for a product. If you do pair, pair for contrast, not similarity — a serif against a sans, a geometric against a humanist. Two faces that nearly match read as a mistake; two faces that clearly differ read as a decision. And remember that "pairing" includes the mono you use for code: it's a third voice in the room, and it should be chosen with the same care as the other two.
None of this is rules. Type in interfaces is mostly judgement and accumulated taste. But these are the questions we end up asking on every project, and writing them down has made our first-week decisions a little less expensive.