Contexto e arquitetura
Um produto. Três formas de decidir.
Compradores, vendedores e moderadores partilham o sistema, mas precisam de permissões, sinais e percursos diferentes.
Caso de estudo
Buy&Sell Marketplace
Num marketplace desenvolvido em equipa, liguei a direção UX/UI, o sistema de design e a implementação de frontend pela qual era responsável.
- 3 papéis
- permissões e percursos distintos
- Figma → Angular
- sistema de design traduzido em componentes
- Full stack
- interface ligada a uma API e aos dados
Colaboração: Projeto realizado em equipa no âmbito do trabalho final de mestrado; a minha autoria limita-se ao contributo descrito neste caso de estudo
Um projeto académico funcional. Não é apresentado como produto comercial nem como projeto individual.
Uma identidade que se transforma num produtoDa matéria ao marketplace.
Sistema de design
Os fundamentos ganham forma.
Tokens, navegação, estados e componentes são organizados antes da construção dos ecrãs.
Experiência de produto
Explorar, compreender e agir.
A interface transforma o catálogo, a confiança e o estado de cada artigo em escolhas claras.
Produto implementado
O sistema resiste à passagem para desenvolvimento.
Figma define a linguagem; Angular, Node e MySQL demonstram o seu funcionamento com componentes, permissões e dados reais.
O preâmbulo termina. O produto começa.
Do sistema à experiência.
Decisões, componentes e código real do marketplace.Problema
Comecei por uma pergunta, não por um ecrã: o que precisa cada papel de ver para tomar decisões informadas num marketplace? Compradores, moderadores e administradores olham para o mesmo produto, mas tomam decisões diferentes.
Analisámos padrões conhecidos — páginas de produto, estados de venda e sinais do vendedor — para compreender a informação que apoia cada percurso. Essa análise chamou a minha atenção para o fluxo de moderação, onde tínhamos de decidir o que mostrar e o que bloquear.
A partir dessa análise, definimos um ciclo de vida — rascunho, publicado, em revisão, retirado, reservado e vendido — que molda o modelo de dados e a experiência de cada papel. Não tratei o produto como um ecrã isolado: cada estado altera quem pode fazer o quê.
Métodos:Análise comparativa de marketplaces de referência · Hipóteses de utilizadores por papel: comprador/vendedor, moderador, administrador · Arquitetura de informação e mapa de estados do produto · Mapa do site e fluxos por papel antes de desenhar um único ecrã.
Sistema
Em Figma, organizei o sistema em átomos, moléculas e organismos para discutirmos variantes e estados antes de abrir Angular. Distintivos, botões, cartões, pesquisa e painéis foram concebidos como elementos que tinham de preservar a mesma lógica no código.
As diferenças entre papéis tornaram-se rapidamente claras nos cabeçalhos: não precisávamos de um cabeçalho genérico, mas de acessos ajustados a cada permissão. Usei essa distinção para alinhar a hierarquia visual com aquilo que cada pessoa pode ver ou gerir.
O protótipo interativo permitiu-nos percorrer os fluxos de cada papel, identificar decisões em aberto e ajustar a estrutura antes de implementar as minhas partes do frontend.
IA no processo
A IA foi integrada como acelerador documentado, não como autora. Foi usada para explorar variantes de componentes, acelerar a criação repetitiva de estruturas-base e avaliar decisões de arquitetura. Em todas as fases, as decisões finais foram humanas, tendo em conta clareza, acessibilidade, coerência com o sistema e viabilidade técnica.
- Ferramenta
- Claude · Codex (assistentes de programação e design)
- Fase
- Exploração de variantes, criação de estruturas-base de componentes e avaliação de arquitetura
- Contributo humano
- Sistema de design atómico em Figma, modelo de dados, critérios de acessibilidade e coerência
- Resultado da IA
- Variantes de componentes e propostas de estrutura para revisão
- Critérios de seleção
- Clareza, acessibilidade, coerência do sistema, evidências dos utilizadores e viabilidade técnica
- Limites identificados
- A IA propõe hierarquias e fluxos, não os decide. Cada resultado é revisto face ao protótipo e ao modelo de dados
- Decisão final
- Decisões humanas em cada fase. A IA acelera; o critério orienta
Implementação
Como responsável de UX/UI, defini a linguagem visual e a estrutura do sistema partilhado. Durante o desenvolvimento, implementei os fluxos de registo, perfil e edição de perfil em Angular, mantendo a coerência com os respetivos designs para computador e telemóvel.
O produto completo ligava Angular, uma API Node/Express e MySQL. Outro membro da equipa era responsável pelo backend e pela base de dados; o meu trabalho era desenhar a experiência e ligar a minha parte do frontend aos contratos da equipa.
A implementação revelou a distância entre um protótipo ideal e um produto feito em equipa: limitações da estrutura partilhada da aplicação, dependências da API e componentes desenvolvidos por pessoas diferentes. Essa negociação faz parte do caso de estudo, não é algo a esconder.
Evidências
As evidências que posso partilhar combinam a avaliação académica do projeto final de mestrado, testes funcionais dos fluxos por papel e uma avaliação heurística segundo os princípios estudados no mestrado em UX/UI. Ajudaram-me a rever o alinhamento entre design, código e dados sem apresentar um exercício académico como validação comercial.
Do protótipo ao componente
Organização do sistema
- 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
Código · evidência de implementação
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
Um componente real do projeto final de mestrado: o átomo Badge em Angular (signals). As suas variantes tipadas correspondem diretamente ao enum de MySQL — do protótipo ao componente e do componente aos dados.
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← enum de MySQL na tabela productos
Evidências
O trabalho, aberto a revisão.
O protótipo é uma parte do processo: documenta o sistema, as decisões e os fluxos que sustentam o produto.
Abrir o design em FigmaAprendizagens
Aprendi que o design atómico em Figma só acrescenta valor se resistir à passagem para desenvolvimento: a estrutura do frontend tem de preservar essa lógica.
O fluxo de moderação molda o modelo de dados, mesmo quando é pouco visível na página inicial do produto.
Tipar o frontend de acordo com os enums da base de dados ajudou-me a limitar estados que a interface não deveria permitir.
Pergunta em aberto:Como influencia a arquitetura de informação a adoção de um sistema de gestão por pessoas em funções não técnicas?
Contacto
Vamos conversar.
Se achas que a minha forma de trabalhar se adequa à tua equipa, ou tens um produto ou uma investigação que gostarias de desenvolver, gostaria de saber mais. Conta-me de que precisas e em que ponto estás. Lerei a tua mensagem pessoalmente.
Também me podes encontrar no LinkedIn