DDS — The dani design system

01 · Philosophy

DDS draws from four schools — Dieter Rams' functional discipline, the Swiss International Typographic style, Nothing OS's industrial monochrome, and Apple's platform polish. From each we took one thing:

• 01
  Less, but better.Every element earns its place. No decoration, no gradients, no shadows. Only functional surface, text, and border.
• 02
  Typography is the interface.Clear hierarchy beats ornament. A grid, a monospace, weight, and whitespace do the work of a hundred icons.
• 03
  Rectangular, not round.Sharp 4px radii and hairline 1px borders. Circles and pills are out; rectangles are honest about what they are.
• 04
  Monochrome speaks, accent shouts.Black, white, and one saturated red. Accent is reserved for action — never decoration.
• 05
  One accent, every app.All dani products share the same Dot Red UI accent. Product identity comes from the app icon and brand assets, not from in-app colors.
• 06
  Status is shape, not hue.There is no green-for-success, amber-for-warning palette. Meaning is carried by label, weight, border width, and position — which survives colorblindness, monochrome printing, and glare.

02 · Color

The DDS color system has two layers. The monochrome base is shared across every product, dark mode and light mode. The accent is Dot Red — the same across all products — and appears only on action surfaces.

Monochrome base

Nine tokens per mode. Memorize them. Never deviate.

