fíor · irlandês · verdadeiro, real, puro
Um app mobile combinado com RYAKKA, um sensor IoT sob medida que lê seis parâmetros da água potável em casa e os condensa em quatro vereditos simples: Excellent, Good, Medium, Bad. Pensado para um contexto irlandês em que os relatórios oficiais são PDFs anuais e a conformidade é reportada em médias, mas a pessoa na torneira ainda não faz ideia do que saiu hoje.
Na Irlanda, um relatório anual de conformidade da EPA ainda supera o que a pessoa na torneira consegue confirmar hoje. As águas superficiais pioram: apenas 52% das águas superficiais estão em condição ecológica satisfatória, uma queda em relação aos 54% anteriores. O limite de chumbo cai pela metade em 2036 (10 → 5 µg/L), com o maior risco recaindo sobre bebês, crianças e gestantes (EPA, 2025). No papel, a conformidade geral soa tranquilizadora. A chaleira discorda.
Fior é um app companheiro do RYAKKA, um sensor doméstico que combina seis leituras com uma Verdict Ladder de quatro estados. A linguagem é calma, não alarmista; toda afirmação tem fonte, não é apenas alegada. O que você pode fazer a seguir, não o que você deveria temer.
MVP conceitual, não lançado. A pesquisa levou a uma mudança de persona, de foco rural para locatário urbano, visando o go-to-market. O resultado: um design system token-first (294 variáveis em três camadas, na v3.2), 15 telas hi-fi navegáveis, e um ecossistema de três superfícies coordenadas (case study, doc de processo, protótipo hi-fi) compartilhando um único design system.
Eu me mudei para a Irlanda em 2022. A primeira coisa que minha chaleira me ensinou foi como é o calcário: uma crosta branca na resistência depois de uma semana, não importava quantas vezes eu enxaguasse. A água da torneira era tecnicamente segura; a EPA garantia isso. Mesmo assim, eu não sabia realmente o que havia nela.
Essa lacuna, entre “a água é tecnicamente segura na média nacional” e “eu, hoje, na minha casa, consigo confirmar isso”, virou o brief. A categoria de consumo praticamente não existe na Irlanda: os dados da EPA ficam em relatórios institucionais, não no bolso das pessoas. O Fior fecha essa distância.
Fontes: EPA · Drinking Water Quality 2024 · EPA · Water Quality Report 2019–2024
Comecei aberto, de propósito. O prompt era “quais são os impactos da água não tratada na Irlanda?”, não “que aplicativo devemos construir?”. Mapear o raio de impacto primeiro evita que um projeto colapse numa única feature antes que o problema seja compreendido.
Cada categoria destravou um ângulo diferente para a próxima rodada de perguntas.
Primeira versão do problem statement: “Famílias rurais na Irlanda precisam de uma forma confiável e acessível de obter água limpa e segura, porque água não tratada pode causar problemas de saúde, ambientais e econômicos.”
Esse statement sobreviveu até que as personas foram esboçadas, e então ele mudou de rumo.
A persona primária mais nítida acabou sendo a Concerned Renter, o locatário preocupado (urbano, 25–40, Dublin / Cork / Galway). Donos de poços rurais têm risco objetivo mais alto, mas locatários têm risco engajável mais alto: eles não podem modificar o encanamento, suspeitam de canos de chumbo, já compram jarras filtrantes, e já vivem dentro da categoria de produto quantified-self.
Donos de poços rurais viraram a persona secundária; novos pais, a terciária. O problem statement se manteve. O alvo primário mudou de quem tinha mais risco para quem tinha mais chance de agir.
Oito prompts de How-Might-We, um por vetor de impacto. O objetivo aqui não era escolher um vencedor. Era trazer à tona os ângulos para que a rodada de ideação não começasse pré-comprometida.
As HMWs convergiram em quatro produtos plausíveis. Cada um foi avaliado segundo três filtros: valor pessoal diário, defensibilidade, e disciplina de escopo (um designer solo conseguiria prototipar isso de ponta a ponta?).
Valor pessoal todos os dias: você não checa um mapa todo dia, mas bebe água todo santo dia. Um moat de hardware através do RYAKKA, o sensor IoT companheiro que transforma seis parâmetros em um único veredito. E um escopo que um designer solo consegue de fato entregar de ponta a ponta: seis leituras, um veredito, um app. Recorte limpo.
Antes de qualquer pixel, um esboço ASCII de quatro telas. Home → Test → Result → Suggestions. Essa espinha dorsal ainda está visível no protótipo hi-fi de 15 telas: Home virou Dashboard, Test virou Measuring, Result virou a tela de veredito, Suggestions permaneceu como um hub.
┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ HOME │ │ TEST │ │ RESULT │ │ SUGGESTIONS │ │ │ │ │ │ │ │ │ │ Last test: │ → │ [ Dip RYAKKA] │ → │ GOOD · 76 │ → │ 1. Boil 3 min │ │ 08:42 · Good │ │ measuring… │ │ TDS · TOC │ │ 2. Filter jug │ │ │ │ ◉ ◉ ◉ │ │ COD · UV275 │ │ 3. Log source │ │ [Test again] │ │ │ │ EC · TEMP │ │ │ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘// esboço de 4 telas · ancestral direto do hi-fi de 15 telas ← Role horizontalmente para ver o fluxo completo →
Tudo que veio depois (um sistema de tokens em três camadas, cinco cores de pilar, o componente Verdict Ladder, a migração de Inter para Nunito) foi engrossando a espinha dorsal. A espinha dorsal em si nunca mudou de lugar.
O design system do Fior vive no Figma e no código: uma biblioteca no Figma construída com variables, components e auto layout, e as camadas de tokens implementadas em código. Três camadas de tokens, uma migração de tipografia no meio do projeto, e um único componente de quatro estados que carrega todo o ponto de vista do produto sobre saúde e honestidade.
// Biblioteca Figma · v3.2 · out 2026
Todo token do sistema pertence a uma de três camadas. Primitivos guardam valores brutos. Tokens semânticos mapeiam significado sobre esses valores (primary, surface, danger). Tokens de componente vinculam a camada semântica a uma parte específica da UI. Troque um primitivo, e as camadas acima se atualizam automaticamente.
No meio do projeto, o tom de marca quebrou a escolha tipográfica. Inter é nítida e neutra: certa para SaaS, errada para um utilitário irlandês calmo que quer soar como um amigo experiente. Os terminais arredondados da Nunito soam mais quentes sem abrir mão da legibilidade.
Com um sistema plano, essa migração teria sido um search-and-replace em cada estilo de texto. Com a arquitetura de três camadas, a mudança no código foi uma única troca de primitivo: --font-family-base passou a apontar de Inter para Nunito, e todo token semântico e de componente se propagou automaticamente.
Dez minutos de trabalho, zero regressões visuais. A arquitetura não era teórica. Ela pagou o custo de ser montada logo na primeira mudança estrutural.
O arquivo do Figma demorou mais a acompanhar: só saiu da Inter em outubro de 2026. Essa história é o capítulo 04.
Seis parâmetros do sensor (TDS, TOC, COD, UV275, EC, TEMP) são complicados. Um veredito não é. A Verdict Ladder é o único componente que transforma a leitura em uma manchete sobre a qual qualquer pessoa consegue agir em menos de dois segundos. Quatro estados. Linguagem simples. Nenhuma muralha de números.
O dashboard abre com o veredito, não com as leituras. COD, TDS, UV275 são evidência. Ficam um toque mais fundo, para quem quiser vê-las. A maioria não quer. Tom calmo em vez de tom assustador: os quatro estados nunca dizem “inseguro” ou “alerta”. Eles dizem o que você deve fazer a seguir (ferver, filtrar, beber).
As cinco cores de pilar e seus tons de apoio, a escala tipográfica da Nunito, e a grade de espaçamento base-4: as superfícies em que a arquitetura de três camadas desemboca.
O Fior vive em três superfícies ativas: o case study que você está lendo, um doc de processo mobile-first, e um protótipo hi-fi interativo. Elas compartilham a mesma paleta, a mesma Verdict Ladder, a mesma voz calma. Um design system. Três vozes.
A entrada narrativa: a história dentro da qual você está agora.
Um único documento mobile-first com quatro modos: Process, Wireframe, Prototype, System. Percorre a trilha de design desde o enquadramento do problema até o sistema embrionário.
Vite + React 18 + TypeScript strict. 15 telas em 6 fases e 3 ramificações. A Verdict Ladder de 4 estados vive aqui, de ponta a ponta. Hash routing, sem build SSR.
Por trás das três superfícies está o arquivo do Figma, onde o Fior começou: 27 telas em sete fluxos de feature. O protótipo hi-fi veio depois, como um caminho navegável de 15 telas. Em outubro de 2026 auditei o arquivo contra o código entregue e o reconstruí em três passos, da v3 à v3.2. Todo número deste capítulo é da v3.2.
A página System do doc de processo dizia com todas as letras: “O Figma é a fonte da verdade. Se este artefato divergir, o Figma vence.” A auditoria mostrou o contrário. Quem estava atrás era o Figma: ainda em Inter, ainda na escala tipográfica antiga. A contagem de variáveis batia com o sistema online até a unidade. Os valores, não.
Os achados que importavam eram os que nenhum screenshot mostra. A borda do input apontava para um token de espaçamento. O token de raio do botão estava ligado a retângulos que não eram botões. E o próprio componente Button tinha sido deletado enquanto telas ainda o usavam.
Antes de mudar qualquer valor, religuei cada camada a um token com o mesmo valor, para que nada na tela pudesse se mexer enquanto a estrutura por baixo mudava. Só então os valores mudaram. Nas 27 telas, zero regressões.
A frase saiu do site. A página System agora publica a regra que o trabalho de fato segue: o código entregue define os valores; o Figma o espelha, exceto onde o código reprova em acessibilidade.
A documentação também dizia zero hex hardcoded. Dentro das telas, isso ainda não era verdade. Eu podia ter suavizado a frase. Preferi corrigir o arquivo: as 67 cores soltas dentro das telas agora resolvem para variáveis, e os gradientes vivem como paint styles, porque a API de plugins do Figma não liga uma variável a uma parada de gradiente. O census marca zero nas 27 telas.
A estrutura também segue a API do código. O Button virou um set Type × State, porque no código disabled é estado, não tipo. A aba ativa da nav bar virou variante, espelhando activeTabForScreen(), e a entrada da aba Map corrigiu um erro de navegação no caminho.
Onde paridade e acessibilidade discordavam, a acessibilidade venceu, nos dois sentidos. O botão de sucesso da biblioteca de componentes reprovava AA com 2,2:1, então o código mudou para green-600 (5,6:1). O texto de erro do input no Figma reprovava AA com 3,9:1, então o Figma mudou para o red-600 do código (7,9:1).
A auditoria achou também o botão que todo mundo vê reprovando: branco sobre blue-400 dava 3,48:1. O primary passou para blue-500 (5,22:1), primeiro no código, depois no Figma.
Uma checagem automática confirma: axe-core 4.10, regras WCAG 2.1 A e AA, rodado no hi-fi no ar em 375 px e no desktop, reporta 0 violações nas 15 telas (out 2026). É uma checagem automática, não uma auditoria completa: nenhum leitor de tela entrou no teste.
A página Token Reference do Figma é a única ponte para o código para quem não tem assento pago. Ela listava nomes de CSS que não existem no código, como --color-primary e --spacing-1.
Não renomeei o Figma para parecer o código. Renomear produziria o pior tipo de drift: mesmo nome, outro valor. Em vez disso, cada variável aprendeu a palavra do código para ela, mas só onde os valores resolvidos batem. 262 de 294 batem. As outras 32 levam um traço e um motivo.
| Código (CSS do hi-fi) | Valor | Variável do Figma (Fior/Semantic) |
|---|---|---|
| --text-primary | #0D1E2E | color/text-primary |
| --text-muted | #6A849E | color/text-secondary |
| – | #8FA5BC | color/text-tertiary |
| --text-secondary | #354D62 | color/text-strong |
| --text-tertiary | #4E6680 | color/text-meta |
| – | #B8C8D8 | color/text-disabled |
| --text-on-deep | #FFFFFF | color/text-inverse |
Não há Code Connect: ele exige plano Organization ou Enterprise, e o arquivo está no Pro. Em vez disso, cada component set traz na descrição o arquivo-fonte e as props.
Uma revisão ainda me pegou. Bater o valor é necessário, não suficiente: um par passou no meu script e ainda estava errado, porque o peso compartilhado dos botões batia com o do botão primário e escondia duas variantes mais leves no código. A regra que ficou: o papel vence o valor mais próximo.
Antes de qualquer parte disso ir a público, cinco revisores independentes, agentes de IA separados com uma lente cada, leram o material contra o código, o arquivo do Figma e o site. Acharam erros que eu tinha escrito com confiança: um “AAA” que era AA, comparações entre contagens de escopos diferentes, e o site ainda dizendo “Figma wins”. Tudo corrigido antes de este capítulo ser escrito.
Todo número aqui é um census que eu consigo rodar de novo, e toda escrita em massa foi tudo-ou-nada: o script comparava cada par e não gravava nada se um único divergisse.
O brief não estava no laboratório. Estava na lixeira.
A água pública irlandesa tem 99,8% de conformidade, e as lixeiras de reciclagem de Dublin estão cheias de garrafas de água. Essa lacuna é o verdadeiro brief. As pessoas não estavam fugindo de água insegura; estavam fugindo da ausência de confirmação pessoal. A pesquisa mora menos no que as pessoas dizem estar errado, e mais no pequeno workaround que elas construíram silenciosamente ao redor disso.
A maioria dos apps de saúde abre com a leitura (TDS 128, pH 7,2) e deixa você traduzir isso sozinho. Isso é uma falha de voz disfarçada de transparência. A Verdict Ladder do Fior abre com o estado e guarda os números a um toque de distância. Calma não é um tom; é uma decisão de information architecture.
Tudo isso foi construído solo, 15 telas, 294 variáveis, 29 testes passando, WCAG 2.1 AA: eu mesmo desenhei no Figma e direcionei o sistema (personas, Information Architecture, a voz calma, a verdict ladder como a decisão central), enquanto a IA escrevia o código sob a minha direção.