27 de maio de 2026 • ⏱️ 10 min de leitura

Rotina Flow — Quando o app que você criou virou o impedimento que você queria resolver

UXProduct DesignNext.jsAcessibilidade

Uma reflexão honesta sobre UX, friction e o momento em que você percebe que o bloco de notas do celular ainda ganha.

O problema que eu não queria admitir

Eu criei o Rotina Flow para resolver um problema meu: manter o foco nas tarefas do dia sem me perder em apps de produtividade complexos demais. Eu e minha parceira Nara somos os dois únicos usuários do sistema — ela para organizar sua rotina pessoal e de trabalho, eu para manter o dia em ordem.

Por um tempo funcionou. O visual era bonito, a lógica era simples no papel. Mas em algum momento comecei a notar algo incômodo: eu continuava abrindo o bloco de notas do celular para anotar coisas.

Por quê?

Porque criar uma tarefa no Rotina Flow tinha atrito. Não muito — mas o suficiente para o meu cérebro preferir a alternativa mais fácil. E a alternativa mais fácil era o app mais primitivo possível.

O fluxo que eu tinha em Produção

Para adicionar uma tarefa na versão antiga, o caminho era:

Abrir o app e ver o “ROTINA DIÁRIA”
Rolar para procurar onde adicionar a tarefa
Encontrar um botão tracejado [+] gigantesco no meio da tela
Clicar nele e ser interrompido por um modal “NOVO BLOCO DE ROTINA”
Enfrentar um formulário com Título, Horário, Frequência (Foco Profundo, Recarregar, etc) e Detalhes.
Digitar o texto da tarefa e clicar em “REGISTRAR NO BANCO”

Seis passos, uma tela sobreposta (modal), e um formulário inteiro apenas para anotar “Comprar pão”. Nenhum é impossível individualmente. Mas em conjunto criam o que os pesquisadores de UX chamam de friction — resistência cognitiva que, multiplicada pela frequência de uso, transforma uma ação simples numa grande barreira.

O bloco de notas tinha zero friction. Você abre, você digita, está feito. O próprio Steve Jobs dizia que a complexidade não existe no produto que você elimina — existe em tudo que você deixou. E nós tínhamos deixado um formulário de cadastro de banco de dados no meio da rotina diária.

A decisão de redesenhar

A mudança não começou num whiteboard. Começou numa pergunta:

“Quando foi a última vez que você abriu o Rotina Flow e adicionou uma tarefa sem hesitar?”

A resposta honesta foi: faz tempo.

Então decidi que a branch feat/config-system não seria apenas sobre adicionar temas e internacionalização — seria sobre simplificar o núcleo da experiência.

O que mudou (versão `feat/config-system`)

1. O QuickInput virou o centro da experiência

Eliminamos o formulário gigante e o botão tracejado central. Criamos o QuickInput colado na base da tela — sempre visível, sem modais. O que mudou foi a redução drástica de esforço e a clareza de intenção.

Antes (em produção): Um botão + que abria um modal escuro com 4 campos diferentes só para registrar a tarefa. Depois: Um campo no rodapé com um ponto visual que responde ao que você está fazendo — cinza quando vazio, roxo brilhante quando tem texto — e um único botão de confirmação com seta que aparece só quando há texto para enviar.

O Escape limpa o campo. O Enter confirma. Um estado de loading aparece enquanto salva. E você mantém o foco no input para digitar a próxima tarefa imediatamente sem recarregar e sem sair do lugar.

Bloco de notas:    abrir → digitar → pronto (2 steps)
Rotina Flow antes: abrir → clicar no botão enorme → ler o modal → preencher título → Registrar (5 steps pesados)
Rotina Flow agora: abrir → digitar → Enter (3 steps fluídos)

2. Três temas, três contextos de uso

A nova versão tem suporte a Dark, Light e OLED. Não é só estética.

Dark é o padrão — ambientes com pouca luz, uso noturno. O gradiente de fundo muda com o período do dia (laranja de manhã, roxo à noite). Sensação de profundidade sem pesar nos olhos.

Light é para ambientes externos ou iluminados. Um bug crítico da versão anterior: o modo light não existia, e forçar uma interface escura na luz do sol é ilegível. Aqui os cards têm sombras reais, o background tem um gradiente suave, e o acento muda para um violeta mais sólido (maior contraste sobre fundo claro).

OLED é para quem usa smartphone com tela AMOLED às 2h da manhã. Background 100% preto — pixels literalmente desligados — com acento verde neon discreto. Sem gradientes decorativos, sem ruído visual. Apenas as informações que importam.

3. Contraste que passa no WCAG AA