Dark mode is matte black (#000000), not charcoal. This gives DDS its electronic/industrial character — closer to a piece of consumer hardware than a typical software UI. Light mode uses warm off-white (#F7F7F7) with pure-white surfaces stacked on top.

UI accent — Dot Red

Every dani product uses the same accent for UI: Dot Red. It ships as a pair — #FF2D2D tuned for #000 surfaces (dark mode) and #E80000 tuned for #F7F7F7 (light mode). Never cross-use.

accent_subtle is the only place DDS mixes a color with a surface. It is a wash, never a gradient.

Dot Red is pre-verified for ≥4.5:1 contrast against both mode surfaces (WCAG AA). White text on a Dot Red button hits the same floor.

Brand colors (icons & assets only)

Each dani product has a unique hue for its app icon and marketing assets. These are never used as the in-app accent — all UI uses Dot Red above.

03 · Logo & wordmark

Every dani product shares one logo. It is a two-part lockup: a filled tile carrying the d. mark, and a wordmark set beside it. Only two things ever change between products — the string and the tile color. Nothing else: not the proportions, not the mark, not the spacing.

dani.go is the reference artwork. Every ratio below was measured off it, and dani.ko is drawn from those same numbers.

Construction

The lockup is driven by a single input: H, the nominal height a caller asks for. Every other dimension is a ratio of H or of the tile edge, so the lockup keeps its proportions at any size. Nothing in the logo is an absolute pixel value.

Offsets are measured from the tile centre, as fractions of the tile edge. In Flutter these are Alignment(−0.25, 0.05) for the letter and Alignment(0.55, 0.35) for the dot — Alignment units are twice the fraction.

Color

The tile is the accent and the wordmark is text. Never the reverse: a navy or red wordmark on the page background fails contrast, which is the whole reason the mark lives on a filled tile.

Typeface

Line height 1.0 on both — the lockup is centred geometrically, so any leading would push the parts out of alignment.

Platform notes

The same drawing needs two different vertical corrections, because Flutter and CSS/SVG do not put a baseline in the same place.

Centre-aligned in a Row against the same tile, Flutter otherwise hangs the wordmark about 8% of a tile-edge too high. Use Transform.translate, not Padding — padding adds to the laid-out height and a surrounding FittedBox would scale the whole lockup down to pay for it.

The lockup's intrinsic width is driven by H, so a caller asking for a large height is really asking for a very wide row — at H = 34 that is roughly 550px. Always wrap it in a scale-down box (FittedBox(fit: BoxFit.scaleDown) in Flutter, max-width plus height: auto on the web) so it shrinks to the space it is handed instead of overflowing.

Sizes and clear space

Clear space on all four sides is 0.28 × tile — the same value as the gap. Below H = 14 the wordmark stops being legible: drop it and ship the tile alone.

04 · Typography

Two families. Space Grotesk is the voice of the UI. Space Mono is the voice of data — every number, date, code, label, and timestamp uses mono. This split is the system's signature and it is not a stylistic preference: a monospace column of figures aligns without tabular-figure hacks, and it makes numbers instantly distinguishable from prose.

The full scale

Fourteen steps. Sizes below are the phone baseline — multiply by the viewport factor in the next table for tablet and desktop.

Line height is absolute, not a ratio. Ratios drift between Flutter, CSS and SwiftUI; absolute leading does not.

Responsive scaling

The scale above is tuned for a phone. Wider viewports multiply every content size by a single factor, so the whole system grows together instead of drifting apart.

Rounded to the nearest whole pixel. Round once, at the token layer — never per component.

Numerals

Text color roles

Wrapping and truncation

• List item names truncate with an ellipsis at one line. Never wrap a row title.
• Amounts never truncate. If space is tight, the title yields, not the number.
• Body copy wraps freely; reading columns cap at 720px.
• Labels never wrap. If a label does not fit, the label is too long — shorten the words, not the type.
• Two-line clamp is the maximum anywhere inside a card.

05 · Spacing & layout

DDS is built on a 4px grid with a 2px half-step. Every padding, margin, gap and dimension is a multiple of 2, and the overwhelming majority are multiples of 4. The half-step exists for optical corrections only — compensating a hairline border, centering a glyph — the same role Carbon gives its 2px mini-unit and Atlassian gives space.025.

Semantic spacing

Primitives are for building components. Screens use the semantic tokens below, so a change to card rhythm is one edit rather than four hundred.

card_padding 18 = 16 + 2. The half-step compensates the 1px border on each side so text inside a card sits on the same optical rhythm as text on the bare background.

Breakpoints and the layout grid

Content never stretches past 1200px. Reading-heavy views cap earlier, at 720px. Beyond 1440px the shell centers and the background extends — the layout does not keep growing.

Density

Two densities. Default everywhere touch is possible; compact on pointer-only desktop surfaces and inside data tables. Compact drops every control one step on the ladder and swaps card_padding for card_padding_compact. It never changes type sizes.

06 · Radii

DDS is rectangular. Three radii exist. There are no pills and no circles — with one sanctioned exception: the small decorative dot indicators, which are the system's single break from its own rule.

On iOS, use plain corner radii — not continuous/squircle corners. The squircle is Apple's shape language, not ours.

07 · Borders & depth

DDS uses borders instead of shadows. Two widths exist: 1px hairline for standard dividers and card boundaries, and 2px strong for emphasis and selected states. No drop shadows. Ever. Depth comes from surface stacking and borders, never from blur.

Three layers is the ceiling. A fourth nested surface means the hierarchy is wrong, not that a new token is needed.

08 · Sizing & controls

Every interactive element in DDS is height-driven, not padding-driven. You set a height from the ladder and center the content; you never derive a height by adding vertical padding to a font size. This is the single change that keeps a button, an input and a select on the same baseline when their contents differ.

Padding X is the inline padding at rest, with a 1px border. Add the border compensation rule when a 2px border applies.

Component anatomy

The ladder above sets heights. This table sets everything else. Values are phone defaults; desktop drops one ladder step under compact density.

09 · Icons

Icons are outline, uniform stroke, square-cornered, and drawn on the same 4px grid as everything else. There is no filled variant and no duotone — an active icon changes color, not weight.

Optical box is the layout footprint. Align the box, not the glyph — otherwise a wide icon and a narrow icon in the same row will not line up.

10 · Motion

Motion is functional, not expressive. If a user cannot explain what an animation is for, it should not be there. There are no physics-based animations, no parallax, no particle effects, and no easter-egg flourishes.

No transition animates layout size. Animating height causes reflow jank on every platform we ship to.

Haptics are light on tap and selection on tab or segment change. Nothing else vibrates.

11 · States & interaction

Eight states, defined once, applied identically to every control. States are expressed as explicit token swaps — never as a blanket opacity multiplier, which stacks unpredictably when two states coincide.

Selection controls

12 · Components

Every DDS component is built from the same primitives: a height from the ladder, a 4px radius, a 1px border, and type from the scale. The system is combinatorial — there are no special-case components.

Buttons

One primary button per screen. Two primaries means the screen has two purposes and should be two screens.

List items

Data card / totals

Chips & tags

Gauge / progress

Inputs

13 · Usage rules

These are the enforcement rules. Every design and code review applies them.

14 · Accessibility

• Every interactive element has a semantic label — icon-only controls always carry one.
• Focus order follows visual order. Overlays trap focus and return it on dismiss.
• Reduced-motion users get motion disabled, not shortened — zero animation.
• Nothing is communicated by color alone. Every accent signal has a label, marker, or position that repeats it.
• Text scales to 130% without clipping. Rows grow; type does not shrink to fit.
• Layout mirrors fully in RTL. Icons that encode direction mirror; logos and numerals do not.
• Both modes are first-class. Neither is a filter applied to the other.

15 · Platforms

The tokens are identical everywhere. What differs is what each platform's conventions force on us — hit-target floors, safe areas, input model, and the native behaviours we deliberately switch off so DDS still looks like DDS.

iOS / iPadOS

• Never hardcode the home-indicator inset. Tab bar height is 56 + safeAreaInsets.bottom.
• Large titles are off. DDS uses its own 56pt bar with a title 20 heading.
• Amount fields use the decimal pad and the mono face, so the keyboard and the value agree.
• Haptics: .light impact on tap, .selection on tab and segment change.
• Continuous corners are disabled — DDS radii are plain, on every platform.

Android

• The Material ripple is replaced by a 100ms surface-step press state. Splash factory is set to none.
• Minimum hit target rises to 48 × 48 dp — the visual control size does not change.
• Edge-to-edge with transparent system bars; icon brightness follows the mode.
• Stretch overscroll is disabled in favour of a clamped scroll physics.
• Elevation is zero on every surface. Depth is borders, as everywhere else.

Web & desktop

• Hover states apply only under @media (hover: hover) and (pointer: fine).
• Focus rings use :focus-visible. Outlines are never removed, only restyled.
• Full keyboard model: Tab order follows layout, Esc closes overlays, Enter submits, arrows move within tabs and segmented controls.
• Scrollbars are 8px, thumb text_3, no arrows, no track.
• Selection background is the accent with on_accent text.
• Print forces light mode, keeps hairlines, and drops navigation chrome.
• Desktop windows have a custom 44px title bar and a 720 × 560 minimum size.

Token implementations

DDS tokens live in shared/design/dot-tokens.yaml as the single source of truth. Each platform mirrors them into native code. There is no auto-generation — the yaml is the contract, each project owns its translation.

class DdsBase {
  // Dark
  static const darkBg        = Color(0xFF000000);
  static const darkSurface   = Color(0xFF0B0B0B);
  static const darkSurface2  = Color(0xFF141414);
  static const darkBorder    = Color(0xFF1F1F1F);
  static const darkText      = Color(0xFFFFFFFF);
  static const darkText2     = Color(0xFF777777);

  // Light
  static const lightBg       = Color(0xFFF7F7F7);
  static const lightSurface  = Color(0xFFFFFFFF);
  static const lightBorder   = Color(0xFFE0E0E0);
  static const lightText     = Color(0xFF111111);
  static const lightText2    = Color(0xFF666666);
}

class DdsUiAccent {
  // Dot Red — same for all products
  static const dark    = Color(0xFFFF2D2D);
  static const light   = Color(0xFFE80000);
  static const pressed = Color(0xFFE52626);
}

class DdsSize {
  static const xs = 24.0, sm = 32.0, md = 40.0, lg = 48.0, xl = 56.0;
}

class DdsRadii {
  static const xs = 2.0;   // checkboxes, badges
  static const sm = 4.0;   // all controls
  static const md = 8.0;   // sheets, frames
}

// Ripple off, elevation zero — depth is borders.
final ddsTheme = ThemeData(
  splashFactory: NoSplash.splashFactory,
  highlightColor: Colors.transparent,
);

:root {
  /* Light mode (default) */
  --bg: #F7F7F7;
  --surface: #FFFFFF;
  --border: #E0E0E0;
  --text: #111111;
  --text-2: #666666;
  --accent: #E80000;
  --accent-pressed: #B80000;

  /* Control ladder */
  --control-xs: 24px;
  --control-sm: 32px;
  --control-md: 40px;
  --control-lg: 48px;
  --control-xl: 56px;
}

[data-theme="dark"] {
  --bg: #000000;
  --surface: #0B0B0B;
  --border: #1F1F1F;
  --text: #FFFFFF;
  --text-2: #777777;
  --accent: #FF2D2D;
  --accent-pressed: #E52626;
}

.btn-primary {
  height: var(--control-lg);
  padding-inline: 16px;
  background: var(--accent);
  color: #FFFFFF;
  border: 1px solid var(--accent);
  border-radius: 4px;
  font: 600 13px 'Space Grotesk';
}

@media (hover: hover) and (pointer: fine) {
  .btn-primary:hover { background: color-mix(in srgb, var(--accent) 88%, #FFF); }
}
.btn-primary:active { background: var(--accent-pressed); }
.btn-primary:focus-visible { outline: 2px solid var(--accent); outline-offset: 2px; }

enum DdsBase {
  static let darkBg       = Color(hex: 0x000000)
  static let darkSurface  = Color(hex: 0x0B0B0B)
  static let darkBorder   = Color(hex: 0x1F1F1F)
  static let darkText     = Color(hex: 0xFFFFFF)

  static let lightBg      = Color(hex: 0xF7F7F7)
  static let lightSurface = Color(hex: 0xFFFFFF)
  static let lightBorder  = Color(hex: 0xE0E0E0)
  static let lightText    = Color(hex: 0x111111)
}

enum DdsUiAccent {
  // Dot Red — same for all products
  static let dark  = Color(hex: 0xFF2D2D)
  static let light = Color(hex: 0xE80000)
}

enum DdsSize {
  static let xs: CGFloat = 24, sm = 32, md = 40, lg = 48, xl = 56
  static let minTarget: CGFloat = 44
}

// Plain corners, not continuous — and a 44pt target around a smaller control.
extension View {
  func ddsControl(_ height: CGFloat) -> some View {
    self.frame(height: height)
      .clipShape(RoundedRectangle(cornerRadius: 4, style: .circular))
      .contentShape(Rectangle())
      .frame(minWidth: DdsSize.minTarget, minHeight: DdsSize.minTarget)
  }
}

16 · What we measured against

DDS is opinionated, but it is not invented from nothing. Before fixing the control ladder and the spacing half-step we read what the large public systems actually publish, and where a number already had a good answer we took it rather than inventing a worse one.

The pattern is consistent: we take accessibility floors from the platform owners, because those are constraints rather than opinions, and we reject everything that would add a second visual language on top of ours.

17 · Governance & versioning

DDS is versioned semantically. The current version is 1.3.0.

• Patch (1.x.y) — accent contrast tweaks, doc corrections.
• Minor (1.y.0) — new component, new token, new size step. Backwards compatible.
• Major (x.0.0) — breaking: removed tokens, changed monochrome base, new type family.

Any change to the yaml must be mirrored in every consuming project's local token file before that project's next release. The yaml is the contract.

Changelog