Get in touch
Design

Designing the pixel system

Every mark on this site is drawn on the same grid, in the same light, out of the same ramp of colours. Here is the grid, the light, and the ramp.

By Ovadev3 min read

All posts
  • identity
  • design system
  • svg

We wanted an identity that a small studio could actually maintain: no illustrator on retainer, no asset pipeline, no folder of PNGs that drift out of sync with the brand. So we picked constraints tight enough that the system draws most of itself.

One grid#

Every colour mark on this site is a 20×20 character map. Twenty is small enough that a shape has to be decided rather than described, and large enough for a rim light and one accent detail. The maps live as .pxl text files, which means an icon reviews like code — you can see a diff of a redesign.

The palette icon at 20×20 — outline, fill, inner rim, one accent.

The build step merges neighbouring cells of the same colour into runs, so a twenty-by-twenty map becomes maybe thirty rectangles instead of four hundred. That is what makes it cheap enough to inline the whole icon into the HTML and skip the request entirely.

One light#

Light falls from the top left, always. It sounds trivial and it is the single rule that makes fifteen icons drawn months apart look like a set: highlight on the top and left faces, the hue itself in the middle, the deepened step on the bottom and right.

  • Step 1 — the tint. Rim light and the top face of anything isometric.
  • Step 3 — the hue. The body of the object, and most of its area.
  • Step 5 — the deepened step. Right faces, undersides, and the one-cell outline.
  • Never steps 2 and 4 next to each other: neighbouring steps collapse into one tone at icon size, and the object stops reading as an object.

One ramp, ten palettes#

The site's colours are slots, not values. Components paint in var(--c1) through var(--c6); a palette definition fills those six slots, and a theme decides how bright each one has to be to survive its background. Nothing in a component ever names a hex code.

css
[data-palette="arcade"]{
  --c1:#2E5BFF; --c2:#16C2C2; --c3:#FFC53D;
  --c4:#FF4D6D; --c5:#8A6BFF; --c6:#1B2340;
}
/* dark needs more light in the mid-tones, or c6 disappears */
:root[data-theme="dark"][data-palette="arcade"]{
  --c1:#5E82FF; --c2:#33E0E0; --c3:#FFD35E;
  --c4:#FF6E88; --c5:#A88BFF; --c6:#8E98C0;
}

The switcher itself is a separate story. The monochrome palettes are the interesting case: they fill all six slots with tones of one accent. Anything built correctly on the ramp goes tonal instead of breaking, which is a useful test — if a component looks wrong in monochrome, it was relying on a hue to carry meaning that should have been carried by value.

Where it stops#

Two things deliberately ignore the palette: the pixel icons and the coat of arms in the footer. They are fixed-colour marks, the way a flag is, and they have to hold up unchanged on both themes. Everything that is chrome follows the palette; everything that is identity does not.

Ovadev

A software company in Baar, Zug. We build our own products, run them afterwards, and write down what that teaches us.

Get in touch
Read next

More from the studio — design first, then the rest of the feed.

All posts
© 2026 Ovadev GmbHMade in Switzerland