THE THING WE BUILT:

Text to Wireframes

I’ve wondered about the value of wireframes for a long time.

Not to say they aren’t useful. They certainly can be. But I’ve never been convinced they’re the right tool for every project. As it’s become easier to move directly to high-fidelity designs, there are plenty of situations where it saves time to skip wireframes altogether.

But that assumes wireframes take enough time to create that it justifies recreating the same ideas a second time in high fidelity. The wireframe has to save more time than it costs, and it has to provide enough value during the process to justify that extra step. Sometimes it absolutely does. But not always.

What’s changed is that turning text (simply jotting down your thoughts) into a visual is becoming dramatically faster.

We already see it with tools like Mermaid. We describe a system in text, and moments later we have an architecture diagram. The time isn’t spent drawing boxes. It’s spent thinking through the problem.

If the cost of turning text-based thinking into a useful visual becomes small enough, the role of that visual starts to change, especially for something that was always meant to be thrown away. It becomes less about documentation and more about exploration.

So I started wondering whether wireframes could serve that same purpose.

Not as polished deliverables or even as blueprints. Just as a fast way to externalize an idea, react to it, and iterate before committing to anything.

Editing a .wf file

How It Works

1. Write screens in plain text. Type screens in a tiny wireframe language. Elements nest by indentation like an outline.

@flow coffee-order
@start splash
screen splash 375x812
block hero
text h1 "Order ahead"
button "Get started" -> menu
screen menu 375x812
bar back -> splash
list
row "Oat latte — $5" -> item

2. Click through it like the real thing. Screens lay out as frames on a canvas you can pan and zoom. Arrows (-> target) wire up the navigation, so clicking a button actually goes somewhere.

3. Catch broken flows before the demo. The tool lints your links as you type: unknown targets, duplicate screens, dead ends. You get import-style error checking. And stakeholders get a prototype that never strands them on a screen with no way out.

4. Same file, mobile or desktop. Screen width drives the render. At 375px it reads like a mobile app; at 1024px, a desktop-sized site.

5. Optional sitemap view. After playing with it, we added @sitemap support: an indented tree of pages, same syntax as the rest of the file. You could sketch that hierarchy in a simple Mermaid diagram, but here it lives beside your wireframes and renders as a sitemap-style tree right on the canvas. Switch between the frame strip and the architecture view without leaving the tool. Skip @sitemap for linear app flows; add it when you want the site map, not just the click path.

Notes from Building

This idea came out of a broader shift we've noticed in how we build software.

More and more, we find ourselves spinning up a repository earlier in a project. Sometimes before the SOW is signed. Before designs exist. Before anyone has agreed on exactly what we’re building.

Instead of waiting, we start thinking in the repo.

Estimates. Architecture diagrams. Technical notes. Increasingly, those all begin as text. They evolve through commits, and in some cases, become part of the project’s history.

That got me wondering why wireframes shouldn’t live there too.

If a wireframe can be generated from text, it inherits many of those same benefits. It's version controlled. It evolves alongside the project. Every commit captures not just how the system changed, but how the thinking changed.

It also becomes a tool for faster iteration.

During a whiteboard session, someone suggests moving a button, adding another step, or splitting a screen in two. Today, we might open FigJam and shuffle sticky notes around. Tomorrow, maybe we edit a few lines of text and watch the prototype update alongside the conversation.

That feels like a more natural way to think through a product.

Built with ❤️ by Township

You’re receiving this because you signed up for Township’s “We Built a Thing” newsletter. We'll only send these when we, well, build things.