[EN] Role UI Designer / Product Track CXM / Timeline 2022 / Project Design System
[PT] Função UI Designer / Produto Track CXM / Duração 2022 / Projeto Design System
[EN] [Overview] This project focused on building a scalable design system that eliminates redundancy and accelerates design-to-dev handoff. The principles below reflect solutions adopted by industry leaders in design systems.
To comply with non-disclosure agreements, some sensitive details in this case study have been intentionally generalized or omitted.
To comply with non-disclosure agreements, some sensitive details in this case study have been intentionally generalized or omitted.
[PT] [Resumo] Este projeto priorizou a criação de um sistema de design escalável que elimina redundâncias e acelera o handoff entre design e desenvolvimento. Os princípios abaixo refletem soluções adotadas por empresas líderes em design systems.
Para cumprir com acordos de confidencialidade (NDAs), alguns dados sensíveis neste estudo de caso foram intencionalmente alterados ou omitidos.
Para cumprir com acordos de confidencialidade (NDAs), alguns dados sensíveis neste estudo de caso foram intencionalmente alterados ou omitidos.
[EN ]About
Track.Co's Design System - A performance-driven design system for Track CXM.
Track CXM is a customer experience management platform developed by Track.Co. It helps companies monitor, analyze, and improve customer interactions by collecting real-time feedback and turning it into actionable insights.
Track.Co's Design System - A performance-driven design system for Track CXM.
Track CXM is a customer experience management platform developed by Track.Co. It helps companies monitor, analyze, and improve customer interactions by collecting real-time feedback and turning it into actionable insights.
[PT ]Sobre
Design System da Track.Co - Um Design System orientado a performance para Track CXM.
Track CXM é uma plataforma de gestão da experiência do cliente desenvolvida pela Track.Co. Ela ajuda empresas a monitorar, analisar e aprimorar as interações com os clientes, coletando feedback em tempo real e transformando esses dados em insights acionáveis.
Design System da Track.Co - Um Design System orientado a performance para Track CXM.
Track CXM é uma plataforma de gestão da experiência do cliente desenvolvida pela Track.Co. Ela ajuda empresas a monitorar, analisar e aprimorar as interações com os clientes, coletando feedback em tempo real e transformando esses dados em insights acionáveis.
[EN] Challenge
As the team grew, it became essential to define a clear workflow for the UI team — standardizing Figma files, organizing how they should be handled, and documenting what was done and how it was done in each request or prototype.
To ensure more consistency across the team's work, we needed a complete mapping of Track.co's Design System, which includes around 36 components and several untracked instances.
At a more advanced stage, it was also necessary to define a standardized handoff process for delivering designs to the tech/front-end team.
As the team grew, it became essential to define a clear workflow for the UI team — standardizing Figma files, organizing how they should be handled, and documenting what was done and how it was done in each request or prototype.
To ensure more consistency across the team's work, we needed a complete mapping of Track.co's Design System, which includes around 36 components and several untracked instances.
At a more advanced stage, it was also necessary to define a standardized handoff process for delivering designs to the tech/front-end team.
❌ Confusing files that didn't match what was happening in Jira boards.
❌ Covers were rarely used and when used, didn't reflect the Project's reality.
❌ File pages dedicated to each request/prototype.
❌ Design System split across multiple files.
❌ Covers were rarely used and when used, didn't reflect the Project's reality.
❌ File pages dedicated to each request/prototype.
❌ Design System split across multiple files.
✅ Organized projects with cards in Jira.
✅ Standardized covers containing maximum relevant information about requests.
✅ Pages with versioning: Studies/Screens/Prototype/Handoff/History.
✅ Unification of Design System files and addition of new standards.
✅ Standardized covers containing maximum relevant information about requests.
✅ Pages with versioning: Studies/Screens/Prototype/Handoff/History.
✅ Unification of Design System files and addition of new standards.
[PT] O Desafio
Com o crescimento do time, foi necessário criar um workflow claro para a equipe de UI — padronizando os arquivos no Figma, organizando como deveriam ser tratados e documentando o que foi feito e como foi feito em cada protótipo ou demanda.
Para garantir mais consistência, realizamos o mapeamento completo do Design System da Track.co, que incluía cerca de 36 componentes e 189 instâncias não mapeadas.
Na fase avançada, também definimos o processo padrão de handoff das entregas para o time de desenvolvimento.
Com o crescimento do time, foi necessário criar um workflow claro para a equipe de UI — padronizando os arquivos no Figma, organizando como deveriam ser tratados e documentando o que foi feito e como foi feito em cada protótipo ou demanda.
Para garantir mais consistência, realizamos o mapeamento completo do Design System da Track.co, que incluía cerca de 36 componentes e 189 instâncias não mapeadas.
Na fase avançada, também definimos o processo padrão de handoff das entregas para o time de desenvolvimento.
❌ Arquivos confusos que não refletiam o que acontecia nos boards do Jira.
❌ Covers pouco utilizadas e quando utilizadas, não refletiam a realidade do Projeto.
❌ Páginas dos arquivos dedicadas a cada demanda/protótipo.
❌ Design System dividido em vários arquivos.
❌ Páginas dos arquivos dedicadas a cada demanda/protótipo.
❌ Design System dividido em vários arquivos.
✅ Projetos organizados e com cards no Jira.
✅ Covers padronizadas para conter o máximo de informações relativas à demandas.
✅ Páginas com versionamento: Estudos/Telas/Protótipo/Handoff/Histórico.
✅ Unificação dos arquivos de Design System e adição de novos padrões.
✅ Covers padronizadas para conter o máximo de informações relativas à demandas.
✅ Páginas com versionamento: Estudos/Telas/Protótipo/Handoff/Histórico.
✅ Unificação dos arquivos de Design System e adição de novos padrões.
[EN] UI Audit: Figma, Storybook, and Production
With file structure and standards in place, the next step was to identify as many UI inconsistencies as possible across the Figma–Storybook–Production triad.
Among several findings and mismatches, these were the key insights revealed during the audit:
- Standardization of files in Figma.
- Need for quality checklist, documentation standardization, and handoff.
- Out of 37 components: 4 Documented, 50% in Storybook and Production.
[PT] Análise de UI: Figma, Storybook e Produção
Com a estrutura de arquivos e os padrões já definidos, o próximo passo foi identificar o máximo possível de inconsistências de UI na tríade Figma–Storybook–Produção.
Entre diversos achados e divergências, estes foram os principais insights revelados durante a auditoria:
- Padronização de arquivos no Figma.
- Necessidade de checklist de qualidade, padronização de documentação e handoff.
With file structure and standards in place, the next step was to identify as many UI inconsistencies as possible across the Figma–Storybook–Production triad.
Among several findings and mismatches, these were the key insights revealed during the audit:
- Standardization of files in Figma.
- Need for quality checklist, documentation standardization, and handoff.
- Out of 37 components: 4 Documented, 50% in Storybook and Production.
[PT] Análise de UI: Figma, Storybook e Produção
Com a estrutura de arquivos e os padrões já definidos, o próximo passo foi identificar o máximo possível de inconsistências de UI na tríade Figma–Storybook–Produção.
Entre diversos achados e divergências, estes foram os principais insights revelados durante a auditoria:
- Padronização de arquivos no Figma.
- Necessidade de checklist de qualidade, padronização de documentação e handoff.
- De 37 componentes: 4 Documentados, 50% no Storybook e Produção.
[EN] Action Plan
To define which initiatives to prioritize, we created an Effort vs. Impact matrix that guided the entire process. This resulted in around 20 key actions, including:
- Reviewing, adjusting, and creating new design tokens.
- Defining templates for documentation and handoff.
- Establishing component Do’s and Don’ts.
- Setting success metrics for the design system.
- Strengthening alignment with the front-end team through definitions of “done,” workshops, and team-building sessions.
To define which initiatives to prioritize, we created an Effort vs. Impact matrix that guided the entire process. This resulted in around 20 key actions, including:
- Reviewing, adjusting, and creating new design tokens.
- Defining templates for documentation and handoff.
- Establishing component Do’s and Don’ts.
- Setting success metrics for the design system.
- Strengthening alignment with the front-end team through definitions of “done,” workshops, and team-building sessions.
[PT] Plano de Ação
Para definir quais iniciativas priorizar, criamos uma matriz Esforço vs. Impacto que guiou todo o processo. Isso resultou em cerca de 20 ações-chave, incluindo:
- Revisão, ajuste e criação de novos tokens de design.
- Definição de templates para documentação e handoff.
- Estabelecimento de boas práticas ("Do’s and Don’ts") para componentes.
- Definição de métricas de sucesso para o design system.
- Fortalecimento do alinhamento com a equipe de front-end por meio de definições de "pronto", workshops e sessões de integração.
Para definir quais iniciativas priorizar, criamos uma matriz Esforço vs. Impacto que guiou todo o processo. Isso resultou em cerca de 20 ações-chave, incluindo:
- Revisão, ajuste e criação de novos tokens de design.
- Definição de templates para documentação e handoff.
- Estabelecimento de boas práticas ("Do’s and Don’ts") para componentes.
- Definição de métricas de sucesso para o design system.
- Fortalecimento do alinhamento com a equipe de front-end por meio de definições de "pronto", workshops e sessões de integração.
[EN] Component Mapping
All components required a thorough review, so we defined three stages to consider a component as fully reviewed: Complete handoff, Fixes (if needed), and Documentation on Zeroheight.
To ensure visibility across the entire Product and Tech teams, we created a detailed spreadsheet showing the status of each component. From a total of 36 main components and 189 instances:
- 100% of components reviewed in Figma.
- 100% with complete handoff ready.
- 73% of components needed fixes, 96% with fixes completed.
- 70% in production.
- 50% in Storybook (Well-implemented handoff speeds up the tech team's process).
- 20% in Zeroheight (Initial process).
All components required a thorough review, so we defined three stages to consider a component as fully reviewed: Complete handoff, Fixes (if needed), and Documentation on Zeroheight.
To ensure visibility across the entire Product and Tech teams, we created a detailed spreadsheet showing the status of each component. From a total of 36 main components and 189 instances:
- 100% of components reviewed in Figma.
- 100% with complete handoff ready.
- 73% of components needed fixes, 96% with fixes completed.
- 70% in production.
- 50% in Storybook (Well-implemented handoff speeds up the tech team's process).
- 20% in Zeroheight (Initial process).
[PT] Mapeamento de Componentes
Todos os componentes passaram por uma revisão completa, então definimos três etapas para que um componente fosse considerado totalmente revisado: Handoff completo, correções (se necessário) e documentação no Zeroheight. Para garantir visibilidade para todo o time de Produto e Tecnologia, criamos uma planilha detalhada com o status de cada componente. De um total de 36 componentes principais e 189 instâncias:- 100% dos componentes revisados no Figma.
- 100% com handoff completo pronto.
- 73% de componentes que precisavam de fix, 96% com fix pronto.
- 70% em produção.
- 50% no Storybook (Handoff bem implementado agiliza o processo do time tech).
- 20% no Zeroheight (Processo inicial).
Todos os componentes passaram por uma revisão completa, então definimos três etapas para que um componente fosse considerado totalmente revisado: Handoff completo, correções (se necessário) e documentação no Zeroheight. Para garantir visibilidade para todo o time de Produto e Tecnologia, criamos uma planilha detalhada com o status de cada componente. De um total de 36 componentes principais e 189 instâncias:- 100% dos componentes revisados no Figma.
- 100% com handoff completo pronto.
- 73% de componentes que precisavam de fix, 96% com fix pronto.
- 70% em produção.
- 50% no Storybook (Handoff bem implementado agiliza o processo do time tech).
- 20% no Zeroheight (Processo inicial).
[EN] Token Review
During the Design System token review, we uncovered inconsistencies that could significantly affect the workflow — both in prototyping and in the handoff process.
To address these issues, we implemented several improvements:
- Created new spacing tokens to fill gaps in the layout grid.
- Introduced handoff-specific tokens that greatly reduced production time.
- Restructured typographic tokens, which were previously based on the 8px grid but lacked a clear hierarchy.
- Conducted a study to introduce missing colors that were needed for specific use cases.
- Researched and proposed a more accessible color palette.
During the Design System token review, we uncovered inconsistencies that could significantly affect the workflow — both in prototyping and in the handoff process.
To address these issues, we implemented several improvements:
- Created new spacing tokens to fill gaps in the layout grid.
- Introduced handoff-specific tokens that greatly reduced production time.
- Restructured typographic tokens, which were previously based on the 8px grid but lacked a clear hierarchy.
- Conducted a study to introduce missing colors that were needed for specific use cases.
- Researched and proposed a more accessible color palette.
[PT] Revisão de Tokens
Durante a revisão dos tokens do Design System, identificamos inconsistências que poderiam impactar significativamente o fluxo de trabalho — tanto na prototipagem quanto no processo de handoff.
Para resolver essas questões, implementamos diversas melhorias:
- Criamos novos tokens de espaçamento para preencher lacunas no grid de layout.
- Introduzimos tokens específicos para handoff, o que reduziu significativamente o tempo de produção.
- Reestruturamos os tokens tipográficos, que antes eram baseados no grid de 8px, mas não seguiam uma hierarquia clara.
- Realizamos um estudo para introduzir cores ausentes necessárias para casos de uso específicos.
- Pesquisamos e propusemos uma paleta de cores mais acessível.
Durante a revisão dos tokens do Design System, identificamos inconsistências que poderiam impactar significativamente o fluxo de trabalho — tanto na prototipagem quanto no processo de handoff.
Para resolver essas questões, implementamos diversas melhorias:
- Criamos novos tokens de espaçamento para preencher lacunas no grid de layout.
- Introduzimos tokens específicos para handoff, o que reduziu significativamente o tempo de produção.
- Reestruturamos os tokens tipográficos, que antes eram baseados no grid de 8px, mas não seguiam uma hierarquia clara.
- Realizamos um estudo para introduzir cores ausentes necessárias para casos de uso específicos.
- Pesquisamos e propusemos uma paleta de cores mais acessível.
[EN] Handoff
To ensure a more accurate and efficient handoff from the UI team to development, we held discussions with the front-end team to better understand how they interacted with Figma.
Key findings:
- The "Inspect" tab in Figma was rarely or never used.
- Interactive prototypes were time-consuming to navigate — understanding screen flow was more valuable to the devs.
Based on these insights and benchmarks from other handoff processes, we defined a handoff template that includes:
- Component anatomy.
- Spacing guidelines.
- Typography specifications.
To ensure a more accurate and efficient handoff from the UI team to development, we held discussions with the front-end team to better understand how they interacted with Figma.
Key findings:
- The "Inspect" tab in Figma was rarely or never used.
- Interactive prototypes were time-consuming to navigate — understanding screen flow was more valuable to the devs.
Based on these insights and benchmarks from other handoff processes, we defined a handoff template that includes:
- Component anatomy.
- Spacing guidelines.
- Typography specifications.
[PT] Handoff
Para garantir uma transição mais precisa e eficiente da equipe de UI para o desenvolvimento, realizamos discussões com o time de front-end para entender melhor como eles interagem com o Figma.
Principais descobertas:
- A aba "Inspect" do Figma era raramente ou nunca utilizada.
- Protótipos interativos demandavam muito tempo para navegação — o fluxo entre telas era mais valioso para os desenvolvedores.
Com base nessas informações e em benchmarks de outros processos de handoff, criamos um template que inclui:
- Anatomia dos componentes.
- Diretrizes de espaçamento.
- Especificações tipográficas.
Para garantir uma transição mais precisa e eficiente da equipe de UI para o desenvolvimento, realizamos discussões com o time de front-end para entender melhor como eles interagem com o Figma.
Principais descobertas:
- A aba "Inspect" do Figma era raramente ou nunca utilizada.
- Protótipos interativos demandavam muito tempo para navegação — o fluxo entre telas era mais valioso para os desenvolvedores.
Com base nessas informações e em benchmarks de outros processos de handoff, criamos um template que inclui:
- Anatomia dos componentes.
- Diretrizes de espaçamento.
- Especificações tipográficas.
[EN] Iterations
The iterations with the front-end team were highly constructive, progressively reinforcing the adoption of fully documented and handed-off components.
The iterations with the front-end team were highly constructive, progressively reinforcing the adoption of fully documented and handed-off components.
[PT] Iterações
As iterações com a equipe de front-end foram altamente produtivas, reforçando progressivamente a adoção de componentes totalmente documentados e com handoff concluído.
As iterações com a equipe de front-end foram altamente produtivas, reforçando progressivamente a adoção de componentes totalmente documentados e com handoff concluído.
[EN] Production Time
The improved handoff process significantly reduced production time across the pipeline:
- Design prototyping became faster, thanks to fully finalized components.
- Front-end development also accelerated — delivery times improved, and developers had fewer questions about the design decisions.
- PMs and POs who followed the process after the components were fully aligned reported a noticeable improvement in the delivery quality of both design and front-end teams.
The improved handoff process significantly reduced production time across the pipeline:
- Design prototyping became faster, thanks to fully finalized components.
- Front-end development also accelerated — delivery times improved, and developers had fewer questions about the design decisions.
- PMs and POs who followed the process after the components were fully aligned reported a noticeable improvement in the delivery quality of both design and front-end teams.
[PT] Tempo de Produção
O processo aprimorado de handoff reduziu significativamente o tempo de produção em todo o fluxo:
- Prototipagem de design tornou-se mais rápida, graças aos componentes totalmente finalizados.
- Desenvolvimento front-end também acelerou — os prazos de entrega melhoraram e os desenvolvedores tiveram menos dúvidas sobre as decisões de design.
- PMs e POs que acompanharam o processo após o alinhamento total dos componentes relataram uma melhoria perceptível na qualidade de entrega das equipes de design e front-end.
O processo aprimorado de handoff reduziu significativamente o tempo de produção em todo o fluxo:
- Prototipagem de design tornou-se mais rápida, graças aos componentes totalmente finalizados.
- Desenvolvimento front-end também acelerou — os prazos de entrega melhoraram e os desenvolvedores tiveram menos dúvidas sobre as decisões de design.
- PMs e POs que acompanharam o processo após o alinhamento total dos componentes relataram uma melhoria perceptível na qualidade de entrega das equipes de design e front-end.
