In part one, I covered how we compared typefaces and icon families, then used a button to define our first control rules. The next step was to see whether those choices held together beyond a component specimen.
We had started with paper sketches to explore the shape and hierarchy of the interface. From there, I built representative marketing and product compositions. These were test surfaces, not finished product screens. Their purpose was to expose problems that a single button or font sample could hide.
Give every candidate the same work
For typography, we used the same copy and layout across four families. The interface included a large security headline, supporting text, action buttons, service cards, a metric card, and a product dashboard. That range mattered because a font that feels persuasive in a hero can become difficult to scan in a table or activity list.
We looked for a consistent reading experience: clear hierarchy in the hero, readable supporting copy, stable labels in the dashboard, and numerals that could be compared quickly. This is where IBM Plex Sans made sense as the primary typeface. The current system then gives Geist the numeric role, including tabular figures when alignment matters.
The same method helped with icons. A family had to represent several everyday product concepts at the same size and weight. Comparing only a home or search icon would be easy; comparing security, analytics, cloud, and alerts beside them gave us a better sense of consistency. Fluent UI System Icons Regular became the baseline.
Let the button expose the visual direction
The button study was where the interface started to feel distinctive. We kept the content and compact spacing steady, then changed the edge treatment between sharp, soft, and pill. That let us judge the effect of shape without also changing the type, icon, or layout.
The square-leaning version felt better suited to the technical, information-rich product we were sketching. A 5px radius softened the corners just enough while preserving a clear rectangular control. The pill version brought a different tone to the same actions, and the softer version sat between the two. The comparison gave us a reason to choose, rather than a rule borrowed from another product.
The actual button specification came from more than radius. Standard text is 14px with a 20px line height. The vertical padding and icon gap both use 5px, with 12px horizontal padding and 10px on the icon side. We also set a 1px border and a 16px icon. Together, these values make primary, secondary, and quiet actions feel related even when their colors differ.
What the test screens changed
The screens made us think in relationships instead of isolated values. A button has to sit beside body text. An icon must align with its label. A muted text color needs enough contrast on the surface behind it. A compact dashboard needs spacing that supports scanning, while a marketing section needs room to breathe.
They also showed why the existing purple should be treated as a system input. Product design chose the color direction. I used it in the comparisons, then translated it into action, text, surface, and feedback roles in the later foundation work. A single brand swatch is not enough to define hover, pressed, focus, dark-mode, and status behavior.
The output of this stage was a set of decisions we could explain: IBM Plex Sans for interface language, Fluent Regular icons, and a compact 5px-radius button. We also had a list of questions that could only be answered through broader foundation and component documentation. In the final article, I’ll show how we recorded the answers—and where the system still needs validation.