Studium przypadku

Buy&Sell Marketplace

W platformie handlowej tworzonej zespołowo połączyłem kierunek UX/UI, system projektowy i implementację frontendu, za którą odpowiadałem.

Kontekst: Projekt końcowy studiów magisterskich · Full Stack Development (UNIR) · Kompleksowy projekt zespołowy
Wkład: Kierunek UX/UI, system projektowy i implementacja frontendu rejestracji oraz profilu
Technologie: FigmaAngularNode.jsExpressBootstrapMySQLNext.js
Rok: 2026

3 role: odrębne uprawnienia i ścieżki użytkowników
Figma → Angular: system projektowy przełożony na komponenty
Full stack: interfejs połączony z API i danymi

Współpraca: Projekt zespołowy wykonany na zakończenie studiów magisterskich; moje autorstwo ogranicza się do wkładu opisanego w tym studium przypadku

Działający projekt akademicki. Nie przedstawiam go jako produktu komercyjnego ani projektu indywidualnego.

Tożsamość, która staje się produktemOd materii do platformy handlowej.

Niebieski porządkuje, biały informuje, a pomarańczowy zachęca do działania.

Kontekst i architektura

Jeden produkt. Trzy sposoby podejmowania decyzji.

Kupujący, sprzedający i moderatorzy korzystają z tego samego systemu, lecz potrzebują innych uprawnień, sygnałów i ścieżek.

System projektowy

Podstawy nabierają kształtu.

Tokeny, nawigacja, stany i komponenty są porządkowane przed budową ekranów.

Doświadczenie produktu

Odkrywaj, rozumiej i działaj.

Interfejs przekłada katalog, zaufanie i stan każdego przedmiotu na jasne wybory.

Zaimplementowany produkt

System wytrzymuje przekazanie do wdrożenia.

Figma definiuje język; Angular, Node i MySQL pokazują jego działanie z komponentami, uprawnieniami i rzeczywistymi danymi.

Zobacz zaimplementowany produkt Poznaj system w Figmie

Wstęp się kończy. Zaczyna się produkt.

Od systemu do doświadczenia.

Decyzje, komponenty i rzeczywisty kod platformy handlowej.

Odkryj projekt Otwórz prototyp w Figma ↗

Problem

Zacząłem od pytania, nie od ekranu: co musi zobaczyć każda rola, aby podejmować świadome decyzje na platformie handlowej? Kupujący, moderatorzy i administratorzy patrzą na ten sam produkt, lecz podejmują różne decyzje.

Przeanalizowaliśmy znane wzorce — strony produktów, stany sprzedaży i sygnały dotyczące sprzedawcy — aby zrozumieć informacje wspierające każdą ścieżkę. Analiza skierowała moją uwagę na proces moderacji, w którym trzeba było zdecydować, co pokazać, a co zablokować.

Na tej podstawie zdefiniowaliśmy cykl życia — szkic, opublikowany, w weryfikacji, wycofany, zarezerwowany i sprzedany — który kształtuje model danych oraz doświadczenie każdej roli. Nie traktowałem produktu jak odizolowanego ekranu: każdy stan zmienia to, kto i co może zrobić.

Metody:Analiza porównawcza referencyjnych platform handlowych · Hipotezy dotyczące użytkowników według roli: kupujący/sprzedający, moderator, administrator · Architektura informacji i mapa stanów produktu · Mapa witryny i przepływy według ról przed narysowaniem pierwszego ekranu.

Podstawy

System

W Figmie uporządkowałem system na atomy, molekuły i organizmy, abyśmy mogli omówić warianty i stany przed otwarciem Angulara. Etykiety, przyciski, karty, wyszukiwarka i panele powstały jako elementy, które muszą zachować tę samą logikę w kodzie.

Różnice między rolami szybko ujawniły się w nagłówkach: potrzebowaliśmy nie ogólnego nagłówka, lecz punktów dostępu dopasowanych do uprawnień. Wykorzystałem to rozróżnienie, aby zgrać hierarchię wizualną z tym, co dana osoba może przeglądać lub czym zarządzać.

