---
title: "voxcog: Designsystem im Code und Nutzertests"
description: "Wie voxcogs Oberfläche ein Designsystem im Code bekam und eine Nutzerstudie, in der fünf von siebzehn Befunden an der Prüfung im Code scheiterten."
url: https://torn.studio/de/arbeiten/voxcog-designsystem-und-nutzertests
locale: de
published: 2026-08-31
updated: 2026-08-26
---

# voxcog: Designsystem im Code und Nutzertests

> **Kurze Antwort:** Torn Studio hat voxcogs Oberfläche auf ein Designsystem im Code gestellt, mit Tokens in OKLCH und einem dokumentierten Regelwerk. Eine Nutzerstudie ergab siebzehn Befunde; elf hielten, einer teilweise und fünf fielen bei der Prüfung im Code. Zwölf Änderungen gingen in den Betrieb.

**Kunde:** voxcog · **Übergeben:** 2026-08-26

**Das Verhältnis des Studios zum Kunden:** voxcog ist ein Produkt, das Torn Studio gebaut hat und an dem das Studio beteiligt ist. Das Studio verantwortete Produktleitung, Architektur und Umsetzung bis zur Übergabe im August 2026.

## Der Auftrag

voxcog brauchte eine Oberfläche, die über rund vierzig Ansichten zusammenhält, gebaut von einer Person in wenigen Monaten, und musste wissen, welche der gemeldeten Probleme echt waren, bevor etwas umgebaut wurde.

## Was es schwierig machte

- Eine in hohem Tempo von einer Person gebaute Oberfläche driftet visuell auseinander, wenn jede Ansicht ihre Farben und Abstände selbst wählen darf.
- Eine Nutzerstudie liefert echte Fehler gemischt mit Wünschen, und alles Gemeldete zu bauen ist der schnellste Weg, die falschen Dinge zu bauen.
- Das Produkt sollte startbereit sein, und das verlangt, dass Leerzustände und Rechtsflächen fertige Arbeit sind.

## Zahlen zum Nachzählen

| Zahlen zum Nachzählen | | |
| --- | --- | --- |
| 17 | Befunde einer Nutzerstudie | Elf hielten, einer teilweise, fünf fielen bei der Prüfung gegen die genannte Komponente. Die Bewertung liegt mit Begründung je Ablehnung im Repository. |
| 12 | Änderungen im Betrieb aus der Studie | Die fünf abgelehnten stehen mit ihrer Begründung im Dokument, sodass die nächste Person sieht, was geprüft und verworfen wurde. |
| 373 | Testdateien | Neben dem Code abgelegt, den sie abdecken. Die Auswertungen des Agenten liegen darunter und laufen als eigene Befehle. |
| 300 | Zeilen Obergrenze je Datei | Die Regel, die Komponenten teilbar hält. Sie steht in der eigenen Anleitungsdatei des Repositorys und gilt für alles Neue. |

## So wurde es gemacht

### Tokens als einzige visuelle Quelle

Farbe, Typografie, Radien und Schatten werden als Tokens in OKLCH deklariert und über Variablen benutzt. Die Regel wurde als eigene Referenz festgehalten, sodass eine neue Ansicht das System erbt und ihre Werte von dort bezieht.

### Jeder Befund wurde zuerst im Code geprüft

Die siebzehn Befunde aus der Runde im April 2026 wurden einzeln gegen die jeweils genannte Komponente gelesen. Elf hielten, einer teilweise, und fünf beschrieben etwas, das bereits funktionierte, oder eine Funktion, die es nicht gab.

### Leerzustände, die Richtung geben

Die dünnen Leerzustände wurden zu kurzen Anleitungen umgeschrieben, die erklären, wofür die Fläche da ist, und einen nächsten Schritt anbieten. Werkzeugleisten bleiben verborgen, solange eine Liste leer ist, sodass Erstnutzer eine Anweisung vorfinden.

### Datenabruf als ein Muster

Alles clientseitige Lesen wanderte auf eine gemeinsame Cache-Schicht mit Schlüsselfabrik und geteilter Fehlerbehandlung. Die Aktualisierungsknöpfe konnten weg, weil die Listen nun selbst wissen, wann sie veraltet sind.

**Technik:** React 19, Next.js 16, Tailwind CSS v4, shadcn/ui, OKLCH, TanStack Query, Playwright

## Was dieser Beleg trägt

Das zeigt eine Oberfläche, die zusammenhält, und eine Arbeitsweise, die echte Probleme von Wünschen trennt. Eine Konversionszahl zeigt es nicht: voxcog wurde vor dem Start übergeben, es gibt also keinen Verkehr zum Messen.

## Häufige Fragen

### Warum prüfen Sie Nutzerbefunde im Code, bevor Sie bauen?

Weil eine Studie echte Fehler mit Wünschen und mit bereits Funktionierendem mischt. Fünf von siebzehn Befunden fielen in dieser Runde bei der Prüfung, und sie zu bauen hätte Zeit gekostet und die Oberfläche verschlechtert.

### Was unterscheidet ein Designsystem von einer Komponentenbibliothek?

Die Bibliothek sind die Komponenten. Das System sind die Regeln, die festlegen, was existieren darf: welche Farben es gibt, welche Abstände erlaubt sind und was passiert, wenn etwas fehlt. Die Regeln halten ein schnell wachsendes Produkt zusammen.

### Warum OKLCH als Farbraum?

OKLCH ist wahrnehmungsgleich, also sieht eine Skala mit gleichmäßigen Schritten auch gleichmäßig aus und der Kontrast lässt sich berechnen. Eine dunkle Variante wird zur Neudefinition der Helligkeit im selben System.

### Was bedeutet es, dass ein Leerzustand Richtung gibt?

Dass die Fläche erklärt, wofür sie da ist, und einen nächsten Schritt anbietet, wenn null Zeilen anzuzeigen sind. Erstnutzer treffen auf eine Anweisung, und Suche und Filter bleiben verborgen, bis es etwas zu durchsuchen gibt.

### Können Sie ein Designsystem für unser bestehendes Produkt bauen?

Ja. Die Arbeit beginnt mit einer Bestandsaufnahme der bereits benutzten Werte, führt sie zu einem Tokensatz zusammen und zieht dann Ansicht für Ansicht um. Das System kommt als Code in Ihr Repository und als geschriebene Referenz.

### Wie viele Ansichten umfasste die Arbeit an der Oberfläche?

Rund vierzig Ansichten über Chat, Dokumente, Signale, Aufgaben, Arbeitsflächen und einen öffentlichen Interviewteil. Alle teilen denselben Tokensatz und dieselbe Komponentenbibliothek.