A quick reminder if you're new here. We're ZURB. For 25 years we've asked one question in a hundred different ways: how do teams make better product decisions faster? It's the thread running through our work, through the design methods a generation of teams learned from, and through Helio and Glare.
We built Radar, our product and design newsroom, to test something. Radar runs about 95% on its own. It watches 60-plus sources hourly, filters the noise, groups the signal into topics, drafts articles, illustrates them, publishes daily. Two weeks of working on our side time to get it built.
The automation isn't the story. What held our attention was what automation did to the shape of the work. Design has always organized itself around phases. Discover, define, design, deliver. A phase assumes you finish it and move to the next one. That assumption is what's breaking.
The unit of work is becoming the loop.
What a loop actually is
Intent goes in. An outcome comes out. Between them sits a decision.
That's the whole structure. Two questions govern it: should this be automated, and what deserves attention? The first question sorts the work. The second question is the one only a person can answer.
I lightly tackle this in my LinkedIn post on designing with loops.
Most AI conversation fixates on the one-shot. Prompt in, output out. That's a transaction, not a loop. It produces something once and teaches you nothing. A loop runs again. It carries what it learned forward. Loops compound where one-shots don't.
The difference matters most on a team. You can do remarkable things one-shotting in your own corner. None of it transfers.
We talk about loops, and show how they nest
Ben and I go into the details of our loops in Radar, and walk through some of the ways we’ve been thinking about loops.
Here's the mechanic teams get wrong when they try to automate "the workflow." There is no the workflow. Radar isn't one loop. It's four, stacked.
- The watch loop runs hourly. It pulls links from 60-plus sources, an AI labels each one for relevance, and anything below the bar gets filtered out. We still store the rejects so we're not reindexing them, but they never surface. Fully automated. No human touches it.
- The grouping loop takes the surviving links and compacts them into topic headlines. It looks for signal density. If a bunch of unrelated articles pile up with nothing connecting them, nothing gets published. Also fully automated.
- The ranking loop is where a person enters. We built an arena where editors judge headlines head-to-head. It runs on an ELO system, chess-style. Pick the stronger topic out of four and scores adjust, a low-ranked winner jumps a lot, a high-ranked loser drops hard. They don't swap positions outright, but the pressure is real. The system produces the first ranking. Human taste corrects it.
- The generation loop drafts the article, pulls sources, makes an image. Then a person checks whether the sources are real and whether the writing is good enough to ship. Right now, that's manual. It doesn't have to be.
Four loops with four different machine-to-human ratios. That's the point we’re demonstrating. You don't automate a workflow (yet…). You decompose it into loops and set the ratio on each one separately.
Technically
What actually makes up Radar? How was it built?
We use some boring, old-school technology to build Radar, on purpose. RSS feeds are easy to pull in (they’re basically just a list of latest articles that websites provide), and when paired with a cron job, it makes it easy to capture articles and start feeding them into an indexed list of links that we can parse.
Once those links are flowing in, we make sure that they won’t be re-indexed, or pulled in again. We store them away to be revealed in the next few stages of our loop.
We have a small, cheap model doing some of the hard work up-front. For each link that gets pulled in, it gets labeled, categorized, and we apply a relevance score of 0-100 (100 being most relevant) to capture which links are viable and useful to product & designers, and which aren’t.
We filter out the ones that are under a score of 40 so that they’re not cluttering the next phases of the article generation loop. Those rejected links stay indexed but hidden, because deleting them would just mean rediscovering and re-labeling them next hour (more costs).
Storage is cheap but repeated work isn't. It's a big part of why a finished article costs us about 30 cents.
Everything runs as small, scheduled jobs rather than one giant prompt. Pulling and indexing links run hourly, grouping related links together and generating topics for our ranking loop run daily.
The ranking loop stores an ELO score per topic leveraging a chess-based system, starting off with 1400 to 1600, and updates it from human-decided, head-to-head judgments.
The generation loop drafts the article, pulls its sources, and produces an image in about a minute (which is also why it’s the most expensive part of the process). And the loops that purposefully block a person carry two things that make them trustworthy: state, so a loop running continuously has a durable memory of what it's already done, and a guardrail, so nothing reaches production until a human has reviewed it.
The human loop is scaffolding
Ben and I disagree about this, which is how I know it's the interesting part.
The tempting read is that the human calls in Radar are permanent. Sacred. The two places where judgment lives, protected forever. That's a comfortable story and I don't think it's true.
Every human loop is a question about missing context.
Take the feedback loop we run on Radar's interface. I drop notes in Slack, usually with screenshots. Ben has Claude read the thread, summarize what I asked for, turn it into a PRD, and feed it to the code. It half works. The last release shipped tag alignment correctly, botched the layout order, and broke a button in one of the three visual styles because the font pushed it sideways.
So the question isn't whether to keep a human in that loop. It's what the agent is missing.
Does it need screenshots?
Access to the repo?
Memory of fixes it already made?
Does it need to look at the live site to understand what it's changing?
Every one of those is a variable, and each one we solve shrinks the human's role in that loop by a measurable amount.
That's the work right now. Not defending the human loop. Interrogating it. Naming exactly what a person supplies that the machine can't yet, then closing the gap on the parts that are closeable.
A human loop that never shrinks isn't judgment. It's an unexamined dependency.
What doesn't shrink
Some things stay.
When we went from a dozen hand-picked feeds to the full list, about 60% of what came in was noise. Shopping deals, gadget guides, celebrity gossip. More input didn't make Radar better. The filter did.
The filter is a question we decided to ask of everything: would a busy product or design leader care, and could they act on it? That question isn't in the data. We brought it to the data.
Intent is the scarce ingredient. The model will process infinite input and produce infinite output. The only thing you can supply is the standard that determines what deserves a person's attention. Set it deliberately or volume sets it for you, and volume has no taste.
The same held for voice. Our early articles were accurate, well-sourced, and completely dead. Our team called them encyclopedia entries. We only found the voice by shipping the flat version and reacting to it. You have to ship a product to understand how it works. Radar made us live our own advice.
There’s more work to do, not less
This does not give you a quieter team with less to do.
The machinery gets faster and the judgment gets denser. There's more to decide, more often. There's also a dependency nobody warns you about... once your loops run fast, you start needing them to run faster. Every delay stings. Watching an article generate for sixty seconds becomes unbearable in a way that hand-writing it for two hours never was.
What changes is the rhythm. Loops turn heroics into cadence. Progress arrives on a beat instead of in all-nighters, and everyone around you can see it moving without one person one-shotting the whole thing.
There's a cost, and it's real for designers. To keep a loop improving you have to let go of pieces of it. The instinct is to perfect each release before it ships. Loops punish that. What works is moving forward continuously as long as the intent behind the loop is anchored in something a user genuinely needs. Keep chipping. The experience gets better than any big-bang redesign where you gamble everything and never learn whether it worked.
What this means for design leaders
If the loop is the unit of work, design leadership is loop design.
That means deciding what runs on its own, where a person enters, and what the intent is that governs both. Draw the line wrong in one direction and you automate the judgment away, which produces confident garbage at scale. Draw it wrong the other way and you keep people doing machine-work, which wastes the exact judgment you're paying them for.
It also means treating your judgment moments as products. We built the editorial arena as an actual interface because those calls steer the machine. If your two most important decisions get made in a hurried Slack thread, you've under-built the most important part of your system. Give your best judgment the best tools.
And it means accepting that the map keeps moving. The loops you draw today are provisional. The context you supply by hand this month is the context you automate next month. Design under phases produced deliverables. Design under loops produces systems that improve on a schedule.
The interesting creative work didn't disappear when we automated Radar. It moved. It moved into the decisions sitting right next to the machine: what to cover, what to cut, what good even means here. There are more of those decisions than you'd expect, and they're better decisions, because nothing is hiding them anymore.
AI won't automate your work away. It shows you how much work you were actually avoiding.
Radar is live at radar.zurb.com, built by the team behind Glare. If you're leading a team through this shift, or you want to argue with any of it, the forum is open on the topic of loops.
