Prototyping in code without becoming a developer

A year ago, our design team spent most Tuesday and Thursday afternoons in meetings explaining ideas. Static mockups, long walkthroughs and the same questions every time: what happens when you tap this, how does it feel on a slow connection, what if the list is empty? Today, most of those meetings are gone. What replaced them is a thirty-minute ritual every Friday and a lot of rough, clickable prototypes.

The Friday ritual

Every Friday at three, each designer spends thirty minutes turning one idea into a rough coded prototype. It doesn’t need to be pretty or complete. It needs to be clickable and real enough to react to.

The rules are simple, and they live on a sticky note on our team board:

• Thirty minutes, no more. The time limit keeps ideas small and stops anyone from polishing.

• One idea per prototype. A single interaction, flow or behaviour, never a whole feature.

• Share a link, not a deck. At the end of the session, everyone posts one link in a shared thread.

• Rough is the point. Placeholder text, default fonts and broken edges are all fine. If it explains the idea, it’s done.

People click, comment and move on. No slides, no long walkthroughs. By Monday, the best ideas have already collected a dozen comments from product, engineering and support.

Why it replaced meetings

When we looked at our calendars honestly, many meetings existed only to explain an idea. Someone presented a flow, and the rest of the room tried to imagine how it worked. Half the questions were about behaviour a static screen couldn’t show.

A working prototype explains itself. Once people could try something, the discussion got shorter and far more specific. Instead of “I’m not sure about this flow”, we heard “the second step feels slow when the list is long”. That’s feedback you can act on.

A prototype answers the questions a mockup only raises.

Within two months, we had cancelled half of our recurring design syncs, and nobody asked for them back. The meetings that survived got better, because they focused on decisions instead of explanations.

What we actually build

Most Friday prototypes fall into a few categories. Knowing them helps new designers pick an idea quickly instead of staring at a blank editor.

• Micro-interactions. A button state, a loading pattern, a swipe gesture. Small details that are hard to judge in a static file.

• Real data. Plugging a sample dataset into a list or chart to see how the design holds up with long names, empty values and odd numbers.

• Edge cases. Error states, slow connections and empty screens. Easy to forget in mockups and painful to discover in production.

• Alternative flows. Two versions of the same task side by side, so people can feel the difference rather than debate it.

You don’t need to be a developer

This is the part that worried people most at the start. Several designers on the team had never written a line of code. Most still wouldn’t call themselves developers, and that’s fine. The goal is learning, not production code.

Most prototypes use simple tools, copied snippets and a lot of trial and error. AI assistants made a real difference here: describing an interaction in plain language and getting a working starting point removed most of the fear of a blank file. From there, designers tweak values, swap content and break things until the idea works.

We also built a small starter kit: a template with our fonts, colours and a few common components already wired up. Starting from something that looks roughly like our product saves the first ten minutes of every session.

How engineers got involved

We didn’t plan this, but engineers started joining the Friday sessions after the first month. Some came to help, some came to try their own ideas, and a few came because the prototypes were more interesting than their Friday backlog.

That shared curiosity has done more for collaboration than any process document. Engineers see ideas earlier and flag technical constraints before they become problems. Designers understand what’s easy, what’s hard and why. Handoffs got smoother because, in a way, they now start weeks before the handoff.

Getting started with your team

If you want to try this, start smaller than you think. Here’s how we would do it again:

1. Pick a fixed slot. Same day, same time, every week. Consistency matters more than duration.

2. Prepare a starter template. Remove the setup work so people can focus on the idea.

3. Lower the bar publicly. Share your own rough, slightly broken prototype first. It gives everyone permission to do the same.

4. Collect links in one place. A single thread or page where every prototype lives. Over time, it becomes a library of ideas.

5. Review after a month. Look at which meetings you could cancel and which ideas made it into the product.

What it changed

The Friday ritual didn’t turn designers into developers. It turned them into people who can show an idea instead of describing it. That small shift saved us hours of meetings, improved the quality of feedback and brought design and engineering closer than any reorganisation could.

Thirty minutes a week is a small investment. For us, it’s been one of the best we’ve made.