Tu App: Sistema de Gestão de Rotina e Foco

• Role: Product Designer & Frontend Developer

• Tipo: Projeto independente

• Ferramentas: Figma, Variables, Excalidraw, HTML, CSS, JavaScript, Chrome Extension API

Resumo

O Tu App é um sistema de produtividade criado para reduzir a fragmentação entre planejamento e execução. O projeto nasceu da observação de que muitas pessoas utilizam diferentes ferramentas para organizar objetivos, tarefas, notas e agenda, aumentando o esforço necessário para manter a rotina organizada.

Em vez de começar pela interface, o projeto foi estruturado a partir da arquitetura do domínio utilizando OOUX, evoluindo para wireframes, Design System e implementação em código.

Objetivos do projeto

Desde o início, defini três objetivos que guiariam todas as decisões de produto:

• Reduzir a troca de contexto

• Facilitar a execução diária

• Construir uma arquitetura escalável

1. Product Discovery & Estratégia Humana

Principais descobertas

Depois de entrevistar 10 usuários e analisar aplicativos de produtividade, identifiquei um padrão recorrente: as pessoas utilizavam entre 3 e 5 ferramentas diferentes para organizar a rotina. Enquanto os objetivos estavam em um aplicativo, as tarefas em outro e os compromissos em um terceiro, o custo cognitivo para alternar entre esses ambientes comprometia a execução diária. O desafio passou a ser reduzir a fragmentação sem criar mais uma ferramenta complexa para administrar.

Insight principal

“Às vezes sinto que preciso ser um engenheiro de sistemas para configurar ferramentas de produtividade.”

R., 31 anos, profissional entrevistado.

Padrões Identificados:

• Usuários alternam constantemente entre agenda, tarefas e notas

• Excesso de funcionalidades gera ansiedade

• Dashboards tradicionais escondem o que realmente importa hoje

• A IA não era percebida como um diferencial pelos entrevistados

Trade-off: IA ou Controle do Usuário? Durante a pesquisa, considerei utilizar IA para organizar tarefas automaticamente. Prós: Menos trabalho manual e sugestões automáticas. Contras: Menor previsibilidade e perda da sensação de agência ou controle. Decisão: Optei por uma abordagem manual e intencional, pois os usuários valorizavam a previsibilidade e o controle consciente da rotina muito mais do que a automação.

2. Personas

Através de metodologias como Desk Research, análise de comentários em comunidades (como Reddit) e App Stores, além das entrevistas, mapeei 3 personas para o Tu (o profissional focado em performance, o estudante com rotina mista e o criador autônomo). Elas serviram como referência para validar decisões de priorização ao longo do projeto.

3. Modelagem Lógica (OOUX)

Como tarefas, projetos, objetivos e notas compartilham relações entre si, definir a estrutura antes da interface reduziu inconsistências durante o design. Usei a metodologia OOUX para estruturar o domínio do produto antes do design visual. Essa modelagem permitiu reutilizar objetos em diferentes telas e facilitou a implementação da extensão do Chrome posteriormente.

Decisão de Arquitetura: Objetivos deveriam conter tarefas diretamente? Minha primeira ideia foi permitir que objetivos agrupassem tarefas de forma direta. Durante a modelagem, percebi que isso dificultava a reutilização de tarefas em diferentes iniciativas. Optei por adicionar um nível intermediário: Projetos.

Estrutura Final resultante: Contexto > Objetivo > Projeto > Tarefa.

4. Wireframes de Média Fidelidade (Arquitetura de Fluxo)

Os primeiros wireframes buscavam equilibrar a quantidade de informação e o foco. Durante essa fase, percebi que dashboards muito completos dificultavam identificar rapidamente a próxima ação. Por isso, a interface evoluiu para uma estrutura estritamente centrada no dia atual.

Trade-off: Dashboard completo ou foco no dia? Inicialmente, considerei apresentar objetivos, projetos, agenda e estatísticas logo na tela inicial. Durante as iterações, notei que isso transformava o dashboard em uma tela de consulta passiva, não de execução ativa. A versão final priorizou apenas aquilo que influencia o dia atual.

5. Design System & Engenharia de Tokens

O Design System foi desenvolvido para mitigar o atrito entre design e implementação, permitindo a reutilização de componentes em múltiplos contextos.

• Global Tokens: Definição primitiva das escalas de cor e tipografia.

• Semantic Tokens: Camada semântica de mapeamento de estilo.

• Typography e Componentes: Organização estruturada de famílias de fontes, badges e estados (hover/active).

Trade-off: Tokens estáticos ou semânticos? Poderia utilizar diretamente as escalas de cor puras, contudo optei por criar uma camada de tokens semânticos (Exemplo: gray500 mapeado para text-primary). Isso elimina o impacto técnico de futuras mudanças de marca ou implementação de temas (como Dark Mode).

1. Interface Final (High-Fidelity UI)

O resultado é uma experiência de ponta a ponta, unindo consistência estética e portabilidade técnica:

• Interface Final (High-Fidelity UI) Antes de fechar a versão final, explorei diferentes abordagens para hierarquia visual, distribuição de informações e organização de cards. Cada iteração ajudou a reduzir distrações.

• A UI final utiliza tons pastéis e creme projetados estrategicamente para reduzir a fadiga visual do usuário durante longos dias de trabalho.

• A estrutura entrega uma organização avançada e escaneável de dados, permitindo alternar rapidamente entre contextos específicos sem perder o progresso de vista.

2. Validando o Design System em código

Para validar se a arquitetura realmente era escalável, implementei uma extensão nativa para o Google Chrome utilizando exatamente os mesmos tokens, componentes e padrões definidos no Figma.

• Integração Nativa: A extensão conecta-se em tempo real com o Google Agenda do usuário através de autenticação por login na própria ferramenta, unificando seus compromissos diretamente no fluxo de navegação.

• Restrição de Espaço: A extensão provou a consistência e a resiliência do Design System mesmo sob uma restrição severa de viewport.

• A arquitetura definida no início do projeto demonstrou flexibilidade suficiente para ser reutilizada de forma idêntica em outro ambiente de software.

Aprendizados e Próximos Passos

Esse projeto mostrou que decisões estruturais tomadas antes do design visual reduzem drasticamente o retrabalho durante a implementação. Também reforçou a importância de tratar o Design System como uma ferramenta viva de arquitetura de produto, e não apenas como uma biblioteca de componentes isolados.

No futuro, pretendo evoluir o produto adicionando:

• Sincronização em nuvem entre múltiplos dispositivos.

• Camada de colaboração.

• Métricas e relatórios de produtividade intencional.