Interaktywny prototyp pozwolił nam przejść przez przepływy każdej roli, wskazać nierozstrzygnięte decyzje i skorygować strukturę, zanim zaimplementowałem swoje części frontendu.

Komponenty list i stany w systemie projektowym Buy&Sell — Komponenty

AI w procesie

AI zostało włączone do procesu jako udokumentowane narzędzie przyspieszające pracę, nie jako autor. Służyło do eksploracji wariantów komponentów, przyspieszania powtarzalnego tworzenia szkieletów kodu i oceny decyzji architektonicznych. Na każdym etapie ostateczne decyzje podejmowali ludzie, uwzględniając przejrzystość, dostępność, spójność systemu i wykonalność techniczną.

Narzędzie: Claude · Codex (asystenci programowania i projektowania)
Etap: Eksploracja wariantów, tworzenie szkieletów komponentów i ocena architektury
Wkład człowieka: Atomowy system projektowy w Figmie, model danych, kryteria dostępności i spójności
Wynik AI: Warianty komponentów i proponowane struktury do przeglądu
Kryteria wyboru: Przejrzystość, dostępność, spójność systemu, dowody od użytkowników i wykonalność techniczna
Wykryte ograniczenia: AI proponuje hierarchie i przepływy, ale o nich nie decyduje. Każdy wynik jest sprawdzany względem prototypu i modelu danych
Ostateczna decyzja: Ludzkie decyzje na każdym etapie. AI przyspiesza, osąd wyznacza kierunek

Implementacja

Jako lider UX/UI zdefiniowałem język wizualny i strukturę wspólnego systemu. Podczas programowania zaimplementowałem w Angularze rejestrację, profil i edycję profilu, zachowując zgodność z ich projektami na komputer i telefon.

Cały produkt łączył Angulara, API Node/Express i MySQL. Za backend oraz bazę danych odpowiadał inny członek zespołu; moim zadaniem było zaprojektowanie doświadczenia i połączenie mojej części frontendu z kontraktami zespołu.

Implementacja ujawniła różnicę między idealnym prototypem a produktem zespołowym: ograniczenia wspólnej powłoki aplikacji, zależności API i komponenty rozwijane przez różne osoby. Te uzgodnienia są częścią studium przypadku, a nie czymś do ukrycia.

Strona główna platformy Buy&Sell — Produkt końcowy

Dowody

Dowody, które mogę udostępnić, łączą akademicką ocenę projektu końcowego, testy funkcjonalne przepływów według ról oraz ocenę heurystyczną opartą na zasadach poznanych na studiach UX/UI. Pomogły mi sprawdzić spójność projektu, kodu i danych bez przedstawiania ćwiczenia akademickiego jako walidacji komercyjnej.

Podstawy

Od prototypu do komponentu

Organizacja systemu

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

Kod · dowód implementacji

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

Rzeczywisty komponent z projektu końcowego: atom Badge w Angularze (signals). Jego typowane warianty odwzorowują bezpośrednio enum MySQL — od prototypu do komponentu, a od komponentu do danych.

Dowody

Praca otwarta na ocenę.

Prototyp jest częścią procesu: dokumentuje system, decyzje i przepływy, na których opiera się produkt.

Otwórz projekt w Figmie

Wnioski

Nauczyłem się, że atomowy projekt w Figmie wnosi wartość tylko wtedy, gdy przetrwa przekazanie do wdrożenia: struktura frontendu musi zachować tę logikę.

Proces moderacji kształtuje model danych, nawet jeśli prawie nie widać go na stronie głównej produktu.

Typowanie frontendu zgodnie z enumami bazy danych pomogło mi ograniczyć stany, na które interfejs nie powinien pozwalać.

Otwarte pytanie:Jak architektura informacji wpływa na przyjęcie systemu zarządzania przez osoby na stanowiskach nietechnicznych?

Kontakt

Porozmawiajmy.

Jeśli uważasz, że mój sposób pracy pasuje do Twojego zespołu, albo masz produkt lub projekt badawczy, który chcesz rozwijać, chętnie dowiem się więcej. Napisz, czego potrzebujesz i na jakim jesteś etapie. Osobiście przeczytam Twoją wiadomość.

Znajdziesz mnie również na LinkedIn