Um problema que eu não sabia que tinha: o text-muted na versão original usava rgba(255,255,255,0.25) — o que resulta em um ratio de contraste de ~3.5:1 sobre o background escuro. O mínimo para texto normal segundo WCAG 2.1 AA é 4.5:1.

O que isso significa na prática? Para mim, que tenho visão normal, funcionava bem. Para a Nara, que usa o app num celular com tela um pouco mais escura, o texto de horários e categorias ficava difícil de ler.

Corrigi para #94a3b8 no dark (ratio ~7.6:1) e #4b5563 no light (ratio ~7.2:1). Diferença invisível para quem não tem problema, significativa para quem tem.

4. Respeito ao `prefers-reduced-motion`

Adicionei @media (prefers-reduced-motion: reduce) em todo o CSS. Usuários que configuram essa preferência no sistema operacional — geralmente por sensibilidade a movimento ou epilepsia fotossensível — não precisam ser submetidos às animações de float, pulse e sparkle que o app usa.

Não é sobre sacrificar beleza. É sobre saber quando não impor ela.

5. Acessibilidade de teclado

Todos os botões interativos têm aria-label descritivo. Menus têm role="menu" e role="menuitem". O checkbox de tarefa tem aria-pressed. O progress ring tem role="progressbar" com aria-valuenow/min/max.

São detalhes invisíveis para usuários típicos e essenciais para quem usa leitor de tela.

As decisões de design que mais importaram

O modal forçava a estruturação prematura da informação. O usuário queria apenas esvaziar a mente (“Comprar pão”), mas o sistema o forçava a decidir: Qual a categoria de energia? Quanto tempo vai levar? Vai ter anotação?.

Isso criava paralisia. Transferimos toda essa complexidade para um menu secundário (o botão ”···” de cada tarefa), de forma opcional e assíncrona. O input rápido serve apenas para capturar o que precisa ser feito. Organize depois, se quiser.

Por que o botão de submit fica invisível quando vazio

A Apple tem um princípio de design que eles chamam de “progressive disclosure” — mostrar opções apenas quando são relevantes. Um botão de confirmação visível com o input vazio não tem função — só polui visualmente e cria uma chamada para ação que não pode ser completada.

Quando você começa a digitar, o botão aparece com uma animação suave. Quando você apaga tudo, ele desaparece. A interface responde ao seu estado de intenção.

Por que o ponto indicador muda de cor

Existe uma diferença entre um input que “está esperando” e um input que “está pronto”. O ponto cinza diz: “pode digitar.” O ponto roxo pulsante diz: “tenho algo — o que fazer?”

É a diferença entre um semáforo apagado e um semáforo verde.

O que aprendi com isso

1. Seus usuários mais próximos são os mais difíceis de ouvir. Quando você cria algo para alguém que você conhece bem, tende a assumir que eles pensam como você. A Nara achava que o app era bom “do jeito que estava” porque ela se adaptou ao friction. Só a análise honesta do comportamento revelou o problema.

2. O bloco de notas é o concorrente real de qualquer app de produtividade. Não é o Notion, não é o Todoist. É a fricção zero do app mais simples possível. Se o seu app perde para o bloco de notas em alguma função core, há algo errado.

3. Contraste não é opcional. Achei que estava sendo “minimalista” com texto muted claro. Na verdade estava tornando o app ilegível para parte dos usuários em determinadas condições de luz.

4. Acessibilidade é infraestrutura, não feature. ARIA roles, prefers-reduced-motion, focus-visible — ninguém pede essas coisas. Mas quando você precisa delas e o app não tem, o dano é real.

Próximos passos

A branch feat/config-system está prestes a ser mergeada na main. Junto com ela virão as melhorias visuais, o sistema de temas e a simplificação do fluxo de criação de tarefas.

Versão futura que estou considerando: adicionar a possibilidade de definir horário no próprio momento da criação da tarefa — não no menu pós-criação, mas integrado ao input de forma que não adicione passos desnecessários. Algo como @manha ou @19h no final do texto para definir automaticamente o horário.

Mas isso é para depois. Primeiro: mesclar o que funciona.

Stack técnica

Framework: Next.js 15 (App Router)
Banco de dados: PostgreSQL via Prisma
Estilização: Tailwind CSS v4 + CSS custom properties para o sistema de temas
Estado: Zustand com persist middleware
Internacionalização: Dicionários estáticos server-side + hook client-side
Deploy: Vercel (Hobby plan)

Como era antes vs Como é agora

A Fricção Antiga (Produção)
O atrito cognitivo que fazia a gente preferir o app de notas.

O Novo Fluxo “QuickInput”
Direto, in-place, sem sair da tela. Design invisível.

O Sistema de Temas Dinâmico
Não é apenas estético, é sobre contexto de uso e acessibilidade (modo light pra luz do dia, oled pra noite com pixels desligados).