voxcog: Designsystem im Code und Nutzertests
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.
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.
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
- 17Befunde 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.
- 373Testdateien
- Neben dem Code abgelegt, den sie abdecken. Die Auswertungen des Agenten liegen darunter und laufen als eigene Befehle.
- 300Zeilen 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.
Belege
Worauf dieser Artikel beruht — eine Messung von uns, eine datierte Quelle oder eine Entscheidung und ihr Preis.
- Messung
Wie viele von siebzehn gemeldeten Oberflächenproblemen echt waren
Messobjekt: voxcogs App, Forschungsbericht vom 2. April 2026
Methode: Jeder Befund wurde vor jedem Codeeingriff gegen die genannte Komponente gelesen und das Ergebnis als hält, teilweise oder fällt notiert.
Ergebnis: 11 hielten, 1 teilweise, 5 fielen
- Entscheidung
Die fünf abgelehnten Befunde wurden samt Begründung der Ablehnung festgehalten.
Was sie gekostet hat: Die Runde lieferte zwölf Änderungen, wo siebzehn gewünscht waren, und die Funktionsideen des Berichts blieben als Hypothesen außen vor.
- Entscheidung
Alles Visuelle wird als Token in OKLCH ausgedrückt und über Variablen benutzt.
Was sie gekostet hat: Einmalige Kosten am Anfang und eine Regel, die zu halten ist: eine neue Farbe braucht erst einen neuen Token.
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.
Erzählen Sie uns, was Sie bauen wollen
Dreißig Minuten, kostenlos, und eine klare Antwort, ob wir das richtige Studio dafür sind.