All posts

April 20, 2026

You Don't Have to Describe What You Want — You Can Show It

A screenshot of a competitor, a photo that captures a mood, a rough sketch on paper. Visual references communicate design intent better than text. Mowgli lets you bring them in at any stage — before you start, during identity selection, or after your app is generated.

Design intent is easier to show than describe. When someone knows what they want, they usually don't open a text prompt and type "minimal, warm, slightly editorial, good whitespace, not corporate but not playful either." They pull up a screenshot. They paste an image. They point at something and say: like this, but ours.

Every AI design tool that starts from a text prompt asks you to do the harder thing — translate a visual impression into words, then hope the AI reconstructs the impression accurately from those words. The translation is lossy in both directions. Words don't capture the weight of a particular typeface at a particular size, the specific warmth of a terracotta used as an accent, the way a generous line-height makes a dashboard feel less oppressive than the same layout with tighter spacing.

Mowgli's approach is different: you can bring visual references in at any point in the process — at the very start, during the identity and style selection stage, and after your app is generated on the canvas. The creative steering never closes.

Before the questionnaire

The first opportunity to add references is before you answer a single questionnaire question. Upload a screenshot of a product whose aesthetic you want to borrow. Add your brand guidelines, a logo, or existing marketing assets. Drop in a photo that captures the mood you're going for. These inputs shape the style directions generated for your product — the aesthetic territory the identity stage explores is informed by what you brought in.

This is also where a rough sketch is useful. A hand-drawn wireframe or whiteboard photo communicates structural intent — where the main navigation lives, how the primary view divides, the rough shape of a key flow. Upload it here and describe what it represents. The questionnaire then captures the full product model, and the resulting design reflects your structural thinking without requiring you to reconstruct it in text.

References with a short description of what you want them to contribute work better than references alone. "Use this colour palette but the layout doesn't matter" is a different instruction from "the typographic weight and spacing of this brand is what I'm after" or "this is the wrong version — avoid this direction." All of these are valid inputs.

At the identity and style stage

After the questionnaire, Mowgli surfaces 16+ design directions for your product. This is the identity and style stage: concept, colour, branding, visual language. You're choosing the overall direction your product will have, not the pixel-level details.

You can steer here too. Upload additional references if the grid isn't going where you want, specify colours you need the directions to include, or mix cues from different cards to narrow in on a specific feel. The directions respond to what you add. If you have brand constraints that weren't captured before the questionnaire, this is where they come in.

You pick up to four directions, preview them on a flagship screen from your actual app, and choose the one that's right. That selection is what the full generation is built from.

On the canvas

Once your app is generated, the canvas is where the detailed steering happens — and it stays open.

You can change anything: adjust a layout, rework a component, rephrase copy, update a flow. Each change is instant. But you can also bring new visual references into the canvas if your thinking has evolved. Upload a screenshot of something that gave you a new idea — a competitor's approach, a design you came across that solved a problem you're working through — and use it as the basis for exploring a direction on your current screens.

If you want to try a fundamentally different aesthetic after generation, there are two paths. Redesign applies the full identity flow to your existing project — new directions, new selection, regeneration in the new theme while keeping the spec and screen structure intact. Or you can simply tell the canvas what you want: "update my designs to look more like this" or "regenerate this section in a warmer direction" and the project updates. The chat stays open throughout. Nothing is set in stone.

This is what a living design canvas means in practice. Not a static artefact that gets handed off and forgotten, but something that keeps responding to new inputs — a reference you found, a direction a stakeholder suggested, a visual idea that arrived mid-process. The canvas absorbs the new information and reflects it. You don't lose what was already built; you steer it.

New ideas arrive during design — always. A stakeholder suggests a different approach, you come across something that reframes the visual direction, the product shifts and the design needs to follow. The ability to bring references in and explore from them doesn't expire when the first generation is done. It never expires.

Why vibe coding tools aren't built for this

The tools most people reach for when they want "AI design" — v0, Lovable, Bolt — generate compiled web applications. That's genuinely useful for a different purpose. But it's the wrong medium for design exploration, and the difference matters when you're trying to evaluate visual directions against each other.

Design exploration is a spatial activity. You need to see multiple options at the same time, side by side, at varying levels of zoom — inspect the detail of one layout, step back to compare the proportions of two others, zoom in on a component treatment to understand whether it works. This is why design tools use a canvas. The canvas is not a convenience feature. It's the medium in which comparison happens.

A compiled web app is one thing at a time. You see one version of the design. To compare it against a different direction, you need to navigate to something else, hold the previous version in memory, and imagine the comparison. Or you build workarounds — temporary buttons to toggle between colour schemes, query parameters to switch between layout variants, commented-out code blocks representing alternatives. These are approximations of a comparison that a canvas makes immediate.

The result is that exploration in vibe coding tools tends to converge faster than it should. Not because the right direction was found, but because the tooling makes exploration expensive. Every new direction means a new prompt, a new compile, a new round-trip. Most people stop exploring earlier than they should because each iteration has friction, and the friction accumulates. The design you ship isn't the best direction — it's the last direction you generated before the process became too cumbersome to continue.

This is especially visible when you try to bring in a visual reference. In a vibe coding tool, uploading a screenshot of something you want to emulate means describing what you see in that screenshot back to the AI and hoping the output resembles it. On a canvas, you can place the reference directly alongside your generated screens and evaluate the comparison yourself. The reference stays visible as you work. You can zoom between them. You can immediately see what's been captured and what hasn't, without relying on the AI's interpretation of your verbal description of the image.

There's also a technical reason vibe coding tools are slow for design exploration: they rebuild everything. When you make a visual change in Lovable or v0, the tool doesn't know the change is visual — it treats it like any other change, recompiling the application, rebuilding routes, regenerating backend logic that has nothing to do with what you adjusted. You changed a colour. It rebuilt a web application.

Mowgli is frontend-only and built to be fast at exactly this. There is no backend to rebuild, no routing to recompile, no application state to reconstruct. A visual change — adjust a layout, swap a component style, try a different colour direction — renders immediately on the canvas because the canvas is the product. The feedback loop is the speed of your eye, not the speed of a build pipeline. When exploration needs to be fast to actually be exploration — when the friction of each iteration determines whether you try the next idea or give up and ship what you have — the difference between instant and "wait for the build" is the difference between a real creative process and a constrained one.

Why this matters

The alternative model — reference inputs accepted at one point, locked after that — treats design as a pipeline with a fixed entry. Mowgli treats it as a process that remains open to new information throughout.

Creative steering at the beginning produces better starting directions. Steering at the identity stage produces a better aesthetic foundation. Steering on the canvas lets the design evolve as the product evolves, without having to restart from scratch every time something changes. Each stage has a different kind of steering available, and none of them close before you're done.

The canvas is what makes this possible. Exploration on a canvas — multiple screens visible at once, zoom available at any level, references placeable alongside generated output — is a fundamentally different activity from iterating on a compiled application one version at a time. Brainstorming needs ideas next to each other. Comparison needs spatial proximity. Design exploration is not something that happens in a browser tab — it's something that happens on a surface where everything you're considering can be seen at once.

You never have to describe in words what you can more accurately show.

Sources