Mosaic

A hipótese

Grande parte das experiências de link-in-bio organiza conteúdo em uma sequência de itens visualmente parecidos. Isso funciona bem para listar destinos, mas oferece pouco espaço para criar hierarquia entre trabalhos, imagens, textos, redes sociais ou outros tipos de conteúdo.

A hipótese do Mosaic é que o criador pode comunicar melhor o próprio trabalho quando cada conteúdo pode ter tamanho, posição e formato diferentes. Em vez de uma lista de links, uma composição pessoal.

Essa hipótese ainda não foi validada com usuários em escala. O primeiro objetivo foi torná-la navegável.

Meu papel

Meu trabalho no Mosaic ficou entre definição do produto, experiência e prototipação. O foco foi transformar a hipótese em uma interação funcional, decidir o que precisava entrar no MVP e, principalmente, o que ainda não precisava ser construído.

Também trabalhei diretamente na implementação do editor, da grade e dos principais comportamentos de interação.

Da lista para uma página modular

A diferença não está em ter mais features. Está em como o conteúdo é organizado e qual controle o criador tem sobre isso.

“Um único link, diferentes formas de mostrar o trabalho.”

Editar manipulando a própria página

O editor foi construído ao redor de manipulação direta. O criador não preenche formulários em um painel separado: ele adiciona um bloco, escolhe o tipo, edita o conteúdo e reposiciona na grade. A página muda em tempo real, enquanto a edição acontece.

O resultado é uma página com blocos organizados visualmente, sem nenhuma linha de código.

O Mosaic suporta seis categorias de conteúdo, cada uma com comportamento e visualização próprios:

Cada bloco aceita cinco tamanhos: Small, Medium, Large, Wide e Tall. O criador decide quanto espaço cada conteúdo merece na grade, e essa escolha é o que cria hierarquia visual. Uma imagem grande ao lado de dois links compactos comunica algo diferente de uma lista com tudo do mesmo tamanho.

Testar a experiência antes de construir a infraestrutura

O MVP não tem backend, autenticação, banco de dados ou sincronização entre dispositivos. Isso foi uma decisão de escopo, não uma limitação a resolver depois.

A pergunta central era: a interação faz sentido? A grade comunica algo? Editar blocos parece natural para o criador? Essas perguntas podiam ser respondidas sem servidor.

Essa escolha define o escopo do protótipo. Os dados permanecem no navegador e não sincronizam entre dispositivos. Esse custo foi aceito para manter o foco na experiência que queríamos testar.

Uma interface de manipulação direta

A interação não é ornamento. Ela é a proposta de valor do editor.

O criador enxerga a página enquanto edita, sem alternar entre uma interface de configuração e um preview separado. Os blocos podem ser arrastados para outra posição, redimensionados para dar mais ou menos destaque a um conteúdo, e editados diretamente no seu contexto visual. As mudanças são salvas no navegador sem nenhuma ação manual.

A implementação utiliza dnd-kit para dar mais controle sobre o comportamento de arraste e posicionamento dos blocos dentro da grade.

Consistência entre editor e página

Editor e resultado final precisam parecer partes do mesmo produto. Para isso, Mosaic usa um conjunto de tokens de cor semânticos e dois temas visuais, claro e escuro, controlados por CSS variables. Trocar de tema não reescreve componentes, substitui tokens.

Isso garante que o que o criador vê enquanto edita corresponde ao que a página vai exibir.

Arquitetura

Intencionalmente simples. O MVP não tem backend, então a arquitetura reflete isso.

A landing page e o editor evoluem de formas diferentes, então mantê-los como módulos separados reduz o acoplamento e facilita a evolução independente de cada parte.

Onde o MVP está hoje

O Mosaic hoje é um MVP funcional voltado à experiência do editor. Ele permite criar, editar, redimensionar e reorganizar uma página no navegador, mas ainda não possui contas, sincronização entre dispositivos, pagamentos ou infraestrutura de publicação.

Essas camadas ficaram fora do primeiro escopo porque não eram necessárias para tornar a hipótese de interação testável.

Também ainda não existem dados suficientes para afirmar adoção, retenção ou impacto com usuários reais.

O que quero validar a seguir

As perguntas que precisam de resposta antes de qualquer decisão sobre infraestrutura ou escala:

• Quanto tempo leva para um criador montar uma página do zero?
• Quantas pessoas completam o fluxo sem abandonar?
• Onde ocorrem os abandonos?
• Quais blocos são mais utilizados?
• Os cinco tamanhos ajudam a criar hierarquia ou adicionam complexidade desnecessária?
• Reorganizar os blocos parece intuitivo?
• Como a manipulação direta se comporta em telas menores?
• A pessoa consegue chegar a uma página que gostaria de compartilhar?
• Ela retorna para editar novamente?

O que este projeto demonstra