Before we had tokens or component documentation, we had sketches on paper. We used them to work out the direction of the interface: what should feel prominent, how much information a screen might carry, and how an action should sit beside that information. The sketches were useful, but they could not tell us whether a typeface would hold up in a dense table or whether an icon would still make sense at 16px. We needed to test those choices in an interface.
This is the first article in a three-part series on how we built Lattice by Tegis’s design system. I’ll start with typography, icons, and buttons. In the next article, I’ll show why we put those pieces into representative screens before making a distinctive visual choice. The final article covers the system and its documentation as they stand today.
Choosing a typeface in context
Tegis needs to communicate technical subjects clearly. A typeface has to work in a marketing headline, a product label, and a table of infrastructure data. Comparing font names or isolated specimen cards would only answer part of that question.
We put four candidates—IBM Plex Sans, Instrument Sans, Source Sans 3, and Switzer—into the same interface. Each one had to carry the same hero, service cards, product dashboard, and short promotional card. Holding the content and layout steady made the difference in rhythm and density easier to see. We looked at how the families handled long headings, small labels, numerals, and the move from expressive marketing copy to quiet product UI.
IBM Plex Sans became the interface family. It gave us a clear, capable voice without making the product feel cold. In the current foundation, it covers headings, body copy, labels, and controls. Geist has a narrower job: numeric content, with tabular numerals where columns need to line up. That distinction matters in a dashboard. A type choice is also a data choice.
We recorded a type scale rather than choosing a new size for every screen. The current roles begin at 12/16 for captions, use 14/20 for labels and controls and 16/24 for body copy, and extend to display sizes for marketing. Weight assignments by role and some responsive display details still need validation in real screens.
Comparing icons by task
We tested icon families against the same set of concepts: home, search, security, cloud, people, analytics, settings, and alerts. We compared regular and filled treatments from Fluent UI, Phosphor, Hugeicons, and Untitled UI. The goal was to see whether the symbols formed a coherent set across navigation and actions, and whether their visual weight worked with the type.
Fluent UI System Icons in the Regular style became the baseline. Standard button icons are 16px. We also documented a proposed 20px alignment slot for related controls so their text can begin on the same line. That slot is still being checked in dense navigation and toolbars. An icon-only action needs an accessible name; where the action may be unfamiliar, it also needs a visible tooltip.
Starting the component language with a button
Once the type and icon direction was clearer, we designed a button. It gave us a small place to test the decisions together: text size, icon weight, padding, gap, border, and corner shape.
We tried sharp, soft, and pill treatments while keeping the compact spacing consistent. We also read about how corner shape affects perception and how interface elements signal that they can be clicked. That research informed the comparison, but it did not prescribe a universal radius. The important test was whether our control read as a button in the interfaces we were building. Research on tappability has found that people rely on multiple visual cues when deciding what looks interactive; shape alone is not a guarantee. Material Design’s shape guidance also treats a component’s visible edge and contrast as part of that signal, while research on tappability examines how users read interface elements as actionable.
We chose a compact, square-leaning button with a 5px radius. It retains a clear button shape without the softer character of a pill. The current standard uses 14/20 text, a 1px border, 5px vertical padding, 12px horizontal padding, and 10px on the icon side. The icon-to-label gap is also 5px. That relationship between padding and gap gave us a repeatable baseline for text-only and icon-and-text actions.
One detail about color: purple was chosen by product design. I worked with that direction when testing the interface and building the system. The engineering task was to make it usable and consistent across roles and states, not to claim the brand choice as mine.
These first decisions gave us enough to build a screen. They did not yet prove that the system would work. That is what we tested next.