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.
Wie Buy&Sell umgesetzt wurde.
Vom System zum Erlebnis.
Entscheidungen, Komponenten und echter Code des Marktplatzes.Problem
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.
Vor der Gestaltung der Ansichten untersuchten wir die Bedürfnisse jeder Rolle. Wir analysierten vertraute Muster — Produktseiten, Verkaufszustände und Informationen über Verkäufer —, um zu verstehen, welche Informationen jeder Nutzerweg benötigt. 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. Jeder Zustand verändert, wer das Produkt ansehen, bearbeiten oder verwalten 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.
Ich gestaltete Kopfbereiche mit unterschiedlichen Zugängen je nach den Berechtigungen der jeweiligen Rolle, damit jede Person die für sie verfügbaren Optionen finden konnte.
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
Wir nutzten KI, um Komponentenvarianten zu erkunden, wiederkehrende Codestrukturen zu erzeugen und Architekturentscheidungen zu bewerten. Wir dokumentierten ihren Einsatz; die endgültigen Entscheidungen blieben beim Team, das Klarheit, Barrierefreiheit, Systemkonsistenz und technische Machbarkeit prüfte.
- 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.
Während der Implementierung mussten wir das Design an die gemeinsame Anwendungsstruktur, die API-Abhängigkeiten und die von anderen Teammitgliedern entwickelten Komponenten anpassen.
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