Eine gemeinsame Grundlage für Produkte, Design und Entwicklung.
Das Redrice Framework beschreibt, wie aus realen Arbeitsabläufen verständliche, wartbare und verlässliche Software entsteht. Das Design System ist ein Teil davon – ergänzt um UX, Engineering, Qualität, Dokumentation und Produktlebenszyklus.
01 · Foundation
Software beginnt mit einem nachvollziehbaren Maßstab.
Jede Entscheidung wird daran gemessen, ob sie einen realen Arbeitsablauf verständlicher, zuverlässiger oder einfacher macht.
Usability First
Der nächste sinnvolle Schritt ist sichtbar. Die Oberfläche erklärt sich aus dem Arbeitsablauf.
Arbeitsabläufe statt Features
Eine Funktion ist nur dann wertvoll, wenn sie eine konkrete Aufgabe verbessert.
Ruhe statt Aufmerksamkeit
Keine Gimmicks, keine unnötigen Unterbrechungen und keine dekorative Komplexität.
Qualität als Standard
Qualitätsanforderungen sind sichtbar, konfigurierbar und nachvollziehbar.
Wartbarkeit
Produkte werden für Weiterentwicklung, Betrieb und Übergabe gebaut – nicht nur für den ersten Release.
Vertrauen statt Marketing
Wir beschreiben konkret, was ein Produkt leistet, wie es arbeitet und wo seine Grenzen liegen.
02 · Design System
Eine visuelle Sprache für Website, Plugins und Software.
Tokens und Komponenten reduzieren Einzelentscheidungen und sorgen dafür, dass Redrice-Produkte als Familie erkennbar bleiben.
#A62E35#17212B#FBFAF8#EEF1F3#2F6B50#A46A1FKomponenten
Wenige Varianten, klare Bedeutung.
03 · UX Standards
Die Oberfläche folgt dem Arbeitsablauf.
Progressive Komplexität
Die häufigste Aufgabe steht im Vordergrund. Erweiterte Optionen erscheinen erst, wenn sie gebraucht werden.
- Wesentliches zuerst
- Erklärungen in unmittelbarer Nähe
- Keine Optionen ohne klaren Nutzen
Handlungsorientierte Rückmeldung
Statusmeldungen beschreiben nicht nur einen Zustand, sondern den nächsten sinnvollen Schritt.
- Was ist passiert?
- Was bedeutet das?
- Was kann der Nutzer tun?
Keine überraschenden Eingriffe
Automatische Änderungen benötigen Vorschau, Freigabe, Erfolgsmeldung und Änderungsprotokoll.
Zugänglichkeit
Kontraste, Fokuszustände, Tastaturbedienung und verständliche Bezeichnungen gehören zur Grundqualität.
04 · Engineering
Technische Entscheidungen müssen auch morgen noch tragen.
Engineering umfasst Architektur, Sicherheit, Erweiterbarkeit, Tests, Releases und einen nachvollziehbaren Betrieb.
API First
Wichtige Funktionen werden so gebaut, dass sie automatisiert und integriert werden können.
Klare Grenzen
Module, Datenflüsse und Verantwortlichkeiten bleiben verständlich und testbar.
Sichere Standards
Eingaben validieren, Ausgaben escapen, Berechtigungen prüfen und sensible Daten minimieren.
Beobachtbarer Betrieb
Logs, Diagnostik und verständliche Fehlermeldungen sind Bestandteil des Produkts.
Rückwärtskompatibilität
Updates respektieren bestehende Daten, Einstellungen und Arbeitsabläufe.
Kleine Releases
Überschaubare Änderungen lassen sich besser prüfen, ausrollen und bei Bedarf zurücknehmen.
05 · Quality Standards
Qualität ist kein abschließender Check.
Qualitätsstandards begleiten ein Produkt von der Anforderung bis zum Betrieb und werden an den jeweiligen Anwendungsfall angepasst.
| Bereich | Standard | Nachweis |
|---|---|---|
| Funktion | Der zentrale Arbeitsablauf ist vollständig nutzbar. | Akzeptanztest |
| Usability | Der nächste Schritt ist ohne Zusatzwissen erkennbar. | Praxistest |
| Sicherheit | Eingaben, Rechte und Ausgaben folgen Plattformstandards. | Codeprüfung |
| Kompatibilität | Unterstützte Umgebungen und Abhängigkeiten sind geprüft. | Testmatrix |
| Dokumentation | Installation, Konfiguration und Fehlerbehebung sind beschrieben. | Release-Check |
| Betrieb | Fehler sind erkennbar, nachvollziehbar und behandelbar. | Diagnostik |
06 · Dokumentation
Ein Produkt ist erst fertig, wenn es verständlich ist.
Einführung
Welches Problem löst das Produkt und für wen?
Erste Schritte
Der kürzeste Weg vom Installieren zum ersten sinnvollen Ergebnis.
Konfiguration
Optionen werden nach Arbeitsabläufen statt nach interner Technik erklärt.
Praxis
Konkrete Beispiele zeigen typische Entscheidungen und Ergebnisse.
Fehlerbehebung
Symptom, Ursache, Prüfung und Lösung werden klar getrennt.
Änderungen
Releases beschreiben Auswirkungen und notwendige Schritte.
07 · Product Lifecycle
Von der Beobachtung zum verlässlichen Produkt.
Redrice-Produkte beginnen nicht mit einer Featureliste, sondern mit einem konkreten Arbeitsablauf und einem überprüfbaren Ergebnis.
Beobachten
Den bestehenden Ablauf, Aufwand und Fehlerquellen verstehen.
Eingrenzen
Das kleinste wertvolle Ergebnis und klare Grenzen definieren.
Prototyp
Den Kernablauf früh nutzbar und überprüfbar machen.
Validieren
Mit echten Daten und realen Nutzern prüfen.
Härten
Sicherheit, Qualität, Dokumentation und Betrieb vervollständigen.
Veröffentlichen
Kontrolliert ausrollen, beobachten und verständlich kommunizieren.
Weiterentwickeln
Erfahrungen aus dem Einsatz in gezielte Verbesserungen übersetzen.
08 · Projektstart
Jedes Produkt beginnt mit einem klaren Arbeitsauftrag.
Bevor Architektur, Oberfläche oder Technologie entschieden werden, wird der reale Ablauf beschrieben. Diese Vorlage ist der verbindliche Startpunkt für neue Redrice-Projekte.
Ausgangslage
Was passiert heute? Wer ist beteiligt? Welche Systeme, Daten und manuellen Schritte gehören dazu?
Reibung
Wo entstehen Fehler, Wartezeiten, Doppelarbeit oder Unsicherheit?
Zielzustand
Was soll nach der Umsetzung einfacher, schneller oder verlässlicher sein?
Erster nutzbarer Schritt
Welche kleinste Lösung liefert bereits einen echten Nutzen und kann im Alltag getestet werden?
Qualitätsmaßstab
Woran erkennen Nutzer und Entwickler, dass die Lösung tatsächlich funktioniert?
Grenzen
Was gehört bewusst noch nicht zum ersten Umfang? Welche Annahmen müssen später geprüft werden?
Projektvorlage
Ein Satz, der das Projekt trägt
Für [Nutzergruppe], die [Aufgabe] erledigt, entwickeln wir [Werkzeug], damit [messbares Ergebnis] erreicht wird.
09 · Quality Gates
Qualität wird geprüft, bevor ein Produkt weiterzieht.
Jede Phase besitzt ein klar definiertes Tor. Ein Projekt geht erst weiter, wenn die notwendigen Kriterien erfüllt oder bewusst dokumentiert sind.
Problem verstanden
- Nutzer und Aufgabe sind benannt.
- Der heutige Ablauf ist dokumentiert.
- Der erste sinnvolle Umfang ist abgegrenzt.
Arbeitsablauf nutzbar
- Der zentrale Ablauf kann vollständig durchlaufen werden.
- Fehlerfälle und Rückmeldungen sind verständlich.
- Die Oberfläche wurde im realen Kontext geprüft.
Produktionsbereit
- Sicherheits- und Qualitätsprüfungen sind bestanden.
- Dokumentation und Changelog sind vollständig.
- Rollback, Support und Betrieb sind geklärt.
Weiterentwicklung begründet
- Feedback stammt aus tatsächlicher Nutzung.
- Änderungen lösen ein klar beschriebenes Problem.
- Erfolg und Nebenwirkungen sind überprüfbar.
10 · Release Standard
Ein Release ist ein überprüfbarer Zustand – keine Dateinummer.
Vor jeder Veröffentlichung wird dieselbe Checkliste angewendet. Sie gilt für WordPress-Plugins, Webanwendungen, APIs und interne Werkzeuge.
Funktion
Qualität
Kommunikation
Betrieb
11 · Entscheidungsprotokoll
Wichtige Entscheidungen bleiben nachvollziehbar.
Architektur, Datenmodell, externe Dienste und bewusste Einschränkungen werden knapp dokumentiert. Das schützt Projekte vor wiederholten Grundsatzdiskussionen und erleichtert spätere Änderungen.
Kontext
Welche konkrete Situation oder Einschränkung macht eine Entscheidung notwendig?
Gewählte Lösung
Was wird umgesetzt und welche klare Grenze gehört zur Entscheidung?
Bewusste Abwägung
Welche realistischen Möglichkeiten wurden geprüft und warum nicht gewählt?
Auswirkungen
Welche Vorteile, Kosten, Risiken und späteren Aufgaben entstehen daraus?
Vorlage
Kurzer Architecture Decision Record
# ADR-XXX: Titel
Status: vorgeschlagen | angenommen | ersetzt
Kontext: ...
Entscheidung: ...
Alternativen: ...
Folgen: ...12 · Übergabestandard
Ein Produkt bleibt auch ohne seinen ursprünglichen Entwickler verständlich.
Übergabe bedeutet mehr als Quellcode. Betrieb, Zugang, Grenzen, Entscheidungen und die nächsten sinnvollen Schritte müssen an einer Stelle auffindbar sein.
Produkt
- Zweck und Nutzergruppe
- Kernabläufe und Grenzen
- Aktueller Produktstatus
Technik
- Architektur und Abhängigkeiten
- Lokale Einrichtung und Deployment
- Daten, Migrationen und Backups
Betrieb
- Monitoring und Logs
- Fehlerbehebung und Wiederanlauf
- Verantwortlichkeiten und Kontakte
Weiterentwicklung
- Offene Risiken
- Bewusste Nicht-Ziele
- Priorisierte nächste Schritte
13 · Betrieb & Verantwortung
Nach dem Release beginnt die Verantwortung.
Für jedes produktive System werden Eigentümer, Reaktionswege, Datensicherung und technische Beobachtung festgelegt. Ein Produkt ohne geklärten Betrieb gilt nicht als abgeschlossen.
Wer entscheidet?
Eine benannte Person verantwortet Prioritäten, Risiken und fachliche Entscheidungen.
Woran erkennen wir Probleme?
Logs, Diagnostik und wenige klare Kennzahlen zeigen, ob der Kernablauf funktioniert.
Wie stellen wir wieder her?
Backup, Rollback und Wiederanlauf werden vor dem Ernstfall geprüft.
Wie werden Fälle bearbeitet?
Fehlermeldungen enthalten Kontext, Reproduktionsschritte, Auswirkung und nächsten Schritt.
Verbindliche Betriebsnotiz
System:
[Name und Zweck]
Verantwortlich:
[Owner und Vertretung]
Überwachung:
[Logs, Checks, Kennzahlen]
Wiederherstellung:
[Backup und Rollback]
14 · Teststrategie
Getestet wird dort, wo ein Fehler Wirkung hätte.
Redrice trennt schnelle automatische Prüfungen, reale Arbeitsabläufe und gezielte Regressionstests. Nicht jede Funktion benötigt dieselbe Testtiefe – aber jeder kritische Ablauf benötigt einen belastbaren Nachweis.
Unit & Logik
Berechnungen, Validierung und klar abgegrenzte Regeln werden automatisiert geprüft.
Nachweis: reproduzierbare TestsIntegration
Schnittstellen, Datenbanken, WordPress-Hooks und externe Dienste werden gemeinsam geprüft.
Nachweis: definierte TestumgebungKernablauf
Der wichtigste Nutzerweg wird mit realistischen Daten vollständig durchlaufen.
Nachweis: AkzeptanzszenarioRegression
Behobene Fehler erhalten einen Test oder eine feste Prüfanweisung, damit sie nicht zurückkehren.
Nachweis: verknüpfter FallGünstig, automatisiert, bei jeder Änderung.
Für Datenflüsse und Plattformgrenzen.
Für geschäftskritische Arbeitsabläufe.
15 · Incident Management
Im Fehlerfall zählt ein klarer Ablauf.
Störungen werden nach Auswirkung priorisiert, stabilisiert und anschließend nachvollziehbar ausgewertet. Das Ziel ist nicht Schuldzuweisung, sondern Wiederherstellung und nachhaltige Verbesserung.
Kritisch
Kernprozess steht, Datenverlust oder Sicherheitsrisiko.
Sofort stabilisierenHoch
Wichtiger Ablauf stark eingeschränkt, praktikabler Workaround fehlt.
Priorisiert behebenMittel
Teilfunktion betroffen, Arbeit bleibt mit Umweg möglich.
Geplant korrigierenNiedrig
Kosmetik, Komfort oder Randfall ohne wesentliche Auswirkung.
Bewerten und bündelnErkennen
Auswirkung, betroffene Nutzer und Zeitpunkt erfassen.
Stabilisieren
Schaden begrenzen, Workaround oder Rollback einsetzen.
Beheben
Ursache korrigieren und kritischen Ablauf erneut prüfen.
Lernen
Auslöser, Erkennung und Prävention knapp dokumentieren.
16 · Versionierung & Änderungen
Versionsnummern beschreiben die Wirkung einer Änderung.
Redrice verwendet eine klare Versionslogik und verständliche Änderungsnotizen. Nutzer müssen erkennen können, ob ein Update korrigiert, erweitert oder bewusst Verhalten verändert.
Patch
Fehlerbehebung oder interne Verbesserung ohne geplante Änderung des bestehenden Arbeitsablaufs.
Minor
Neue, rückwärtskompatible Funktion oder sichtbare Erweiterung des Produkts.
Major
Bewusste inkompatible Änderung, Migration oder grundlegende Neuausrichtung.
Jeder Changelog-Eintrag beantwortet vier Fragen
Was?
Welche Funktion oder welches Verhalten wurde geändert?
Warum?
Welches Problem oder Risiko wird damit adressiert?
Auswirkung?
Was bemerken Nutzer, Betrieb oder Integrationen?
Aktion?
Ist nach dem Update ein Schritt erforderlich?
17 · Beispiele
Ein Framework wird durch Anwendung belastbar.
Intra-Community VAT
Validierung, Steuerlogik, Diagnostik und nachvollziehbare Ergebnisse in einem klaren Checkout-Workflow.
Foundation · UX · QualityContent Proofer
Konfigurierbare Qualitätsstandards, Vorschau, Freigabe und Änderungsverlauf statt automatischer Überraschungen.
UX · Design · QualityMarketplace Document Hub
API-first Architektur für Dokumente und Marktplatzprozesse mit klarer Trennung von Integration und Arbeitsoberfläche.
Engineering · Lifecycle · DocsFramework 0.6
Entwicklung und Betrieb greifen jetzt ineinander.
Teststrategie, Incident Management und Versionslogik schließen die Lücke zwischen Umsetzung, Veröffentlichung und verlässlichem Produktbetrieb.