Em resumo
Função. Product Designer, única designer. De julho de 2024 a maio de 2026, em remoto. Colaboradora freelance desde 2019.
Equipa. Seis programadores (mobile, full-stack, frontend), product managers, apoio ao cliente, vendas e o CTO.
Âmbito. Leitor, painel das editoras, checkout, login, tabelas de subscrição, emails, banners para clientes, várias versões do site e uma plataforma interna de protótipos.
Stack com que trabalhei. Figma para design; Laravel, Livewire, Flux UI e Tailwind para os protótipos, o mesmo stack com que os programadores publicavam.
O problema
A Publica.la permite às editoras distribuir e vender eBooks, audiolivros e revistas com a sua própria marca. Quando entrei como única designer, o produto crescia há anos sem ninguém responsável pelo design. O leitor, o painel e a loja pareciam três produtos diferentes. As editoras que avaliavam a plataforma viam a idade da interface antes de verem tudo o que ela conseguia fazer, e cada pedido de funcionalidade nova chegava a uma equipa sem uma linguagem visual partilhada e sem uma forma rápida de testar uma ideia antes de a construir.
O verdadeiro estrangulamento não era visual. Era a distância entre um design e uma funcionalidade publicada. Um ficheiro de Figma passava para um ticket, o ticket passava para um programador, e as dúvidas que surgiam durante o desenvolvimento voltavam para mim semanas depois. Com seis programadores e uma só designer, era esse ciclo que tinha de ser resolvido.
Restrições
Uma designer para tudo. Leitor, painel, checkout, login, emails, site, material de vendas. Tive de escolher onde o tempo de design contava mais e dar ao resto um sistema que a equipa conseguisse aplicar sem mim.
Um produto em produção com editoras que pagam. Nada podia falhar. Cada alteração no leitor ou no checkout chegava a leitores reais a comprar livros reais, por isso desenhei em passos pequenos e reversíveis.
Prazos definidos pelos clientes. As grandes editoras chegavam com listas de requisitos herdadas do fornecedor anterior e com datas que não se negociavam.
Acordo de confidencialidade. A maior parte do trabalho não pode ser mostrada em detalhe. Esta página mostra o leitor antes e depois, e descreve o resto.
Processo
Comecei pelas superfícies que editoras e leitores mais usavam: o leitor e depois o painel das editoras. Cada redesign começou com uma auditoria do fluxo atual, uma lista de pontos de fricção priorizada com o apoio ao cliente e as vendas, e uma passagem pelo sistema de design para que tudo o que eu desenhasse pudesse ser reutilizado.
A mudança que mais contou veio depois. Construí uma plataforma de protótipos sobre o stack da própria equipa: Laravel, Livewire, Flux UI e Tailwind, os mesmos componentes que os programadores usavam em produção. Em vez de mockups estáticos, cada ideia passava a ser um protótipo funcional com o seu próprio URL. Os programadores iam buscar o código, os product managers percorriam os fluxos, e as dúvidas que antes chegavam semanas depois ficavam respondidas no próprio protótipo.
A plataforma ganhou ferramentas próprias: links de partilha para revisões, comentários fixados em qualquer ecrã, exportação de comentários para CSV e um link de cada protótipo para o respetivo ticket no Linear. Entre janeiro e abril de 2026 publiquei 23 protótipos através dela, que cobrem checkout e pagamentos, o painel das editoras, faturação e reembolsos, o leitor, a loja e o onboarding. Quarenta e três commits referem issues do Linear das três equipas de produto, e é esse o rasto que mostraria a quem perguntasse como o design se ligava à entrega.
Solução
O leitor
O que faz. O leitor é onde os utilizadores passam o seu tempo: a ler, a ouvir, a ajustar a página, a passar de um capítulo para outro. Redesenhei-o de ponta a ponta: onboarding, vista de leitura, definições e as transições entre eles.
Decisão-chave
Manter a superfície de leitura quase vazia e levar todos os controlos para uma única camada de definições. O leitor antigo competia com o livro; o novo dá um passo atrás.
Antes
Depois
Sob pressão. Quando uma grande editora nova exigiu uma longa lista de alterações no leitor para igualar o que o fornecedor anterior oferecia, entregámos um leitor novo com todas as alterações em menos de uma semana. A plataforma de protótipos tornou isso possível: a equipa construiu a partir de ecrãs que funcionavam, não de um documento.
A plataforma de protótipos
O que faz. Uma aplicação interna em Laravel onde cada protótipo é uma página real, feita com a biblioteca de componentes de produção, com links de partilha, comentários fixados, exportação para CSV e um link para o respetivo ticket.
Decisão-chave
Construí-la sobre o stack da equipa em vez de usar uma ferramenta de design. Um protótipo em Figma é uma imagem de uma funcionalidade; um protótipo em Livewire é o seu primeiro rascunho. Os programadores podiam copiar a partir dele.
Contrapartida
Custou-me bastante tempo de desenvolvimento no início, e só funciona porque escrevo o mesmo código que a equipa escreve. Para quem desenha e não programa, uma ferramenta de design com um bom handoff é a melhor escolha.
Painel, faturação e subscrições
O que faz. O painel das editoras é o lado do negócio: catálogo, vendas, subscrições, reembolsos e análise. Redesenhei as vistas principais e as tabelas de subscrição, e prototipei os fluxos de faturação e reembolsos antes de serem construídos.
Decisão-chave
Primeiro as tabelas. As editoras vivem em tabelas, por isso a densidade, a ordenação e os estados dessas tabelas definem o tom de todo o painel.
Checkout e login
O que faz. O fluxo de compra e a porta de entrada para leitores e editoras. Redesenhei ambos, e prototipei os passos de pagamento para que os programadores pudessem testar os casos-limite antes de publicar.
Comunicação e superfícies de marca
O que faz. Emails transacionais, banners para as lojas das editoras e várias versões do site ao longo dos anos. Antes, como freelancer, desenhei o site de 2023, capas de livros para editoras e a apresentação que a empresa levou à Startup Chile em 2019.
Sistema de design
Fiz evoluir o sistema de design existente até uma biblioteca de componentes documentada, para que os mesmos botões, tabelas, formulários e estados vazios aparecessem no leitor, no painel e nos protótipos. A biblioteca vivia no código, em Flux UI e Tailwind, e foi isso que permitiu que os protótipos e o produto partilhassem peças.
Impacto
A entrega de funcionalidades passou de meses para menos de uma semana na maioria dos casos. É esse o número que me interessa, porque resultou de mudar a forma como o design chegava ao desenvolvimento, e não apenas de um redesign. O leitor reconstruído em menos de uma semana para um cliente novo e exigente manteve essa conta em andamento. A plataforma de protótipos produziu 23 protótipos publicados em três meses, cada um com o seu rasto até ao ticket.
O que faria de outra forma
Construir a plataforma de protótipos mais cedo. Construí-a no meu segundo ano. O primeiro teria sido mais rápido com ela.
Documentar o sistema à medida que avançava. A biblioteca de componentes foi documentada tarde, quando as peças já existiam no código. Escrevê-la enquanto a construía teria poupado dúvidas à equipa.
Equipa
Eu, única designer de produto. Seis programadores de mobile, full-stack e frontend, product managers, apoio ao cliente, vendas e o CTO.
