O DS que reduz o custo de entrada de novos clientes

Como o design parou de recomeçar do zero a cada cliente e passou a escalar junto com o negócio.

Cargo: Senior Product Designer na Accedo, referência técnica do design system
Cliente: Accedo (produto interno; clientes sob NDA)
Período: set/2024 – set/2025 · POC de 2 meses + 8 meses de construção · o sistema seguiu evoluindo depois da minha saída
Plataformas: Core, Web, iOS, Android, CTV · 8+ dispositivos
Time: 3 designers no Canadá, na Hungria e em Singapura (eu definia o escopo e revisava) · 1 dev na POC · engenharia do Elevate
Resultados: ↓56% das horas de design e dev no setup de cliente

Peças do Reels Design System num bento grid: barra de navegação da TV, destaque de uma série na TV, cards de canal, um conjunto de ícones e o app no celular

Sobre o cliente

A Accedo vende streaming de vídeo de duas formas: constrói o app do zero ou entrega o Elevate, seu produto white-label, que cada cliente customiza com a própria marca. Os dois caminhos atendem ao mesmo tipo de cliente, com necessidades quase idênticas.

Mas a cada cliente novo, mesmo nos de consultoria pura, o design recomeçava do zero. A engenharia tinha uma biblioteca vasta de componentes. O design não tinha nada centralizado.

O Reels Design System virou uma fonte de verdade entre design e código.

↓56%
das horas de design e dev no setup de cliente
Estimativa interna, com base na média histórica dos escopos de horas vendidos
4-5 dias
para criar uma feature nova, antes 2-3 semanas
Estimativa interna, mesma base
8+
dispositivos num só sistema
Accedo, dado interno

O desafio

A inconsistência entre web, mobile e TV virava refação constante, já na fase de ideação.

O sistema precisava fazer três coisas ao mesmo tempo: ser agnóstico à plataforma, compartilhável com o cliente e customizável direto no Figma. Tudo isso sem perder consistência entre dezenas de combinações de cliente e plataforma.

Liderei a solução como referência técnica: definia o escopo e revisava o trabalho de três designers no Canadá, na Hungria e em Singapura.

Os números que viraram o jogo

Nem todo mundo comprou a ideia. Design token, código, um jeito híbrido de trabalhar: parte do time via isso como risco.

Então passei dois meses com um desenvolvedor numa POC focada em CTV, nossa plataforma principal. Uma biblioteca, dois níveis de token: primitivo e semântico.

A engenharia do Elevate resistiu: tempo demais para construir. O que virou o jogo foram os números da própria POC, uma redução real de tempo e custo no setup de um cliente novo.

Diagrama da POC de CTV: uma biblioteca com tokens primitivos e semânticos alimentando uma tela de TV, e os cortes estimados no tempo de design e dev — A POC de CTV: uma biblioteca, dois níveis de token.

Um core, quatro bibliotecas de plataforma

A estrutura simples não aguentaria a escala real. Um token semântico reaproveitado demais amarrava tudo. Os arquivos ficavam pesados. E as regras de cada sistema operacional, numa biblioteca só, viravam um volume ingerenciável.

Então dividimos. Um terceiro nível de token, o de componente, permite ajustar uma peça sem quebrar o resto. E bibliotecas por escopo: uma Core, com os fundamentos de marca, e uma para Web, iOS, Android e CTV, cada uma com seus breakpoints e componentes.

Mais poder trouxe mais complexidade. O onboarding ficou mais difícil, e resolvemos com vídeos e documentação. Levamos 8 meses construindo e lançamos todas as plataformas juntas, porque nenhum cliente real usa só uma.

Diagrama da biblioteca Core, com tokens primitivos, semânticos e de componente, alimentando as bibliotecas de Web, iOS, Android e CTV — Fundamentos de marca na Core, regras de plataforma em cada biblioteca.

Variables do Figma direto no GitHub

Os tokens moram como variables no Figma e viram código no GitHub com o Style Dictionary, sem plugin no meio. A engenharia montou a conexão. Eu conferia o que era gerado e os IDs dos tokens.

Diagrama do fluxo dos tokens: variables no Figma, um workflow do GitHub Actions, as transformações do Style Dictionary e o código gerado em CSS, iOS e JS — Um token, do Figma ao código.

Revisando trabalho em três países

O time estava no Canadá, na Hungria e em Singapura, e cada região lia a interface de um jeito diferente. Essas diferenças viraram variações regionais de componente dentro do próprio sistema.

Foi a primeira vez que encarei escala e operação de design nesse nível. Liderar gente se mostrou mais difícil que liderar token.

Selfie do Petry com Nikki, Aitana, Dora e Victor, sorrindo ao ar livre, à beira da água — O time por trás do sistema, reunido pessoalmente.

A mesma base, duas marcas.

Onde chegou

↓56% das horas de design e dev no setup de um cliente novo (estimativa interna, com base na média histórica dos escopos de horas vendidos).
De 2-3 semanas para 4-5 dias para criar uma feature nova (estimativa interna, mesma base).
De reativa para proativa: a validação de componente acontece uma vez só, na origem, e não a cada entrega.
8+ dispositivos no mesmo sistema.
Os designers pararam de redesenhar telas e passaram a resolver o problema do cliente. Para mim, provavelmente o maior resultado.

Destaques

Liderei o design system como referência técnica, definindo o escopo e revisando o trabalho de três designers no Canadá, na Hungria e em Singapura.
Construí uma POC de CTV com um desenvolvedor e usei os números dela para convencer a engenharia do Elevate.
Defini a arquitetura de tokens em três níveis e a divisão em uma Core e quatro bibliotecas de plataforma.
Conferi a geração e os IDs dos tokens no fluxo do Figma para o GitHub.