Artigo · Julho de 2026
Como eu apliquei a lógica de um design system pra nunca mais travar na hora de decidir o que estudar
Um sistema de tags no Notion, com scores que se propagam como tokens, ordena por mim o que ler, assistir ou ouvir primeiro, a partir do voto que eu dou em tags.
Faz parte da minha profissão remover fricção da experiência das pessoas. Simplificar decisões, organizar informação, deixar claro o que vem primeiro.
De um lado, isso é o meu trabalho. De outro, meus próprios conteúdos de estudo. Normalmente guardados nos favoritos do navegador, sem o mesmo cuidado: centenas de artigos, vídeos e podcasts salvos sem nome, sem categoria, sem prioridade nenhuma. Até que eu percebi que eu melhoro a experiência de consumo para as pessoas e não para mim mesmo.
TL;DR
- Eu tinha artigos, vídeos e podcasts salvos para estudar, e não sabia priorizar qual tema estudar primeiro. Não cheguei na solução de primeira: foram duas tentativas erradas até a versão que funciona.
- Eu tenho uma tabela no Notion por tipo de conteúdo (artigos, vídeos, podcasts, livros, etc), porque as propriedades de cada tipo são diferentes. Eu tenho também uma tabela separada de tags, que são basicamente temas. As pages dessa tabela se conectam às pages de conteúdo.
- A solução: cada tag carrega em si um score. Mudar o score de uma tag propaga para todo lugar em que a tag está aplicada. Assim, não preciso mais mexer em cada página de conteúdo, uma por uma.
- As tags viram uma taxonomia de três níveis hierárquicos: Macro, Meso e Micro, cada um herdando score do nível acima.
- A mesma lógica de design tokens, aplicada à própria aprendizagem. Mude um valor em um lugar. Veja a mudança propagar por tudo. O sistema decide qual conteúdo vem primeiro.
- Eu não decido o que estudar. Eu calibro os temas mais importantes pra mim e o sistema prioriza o conteúdo mais relevante.
A paralisia do conteúdo infinito
Um artigo com benchmark de telas de onboarding, um vídeo de um processo de design, um site de uma ferramenta nova, um post com referências visuais. O tipo de coisa que aparece no dia a dia. Pra estudar depois, guardar como referência, puxar inspiração num projeto futuro, ou mandar pra alguém do time.
Os favoritos do browser parecem a escolha mais óbvia de onde guardar tudo isso. Eu usava assim: tudo no mesmo lugar, sem nome, sem categoria, sem ordem.
E com o tempo, a bagunça ia crescendo… E com ela, um problema que a desorganização escondia: como saber o que já tinha consumido? Se eu assistia um vídeo, deletava o favorito? Se eu ouvia um podcast, movia de pasta? Não havia status para nada disso.
E tinha mais. Na hora de escolher um desses artigos, vídeos ou podcasts, eu travava. Eram centenas de links. Qual era o mais importante agora? Para a etapa da carreira em que eu estava? Não havia como saber.
Não era só falta de tempo, nem só desorganização. Era volume demais, somado a uma dificuldade real minha de saber, no meio de tudo aquilo, o que importava mais naquele momento.
Acabava abrindo o último salvo. Que não era necessariamente o mais relevante.
Tentei, errei, tentei de novo
Na época, eu já era o cara do Notion do meu grupo de amigos. Não foi uma decisão difícil: levei tudo pra lá. Comecei com uma tabela só, pra artigos. Fui criando as outras conforme a necessidade foi aparecendo: vídeos, podcasts, livros, sites, posts, etc. Pela primeira vez, havia estrutura. Uma base organizável, com possibilidades quase infinitas: algumas eu já sabia que viriam, outras só fui descobrir com o tempo. Ao todo, foram quatro fases até a versão que uso hoje.
A primeira versão usava duas propriedades do Notion (os campos que você adiciona a cada item de uma tabela): Multi-select e Function. O Multi-select era a escala de voto: “Muito baixo”, “Baixo”, “Ok”, “Alto”, “Muito alto”, uma opção marcada em cada page de conteúdo. Já a Function lia qual opção eu tinha marcado e decidia a nota. O cálculo era manual, escrito à mão: se a opção fosse “Alto”, a nota era quatro. Se fosse outra, era outra. Um IF pra cada nível possível. Eram só cinco níveis, poucos mesmo assim. Mas já era chato de manter: qualquer ajuste na escala significava reescrever o bloco de IFs à mão.
Mas eu gostava desse tipo de problema: pouco recurso, regra clara, uma lógica que dava conta.
Então veio a segunda fase. Utilizei as chamadas Master Tags: uma tabela em que cada page seria referente a um tema/categoria. Essas pages funcionam como tags que eram conectadas via propriedade de Relation nas tabelas de conteúdo: a propriedade que permite selecionar páginas de outra tabela, direto na página que você está editando. Nas tabelas de conteúdo, essa propriedade se chamava Category.
A partir daí, com Relation, foi o começo do meu maior uso dentro do Notion, simples e incrível. Usei pra duas coisas:
- Juntar conteúdo (artigos, vídeos, podcasts) por tema, independente da tabela, tipo toda menção a Product Design reunida numa mesma Master Tag. Bastava abrir a page da tag pra ver tudo que já tinha sido conectado a ela.
- Um sistema de Voting direto nas páginas de conteúdo. Para cada page de conteúdo, dois critérios de Voting. Engagement: o quanto eu queria genuinamente consumir aquilo. Gain for me: o quanto aquele conteúdo contribuía pra minha evolução. Cada um com voto no range de 1 a 5: “Muito baixo”, “Baixo”, “Ok”, “Alto”, “Muito alto”. A partir do voto dos dois, uma propriedade de Function gerava a média, e o resultado virava a nota daquele conteúdo pra mim. A manutenção da nota de cada nível do range ficava centralizada num lugar só, diferente do IF espalhado da fase 1: dava pra ajustar o número de um nível sempre que precisasse, e isso já aconteceu.
A tabela de Artigos com Score, Engagement, Gain for me e Category. As três últimas colunas vêm de outra tabela, ligadas pela propriedade Relation do Notion.
De começo, fiquei animado com esse sistema: finalmente havia padrão e sincronia entre as tabelas. Por um tempo, pareceu suficiente. Com isso, eu tinha um problema a menos: a dúvida da escolha. Qual item pegar pra consumir, qual era o mais importante? O score, feito pela média dos dois votos, virava um número. Eu abria a tabela, ordenava por maior score entre os conteúdos, e pegava o primeiro item da lista.
Isso durou bem por um tempo. Mas comecei a ver alguns problemas. Os votos tinham sido dados no momento do salvamento. Refletiam quem eu era naquele dia, não quem eu era agora. A carreira não para de evoluir, e os itens no topo da lista sobre assuntos que eu já tinha superado começaram a aparecer. O sistema não sabia disso. Ele só sabia o que eu tinha votado, porque os votos estavam presos em cada page de conteúdo, individualmente.
Votar de novo item por item deixou de ser viável. Eram centenas de linhas. Reabrir cada uma pra atualizar um número não é muito diferente de voltar pros favoritos do browser sem nome nenhum.
A lista parecia organizada. Mas era uma foto antiga. A ordem não era mais confiável.
O sistema precisava ir para outra direção.
A virada, tags como tokens
A fase 3 foi trazer pra dentro da própria Master Tag aquele mesmo sistema de Voting, Engagement e Gain for me, esse que era feito dentro de cada página de conteúdo. Assim, o Voting e o score passavam a ser centralizados no tema, não mais no conteúdo final. Na prática: eu aplicava a Master Tag em cada conteúdo, e a página recebia a nota da tag.
Cada conteúdo continuava conectado a ela via Relation. Só que agora, em vez de cada página de conteúdo receber o próprio voto um de cada vez, passava a puxar o score direto da tag via propriedade de Roll-up: uma propriedade do Notion que permite ler e calcular um valor de uma página relacionada. Se a Master Tag “Research process” tivesse nota 5, por exemplo, um artigo sobre como conduzir entrevistas de persona conectado a ela também mostrava nota 5, sem eu precisar digitar nada. Se a nota da tag mudasse, a nota do artigo mudava junto.
Mas isso é um exemplo com uma tag só. Com duas ou mais é que a mágica acontece: o score do conteúdo passava a ser a média das notas entre todas as tags aplicadas a ele, gerando um número com até 5 casas decimais, que ajudavam a desempatar entre conteúdos.
Mudar o valor de uma tag propaga pra todo conteúdo relacionado a ela. Sem abrir uma linha sequer das tabelas de conteúdo.
Para quem tem contato com Design Systems, deve ter pensado na hora sobre Design Tokens. É a mesma lógica de um token de cor ou espaçamento. Muda o valor na fonte, todo componente que referencia aquele token muda junto. Eu só apliquei a mesma ideia na minha própria vida.
A page de Categoria concentra o Voting, Engagement e Gain for me, e se conecta a várias tabelas de conteúdo diferentes. Mudar o voto ali propaga pra tudo que está ligado a ela.
Mas ainda era pouco, precisava de mais
Do jeito que fiz, era direto: dava voto nas tags, e elas alteravam os scores dos conteúdos. Simples e direto. Mas comecei a perceber que tanta tag em um lugar só, com pesos iguais, ficava sobrecarregado, confuso, meio perdido: era carga cognitiva real, ter que dar nota pra “Product Design” e pra “Personas” no mesmo nível, como se fossem temas equivalentes, sendo que um está dentro do outro. Além disso, sentia falta de uma manutenção mais global: um jeito de melhorar de uma vez as notas de vários temas parecidos, sem precisar mexer em cada um individualmente.
A fase 4 veio da ideia de usar as próprias Master Tags nelas mesmas: criar níveis de tags, uma como guarda-chuva da outra. A premissa continuava a mesma, tabelas separadas, sistema de Master Tag e Voting, só que agora com o score se implementando de um nível pro outro. Faltava só descobrir quantas camadas eu precisava.
Testei duas camadas de tags. Um nível muito geral e um muito técnico, sem um nível intermediário de conexão entre os dois. No fim, ainda sobrava carga no nível de cima, sem uma camada de altíssima abstração que exigisse manutenção quase zero.
Três camadas se provou o ponto de equilíbrio: Macro, Meso e Micro. Um nível para manutenção quase zero. Um intermediário, fazendo ponte entre o geral e o específico. Um específico e técnico.
Macro Tags são os grandes âmbitos da minha carreira e vida: Product Design, Design Gráfico, Arte, Entretenimento, Career. Hoje giram em torno de 12 tags. Poucas, e quase paradas. Mexer numa Macro é uma decisão grande. Os critérios de Voting aqui são Gain for me e Engagement, cada um de 1 a 5.
Meso Tags fazem a ponte entre as Macro e Micro, tipo “Research process”, dentro da Macro “Product Design”. Hoje giram em torno de 77 tags. Uma Meso pode estar dentro de mais de uma Macro, herdando a média delas. O Voting é igual ao da Macro. Mas o score final vai além: pega a média das Macro Tags aplicadas àquela Meso, e faz a média dela com o voto da própria Meso.
Micro Tags são o nível mais específico: Personas, A/B Testing, Empathy Map, Storyboard. Hoje giram em torno de 552 tags. Aqui o Voting muda: no lugar de Gain for me, entra Skill Level, o quanto eu já domino aquele assunto. Quanto menor o meu domínio naquele assunto, maior a necessidade de aprender. O Engagement continua. E o mesmo vale aqui: o score final pega a média das Meso Tags aplicadas àquela Micro, e faz a média dela com o voto da própria Micro.
Quanto menos eu domino um assunto, mais alto o número que eu voto em Skill Level, e maior a prioridade que a Micro Tag ganha no score final.
Isso podia virar um problema: sempre no topo o que eu domino menos, nunca aprofundar o que já sei bem.
A Meso Tag freia isso. Ela vota em Gain for me, não em Skill Level: um tema de alto valor estratégico continua pesando, mesmo com Micro Tags fracas lá dentro.
E o próprio Engagement, votado junto ao Skill Level, tende a ser mais alto nos assuntos que eu já domino bem. Interesse genuíno segura a balança.
Um artigo sobre como construir personas eficazes recebe a tag “Personas”, e herda o score de todas as camadas acima.
Com isso tudo, cada conteúdo recebe uma ou mais Micro Tags. O score desse conteúdo vira a média das Micro Tags aplicadas. Mexer numa Macro muda toda Meso ligada a ela, que muda toda Micro ligada, que muda todo conteúdo com aquela Micro. Uma alteração, uma cascata inteira.
A propriedade nas tabelas de conteúdo também mudou de nome. Não é mais Category: agora é Micro Tags, porque é a Micro Tag, e só ela, que é aplicada direto em cada conteúdo.
Duas decisões pequenas sustentam isso:
- Usar média, não soma, pra cada tag pesar igual no resultado final.
- Essa mesma lógica de casas decimais que evita empate, agora formalizada como regra do sistema: calcular sempre com 5 casas, porque arredondar geraria dezenas de itens empatados, e empate é ordem arbitrária.
A precisão garante que a lista quase nunca trava numa dúvida de quem vem primeiro.
Sei que parece exagero, 5 casas depois da vírgula. Mas prefiro errar pelo excesso do que pela falta: desempate arbitrário é pior do que precisão demais.
A cascata de score: a Macro Tag Product Design herda pra Meso Tag Research process, que herda pras Micro Tags como Personas e A/B Testing, até chegar num conteúdo real de cada tabela.
Nada disso se sustenta sem manutenção. E manutenção manual, com 552 Micro Tags, seria inviável: as tags ficam dentro de uma tabela, dentro do Notion, dentro do site. Fácil de esquecer que estão lá, e mais fácil ainda de nunca dar manutenção.
A solução foi realizar o Voting de cada tag dentro de um hábito que já existia. Toda vez que abro o Instagram, um iOS Shortcut dispara antes, apresentando uma tag pra votar.
Ligar o Voting ao Instagram funciona justamente porque eu abro esse app todo dia, sem precisar de intenção nenhuma pra isso.
É esse voto contínuo que mantém o sistema vivo. Sem ele, os scores parariam no tempo, e a lista voltaria a ser a mesma foto antiga da fase anterior.
O Shortcut de Voting dispara ao abrir o Instagram, pedindo um voto de Macro, Meso ou Micro Tag, cada uma com sua própria escala.
Mas nem toda Micro Tag recebe voto na mesma frequência. Algumas aparecem toda semana no Shortcut, outras passam meses sem ser sorteadas.
Por isso, cada Micro guarda a data do último voto. Se passar de 80 dias sem voto novo, o score dela para de considerar o próprio voto: passa a herdar só a média das Meso Tags aplicadas ali.
Um voto de 80 dias atrás não representa quem eu sou hoje. Vontade e domínio mudam rápido demais pra confiar num número parado no tempo.
A Meso, não. Ela carrega o interesse num nível mais amplo da minha vida, mais estável do que a vontade passageira de uma Micro específica. Por isso é a média mais segura pra herdar quando o voto local expira.
Eu não inventei esse sistema
Eu não inventei esse sistema. Eu só apliquei em mim o que já aplicava no trabalho sobre Design Tokens, o que via em vídeos do youtube sobre notion, e claro, com muitos testes e erros no caminho.
A matriz de Voting veio direto de uma matriz que uso o tempo todo em discovery de produto: Esforço × Impacto, ou Ganho × Dificuldade, dependendo de quem você pergunta. A lógica é simples: número maior sempre significa algo bom, e número menor, algo ruim.
A mesma lógica que uso pra decidir o que um time constrói a seguir, decide o que eu estudo a seguir.
E a propagação de score não é só uma analogia bonita com design systems. É a mesma arquitetura. Um valor muda numa fonte, tudo que depende dele atualiza sozinho. Frameworks de priorização existem justamente pra isso: tirar da nossa cabeça uma decisão que o volume tornou impossível de fazer no improviso.
A diferença é que, dessa vez, o que está em jogo sou eu.
Sei como isso soa de fora: over-engineering pra decidir o que ler. E é, mesmo.
Troquei uma fricção grande por uma que eu escolho carregar. Não era só escolher entre conteúdos parecidos. Era não saber o que era prioridade de verdade, quando tudo parece prioridade: difícil escolher entre dois artigos do mesmo tema, mais difícil ainda dizer qual tema pesa mais.
A fricção nova é pensar sistema, montar lógica, testar hipótese.
É o mesmo padrão desde a fase 1: pouco recurso, regra clara, uma lógica que dá conta.
Não é sacrifício. Eu gosto de montar sistema: lógica de backend, uma peça puxando a outra, um efeito dominó que corre sozinho depois que eu solto a primeira peça.
O sistema decide por mim
Hoje eu não fico pensando no que estudar. O sistema decide por mim. E eu confio nessa decisão.
Na prática, isso vira dois caminhos. Abrir a tabela no Notion e pegar o primeiro item. Ou acionar um Shortcut, que já consulta a tabela pela API e entrega o primeiro item direto, sem precisar abrir o app.
Cada tipo de conteúdo tem seu próprio Shortcut. Um pra vídeo, outro pra artigo, outro pra podcast, etc.
Quando dois itens empatam mesmo com 5 casas decimais, outro critério desempata. Em vídeo, por exemplo, duração. Quanto mais curto, melhor: termina mais rápido, sai da lista mais rápido.
As tabelas de conteúdo, Articles, Audio-visual, Podcasts e Books, já ordenadas por Score. O primeiro item de cada uma é o próximo a consumir.
Existe até um Shortcut chamado “choose for me”, que escolhe o tipo de conteúdo com base no contexto. Em casa com Wi-Fi não é a mesma coisa que na rua com fone conectado. Isso é assunto pra um artigo inteiro à parte.
O resultado não é técnico. É comportamental. Parei de confiar na intuição do momento e passei a confiar num sistema calibrado com intenção.
O que isso libera é energia. A energia que ia pra decidir o que estudar, agora vai pro estudo em si.
E o princípio não depende do Notion. Separar onde o valor vive de onde ele é consumido funciona em qualquer sistema com hierarquia e propagação.
Esse sistema também não termina aqui. Usando ele no dia a dia, fui pensando em mais peças: um sistema que guarda conteúdo novo (vídeo, podcast, artigo) via Shortcut e script, cada um na sua tabela com os metadados certos. Outro que aplica as tags sozinho, em cascata: Micro Tag na página de conteúdo, Meso Tag na Micro, Macro Tag na Meso. E o próprio Shortcut de Voting no Instagram, que merece mais detalhe do que cabe aqui.
Cada uma dessas é assunto pra outro artigo.