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

Jak powstało Buy&Sell.

Od systemu do doświadczenia.

Decyzje, komponenty i rzeczywisty kod platformy handlowej.

Odkryj projekt Otwórz prototyp w Figma ↗

Problem

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.

Przed zaprojektowaniem ekranów przeanalizowaliśmy potrzeby każdej roli. Przyjrzeliśmy się znanym wzorcom — stronom produktów, stanom sprzedaży i informacjom o sprzedawcy — aby zrozumieć, jakich informacji wymaga każda ścieżka. 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. Każdy stan zmienia to, kto może przeglądać i modyfikować produkt lub nim zarządzać.

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.

Zaprojektowałem nagłówki z różnymi punktami dostępu zależnie od uprawnień każdej roli, tak aby każdy mógł znaleźć dostępne dla siebie opcje.

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

Wykorzystywaliśmy AI do eksploracji wariantów komponentów, generowania powtarzalnych struktur kodu i oceny decyzji architektonicznych. Dokumentowaliśmy jej użycie, a ostateczne decyzje pozostawały w rękach zespołu, który oceniał przejrzystość, dostępność, spójność z systemem 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.

Podczas implementacji musieliśmy dostosować projekt do wspólnej struktury aplikacji, zależności API i komponentów opracowanych przez innych członków zespołu.

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