Mosaic

The Hypothesis

Most link-in-bio experiences organize content as a sequence of visually similar items. That works well for listing destinations, but it leaves little room to create hierarchy between different types of work: projects, images, text, social profiles, or anything else a creator might want to surface.

The hypothesis behind Mosaic is that a personal page can do more when each piece of content can have its own size, position and format. Instead of a link list, a personal composition.

This hypothesis has not been validated at scale. The first goal was to make the experience navigable.

My Role

My work on Mosaic sat between product definition, experience design and prototyping. The focus was turning the hypothesis into a working interaction, deciding what needed to be in the MVP, and most importantly, what did not need to be built yet.

I also worked directly on the implementation of the editor, the grid and the core interaction behaviors.

From a Link List to a Modular Page

The difference is not about having more features. It is about how content is arranged and how much control the creator has over that arrangement.

“One link, different ways to present your work.”

Edit the Page by Manipulating It Directly

The editor is built around direct manipulation. Creators do not fill out forms in a separate panel: they add a block, choose the type, edit the content and reposition it in the grid. The page updates as the editing happens.

The result is a page with visually organized blocks, without a single line of code.

Mosaic supports six content categories, each with its own behavior and layout:

Each block accepts five sizes: Small, Medium, Large, Wide and Tall. The creator decides how much space each piece of content deserves in the grid, and that choice is what creates visual hierarchy. A large image next to two compact links communicates something different from a list where everything is the same size.

Test the Experience Before Building the Infrastructure

The MVP has no backend, no authentication, no database and no cross-device sync. That was a deliberate scoping decision, not a constraint to resolve later.

The central question was: does the interaction make sense? Does the grid communicate anything? Does editing blocks feel natural for the creator? Those questions could be answered without a server.

This choice defines the scope of the prototype. Data stays in the browser and does not sync across devices. That cost was accepted to keep the focus on the experience worth testing.

An Interface Built on Direct Manipulation

The interaction is not decorative. It is the product’s value proposition.

Creators see the page as they edit it, without switching between a configuration panel and a separate preview. Blocks can be dragged to a new position, resized to give more or less weight to a piece of content, and edited directly in their visual context. Changes are saved in the browser without any manual action.

The implementation uses dnd-kit for more precise control over drag behavior and block positioning within the grid.

Consistency Between Editor and Page

The editor and the final result need to feel like parts of the same product. Mosaic uses a set of semantic color tokens and two visual themes, light and dark, controlled by CSS variables. Switching themes does not rewrite components, it swaps tokens.

That ensures what the creator sees while editing matches what the page will actually display.

Architecture

Intentionally simple. The MVP has no backend, so the architecture reflects that.

The landing page and the editor evolve in different directions, so keeping them as separate modules reduces coupling and lets each part change independently.

Where the MVP Stands Today

Mosaic is a functional MVP focused on the editor experience. It lets creators build, edit, resize and reorder a page in the browser, but it does not yet have accounts, cross-device sync, payments or any publishing infrastructure.

Those layers were left out of the first scope because they were not needed to make the interaction hypothesis testable.

There is also not yet enough data to make claims about adoption, retention or real-user impact.

What I Want to Validate Next

The questions that need answers before any decision about infrastructure or scale:

• How long does it take a creator to build a page from scratch?
• How many people complete the flow without dropping off?
• Where do they drop off?
• Which blocks get used the most?
• Do the five sizes help create hierarchy, or do they add unnecessary complexity?
• Does reordering blocks feel intuitive?
• How does direct manipulation hold up on smaller screens?
• Can someone reach a page they would actually want to share?
• Do they come back to edit it again?

What This Project Demonstrates