Aristotle Design System / Design system for an AI research interface
Designing a system for an interface with depth.
Aristotle isn’t a flat interface. Research answers, citations, reasoning, tools, sidebars, cards, and canvases can all exist at different levels of the interface. As the product grew, those layers made consistency harder to maintain.
I built the foundation that kept Aristotle’s hierarchy, contrast, and interaction patterns coherent as the product expanded.
- Role
- Product Designer
- Timeline
- Oct 2025 to Present
- Team
- 2 designers
- Scope
- Tokens · Components · Dark mode · Typography · Iconography
01 · The problem
When everything can be a surface, consistency gets complicated.
Aristotle’s interface evolved quickly as we introduced new research workflows and ways of presenting information.
A component that looked correct on one surface could lose hierarchy on another. Colors were increasingly being chosen at the component level. Similar patterns began behaving differently across the product.
The problem wasn’t that we didn’t have components.
It was that we didn’t yet have a system for deciding how those components should behave.
02 · The principle
One system, multiple layers.
Components shouldn’t know what color they are. They should know where they belong.
03 · Surface tokens
We stopped letting components choose colors.
Aristotle’s layered interface meant the same component could appear on multiple surfaces. Hard-coded colors made those relationships brittle. So we introduced semantic surface tokens: a primitive Neutral scale from 0 to 1500, mapped to tokens organized by surface intent.
Components ask for a surface, never a color.
background: #F7F7F7border: #E4E5E6text: #3E4042background: surface.secondaryborder: border/subtletext: text/secondary04 · Dark mode
Don’t design two themes. Design one relationship.
The challenge wasn’t simply translating light colors into dark ones. Aristotle’s surfaces have relationships: page, panel, card, elevated content. Those relationships needed to remain intact regardless of theme.
So instead of creating a separate set of dark-mode values for each component, I mirrored the semantic relationships between surfaces. Dark mode is a mirrored token architecture, not a set of manual overrides.
05 · From tokens to components
The system only matters if it survives contact with the product.
Tokens gave Aristotle a shared visual language. The next challenge was making that language work across real product surfaces.
Instead of building components as isolated UI pieces, I connected them back to the system: primitive values became semantic tokens, semantic tokens became component properties, and components became part of the product.
From value to interface
Designing components around meaning
We focused on a small set of foundational components that appeared repeatedly across Aristotle. Rather than creating a new visual treatment for every context, components inherited their visual behavior from the same underlying token system.
This meant a card used in a research response and a card used in a project workspace could feel different when necessary, without becoming completely different components.
The system provided consistency without forcing every surface to look identical.
01 · Button
Buttons were one of the simplest examples of the system becoming reusable behavior. Instead of defining colors directly inside each button variant, states were mapped to semantic tokens for background, content, and interaction.
- Primitive
- Neutral / Accent
- Semantic
action.primary/content.on-primary- Component
- Button / Default / Hover / Disabled
- Product
- Submit prompt / Save / Continue
This allowed the same interaction pattern to move across Aristotle without manually recreating its visual states.
02 · Input
Inputs had to work across some of Aristotle’s most important moments: asking a question, searching for evidence, and configuring research workflows.
- Primitive
- Neutral / Spacing / Radius
- Semantic
surface.input/border.default/content.primary- Component
- Input / Focus / Error / Disabled
- Product
- Research prompt / Search / Sign-up
The component handled the interaction states while the token system controlled how those states appeared across themes.
03 · Card / Surface
Cards were particularly important because Aristotle uses multiple layers of information.
- Primitive
- Neutral scale / Border / Radius
- Semantic
surface.secondary/surface.elevated/border.subtle- Component
- Card / Surface
- Product
- Research results / Hypotheses / Project content
Rather than treating every card as a new visual object, we used surface semantics to establish hierarchy.
The component changed when its context required it. The underlying visual language didn’t.
04 · Navigation
Navigation introduced another layer of the system: hierarchy.
- Primitive
- Typography / Neutral / Spacing
- Semantic
content.primary/content.secondary/surface.subtle- Component
- Navigation / Item / Active / Hover
- Product
- Sidebar / Workspace navigation
This gave navigation a consistent relationship to the rest of the product while allowing different product areas to establish their own hierarchy.
05 · Research-specific components
The most important test was whether the system could support components unique to Aristotle’s scientific workflow.
- Primitive
- Type / Surface / Border / Spacing
- Semantic
- Content / Surface / State tokens
- Component
- Research component
- Product
- Aristotle screen
Which Aristotle-specific component this is (for example a hypothesis, research result or evidence card) and the screen it ships in.
This is where the design system stopped being a collection of generic UI components and became a system built for Aristotle.
The goal wasn’t to make every component look the same. It was to make every component feel like it belonged to the same product.
06 · Designing for variation
Not every difference needs a variant.
Aristotle’s interface had many contexts where a component could technically have dozens of variations. Instead of encoding every possible combination into the component, I focused on identifying the properties that actually represented meaningful product states.
Card / Dark / Compact / Elevated /Research / Selected / WithIcon / …Cardsurface · state · density07 · Typography
Type for people who read papers.
Two typefaces: Helvetica Now Display for the interface, paired with Iowan Old Style, a serif that feels familiar to researchers used to academic papers.
08 · Iconography
Build only what the product actually needs.
Aristotle’s scientific workflows introduced concepts that weren’t always well represented by existing icon libraries. Rather than creating an exhaustive icon set upfront, we built icons as product needs emerged and standardized them around six size tiers.
158 icons. 6 size tiers. One visual language.
09 · Maintenance
A design system is a product, not a file.
Once the system was in use, the challenge shifted from building components to keeping the system coherent as Aristotle changed.
What you actually did to keep it coherent: naming conventions, component cleanup, reducing variants, token usage, Figma organization, handoff, preventing one-off styles, updating the system alongside product work.
10 · The system in the wild
One foundation. Many surfaces.
Maintain hierarchy
Establish reading hierarchy
Standardize interaction
Create consistent navigation
Preserve relationships
The goal wasn’t consistency for its own sake. It was to make Aristotle feel like one product as its complexity grew.
11 · What changed
One foundation for a growing product.
- Designers could build new surfaces without inventing new colors.
- Dark mode could scale through the token architecture.
- Components could move across Aristotle’s layered interface without losing hierarchy.
- Engineers had clearer semantic values to implement against.
Next project
Aristotle