Kontext und Architektur
Ein Produkt. Drei Arten, Entscheidungen zu treffen.
Käufer, Verkäufer und Moderatoren teilen ein System, benötigen aber unterschiedliche Berechtigungen, Signale und Wege.
Fallstudie
Buy&Sell Marketplace
Bei einem im Team entwickelten Marktplatz verband ich die UX/UI-Ausrichtung, das Designsystem und die Frontend-Implementierung, für die ich verantwortlich war.
- 3 Rollen
- unterschiedliche Berechtigungen und Nutzerwege
- Figma → Angular
- Designsystem in Komponenten übersetzt
- Full Stack
- mit API und Daten verbundene Oberfläche
Zusammenarbeit: Ein gemeinsam erarbeitetes Master-Abschlussprojekt; meine Urheberschaft beschränkt sich auf den in dieser Fallstudie beschriebenen Beitrag
Ein funktionsfähiges Hochschulprojekt. Es wird weder als kommerzielles Produkt noch als Einzelprojekt dargestellt.
Eine Identität, die zum Produkt wirdVom Material zum Marktplatz.
Designsystem
Die Grundlagen nehmen Gestalt an.
Tokens, Navigation, Zustände und Komponenten werden vor dem Aufbau der Seiten geordnet.
Produkterlebnis
Entdecken, verstehen und handeln.
Die Oberfläche übersetzt Katalog, Vertrauen und Artikelzustände in klare Auswahlmöglichkeiten.
Implementiertes Produkt
Das System besteht die Übergabe.
Figma definiert die Sprache; Angular, Node und MySQL zeigen, wie sie mit Komponenten, Berechtigungen und realen Daten funktioniert.
Die Einleitung endet. Das Produkt beginnt.
Vom System zum Erlebnis.
Entscheidungen, Komponenten und echter Code des Marktplatzes.Problem
Ich begann mit einer Frage, nicht mit einer Bildschirmansicht: Was muss jede Rolle sehen, um auf einem Marktplatz fundiert entscheiden zu können? Käufer, Moderatoren und Administratoren betrachten dasselbe Produkt, treffen aber unterschiedliche Entscheidungen.
Wir untersuchten vertraute Muster — Produktseiten, Verkaufszustände und Verkäufersignale —, um die Informationen hinter jedem Nutzerweg zu verstehen. Diese Analyse lenkte meinen Blick auf den Moderationsablauf, in dem wir entscheiden mussten, was sichtbar sein und was gesperrt werden sollte.
Daraus definierten wir einen Lebenszyklus — Entwurf, veröffentlicht, in Prüfung, zurückgezogen, reserviert und verkauft —, der das Datenmodell und das Erlebnis jeder Rolle prägt. Ich behandelte das Produkt nicht als isolierte Ansicht: Jeder Zustand verändert, wer was tun darf.
Methoden:Vergleichsanalyse von Referenz-Marktplätzen · Nutzerhypothesen nach Rolle: Käufer/Verkäufer, Moderator, Administrator · Informationsarchitektur und Zustandsübersicht des Produkts · Sitemap und rollenbasierte Abläufe, bevor eine einzige Ansicht gezeichnet wurde.
System
In Figma ordnete ich das System in Atome, Moleküle und Organismen, damit wir Varianten und Zustände besprechen konnten, bevor wir Angular öffneten. Badges, Schaltflächen, Karten, Suche und Panels wurden als Elemente entworfen, die im Code dieselbe Logik bewahren müssen.
Die Unterschiede zwischen den Rollen wurden schnell in den Kopfbereichen sichtbar: Wir brauchten keinen allgemeinen Header, sondern zu den Berechtigungen passende Zugänge. Mit dieser Unterscheidung stimmte ich die visuelle Hierarchie darauf ab, was jede Person sehen oder verwalten darf.
Mit dem interaktiven Prototyp konnten wir die Abläufe jeder Rolle durchgehen, offene Entscheidungen erkennen und die Struktur anpassen, bevor ich meine Teile des Frontends implementierte.
KI im Prozess
KI wurde als dokumentiertes Werkzeug zur Beschleunigung eingebunden, nicht als Autor. Sie half bei der Erkundung von Komponentenvarianten, beim schnelleren Erstellen wiederkehrender Codegerüste und bei der Bewertung von Architekturentscheidungen. Die endgültigen Entscheidungen trafen in jeder Phase Menschen anhand von Klarheit, Barrierefreiheit, Systemkonsistenz und technischer Machbarkeit.
- Werkzeug
- Claude · Codex (Programmier- und Designassistenten)
- Phase
- Varianten erkunden, Komponentengerüste erstellen und Architektur bewerten
- Menschlicher Beitrag
- Atomares Designsystem in Figma, Datenmodell, Kriterien für Barrierefreiheit und Konsistenz
- KI-Ergebnis
- Komponentenvarianten und vorgeschlagene Strukturen zur Prüfung
- Auswahlkriterien
- Klarheit, Barrierefreiheit, Systemkonsistenz, Nutzernachweise und technische Machbarkeit
- Erkannte Grenzen
- KI schlägt Hierarchien und Abläufe vor, entscheidet sie aber nicht. Jede Ausgabe wird am Prototyp und Datenmodell geprüft
- Endgültige Entscheidung
- Menschliche Entscheidungen in jeder Phase. KI beschleunigt, Urteilsvermögen gibt die Richtung vor
Implementierung
Als UX/UI-Verantwortlicher definierte ich die visuelle Sprache und die Struktur des gemeinsamen Systems. In der Entwicklung implementierte ich Registrierung, Profil und Profilbearbeitung in Angular und hielt sie mit den Entwürfen für Desktop und Mobilgeräte konsistent.
Das vollständige Produkt verband Angular, eine Node/Express-API und MySQL. Ein anderes Teammitglied war für Backend und Datenbank verantwortlich; meine Aufgabe war es, das Nutzungserlebnis zu gestalten und meinen Frontend-Anteil an die Verträge des Teams anzubinden.
Die Implementierung zeigte die Lücke zwischen einem idealen Prototyp und einem Teamprodukt: Einschränkungen der gemeinsamen Anwendungshülle, API-Abhängigkeiten und von verschiedenen Personen entwickelte Komponenten. Diese Abstimmung ist Teil der Fallstudie und nichts, was verborgen werden sollte.
Nachweise
Die teilbaren Nachweise verbinden die akademische Bewertung des Master-Abschlussprojekts, Funktionstests rollenbasierter Abläufe und eine heuristische Bewertung anhand der im UX/UI-Master vermittelten Prinzipien. Damit prüfte ich das Zusammenspiel von Design, Code und Daten, ohne eine Hochschulaufgabe als kommerzielle Validierung darzustellen.
Vom Prototyp zur Komponente
Aufbau des Systems
- atoms / badge · button · button-icon · icon · link-icon · toast
- molecules / cards · buscador · user-card · user-contact · breadcrum · report-modal
- organisms / guest-header · user-header · moderator-header · admin-moderator-header
- organisms / admin · reports · incidents · historic-moderator
Code · Implementierungsnachweis
import { Component, computed, input } from '@angular/core';
import { BadgeIcon, BadgeIconPosition } from './badge.types';
@Component({
selector: 'atom-badge',
templateUrl: './badge.html',
styleUrl: './badge.css',
})
export class Badge {
variant = input<string>('Como nuevo');
icon = input<BadgeIcon>('none');
iconPosition = input<BadgeIconPosition>('left');
protected label = computed(() =>
this.variant().replace(/_/g, ' ')
);
protected classes = computed(() =>
`app-badge app-badge--${this.cssVariant()}`
);
}frontend/src/app/components/atoms/badge/badge.ts
Eine reale Komponente aus dem Master-Abschlussprojekt: das Badge-Atom in Angular (signals). Seine typisierten Varianten bilden direkt die MySQL-Enumeration ab — vom Prototyp zur Komponente und von der Komponente zu den Daten.
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← MySQL-Enumeration in der Tabelle productos
Nachweise
Die Arbeit, offen zur Überprüfung.
Der Prototyp ist ein Teil des Prozesses: Er dokumentiert das System, die Entscheidungen und die Abläufe hinter dem Produkt.
Entwurf in Figma öffnenErkenntnisse
Ich habe gelernt, dass Atomic Design in Figma nur dann einen Mehrwert bringt, wenn es die Übergabe übersteht: Die Frontend-Struktur muss diese Logik erhalten.
Der Moderationsablauf prägt das Datenmodell, selbst wenn er auf der Startseite des Produkts kaum sichtbar ist.
Die Typisierung des Frontends anhand der Datenbank-Enumerationen half mir, Zustände einzugrenzen, die die Oberfläche nicht zulassen sollte.
Offene Frage:Wie beeinflusst die Informationsarchitektur die Einführung eines Verwaltungssystems bei Menschen in nichttechnischen Rollen?
Kontakt
Lass uns sprechen.
Wenn du denkst, dass meine Arbeitsweise zu deinem Team passt, oder ein Produkt beziehungsweise ein Forschungsprojekt entwickeln möchtest, würde ich gern mehr erfahren. Erzähle mir, was du brauchst und wo du gerade stehst. Ich lese deine Nachricht persönlich.
Du findest mich auch auf LinkedIn