Design by Pizza

Brandon Arthur Roth
6 min readMar 22, 2018

Design by Pizza is our way to bring simplicity to our design. It’s a commitment to creating human centered experiences from the inside out. It’s a way to bolster quality and improve efficiency as our team scales. And yeah, it’s a bit absurd.

The last 6 months have been a whirlwind for Radar. Rapid iteration has pushed code out the door quickly but as we move forward it’s important to dial in the details. We need to be responsive to all of your feedback and make sure we get to a world class product experience. All of that means one thing: time for a design system. We’re just getting started, but we thought we would let you in on our work in progress.

It’s important for us to be calculated in how we go about this and ensure we’re building for Radar rather than pulling from a template. Our first step was to define a set of success criteria:

  1. Be consistent yet malleable.

Blockchain is in its early stages and so is our product and team. As the ecosystem evolves and conventions come to light, iterations may or may not be so subtle. We need a system that keeps our team on the same page, but doesn’t require reworking piles of documentation or wading through too many workflows when things change.

2. Be optimized for less pages and more subtle interactions.

Unlike a content or e-commerce site, system wide templates aren’t that important for us. The horizontal architecture or our app is fairly limited in scope but we have many smaller, data-heavy pieces with lots of micro interactions.

3. Be relatable.

Everything we do should be in service of making blockchain relatable, simple, and accessible all the way down to how we describe our design process. Metaphors work wonders when it comes to breaking down complexity and gaining buy-in from stakeholders.

4. Be easily exportable.

As the team grows we need to quickly outsource work to contractors and potential new hires. This requires a modular setup to handle shipping out small chunks of work and targeted tasks. We also need an on-boarding process free of complex terms, jargon, excessive apps, paperwork, or lengthy education.

With these criteria in mind we came across a great organizational structure. One that happens to mimic everyone’s favorite thing.

The Pizza Model

We found pizza to be a great analogy for our system. A whole pizza is made of slices. Each slice fits together modularly. Toppings are freely distributed across slices. Some slices may have pepperoni & black olives while others have pepperoni & green peppers. Any combination of slices can be assembled to make new kinds of pizzas.

Cheesy? Yes. But the reason this works well is that mid-level components make up the bulk of our app. The micro and macro parts are fairly straightforward, there aren’t piles of icons or pages. However, each page is built from small pieces repeated multiple times in different contexts. The slice is where all the focus belongs, exactly like a pizza. The analogy paints an immediate visual that doesn’t require much effort to understand. If the goal is to make complex ideas & tech relatable, this seems like a fitting foundation. Plus, the pun-ability is supreme, so let’s dig-in.


🧀 🍅 🌶

Toppings are all the bit-size pieces: colors, fonts, icons, buttons, and input fields. For our purposes the smallest parts in the system are those with isolated functionality, such as input text, click an icon, open a dropdown, color a background. Updating these items applies the change to that item everywhere it occurs across the app.

Within our toppings category we found we’re able to streamline the majority of our items into groups of three — for now, at least. This keeps a nice symmetry with the overall system. In general we have an active, disabled, and default state for buttons. Highlight colors correlate to three actions: positive, negative, and error. Green for confirm, buy, proceed; orange for cancel, sell, warning; and red for errors and validation. Fonts stick close to a similar rule with large, medium, and small sizes each with a left, right, or centered alignment.



Toppings are great but only filling when you put them on a slice. Slices are ready-to-eat pieces that are easily portable. They combine the isolated functionality of multiple toppings into something with a specific purpose: manage balances & transactions, choose a marketplace, display trade history, etc. The entirety of the app is broken into slices, each with multiple states. Changes made to slices affect only the slice and it’s copies.

Because this is the meat of our app, we’re building as many contextual states as we can into each slice in our design files. The wallet, for example, has duplicate slices for showing tokens list, history list, orders list, disconnected state, and so on. What’s left are the small interactions that come through updating the toppings: toggle on/off, text updates, and icons. This way we can easily visualize subtle user flows.

The Whole Pizza

When you get enough slices together, you end up with a pizza. These are holistic views that combine the actions of many slices for the purpose of an outcome. Thinking of it this way makes sure we’re combining slices for the experience, not the page. For example: connect your wallet, check your balances, place a market order, these are all the actions a user performs to complete a trade. All the slices need to fit perfectly for the pizza to form it’s ideal shape.


Breaking down the three parts of a pizza makes our workflow pretty simple. One master pie is kept sacred and is updated after every sprint with any new toppings or slices. Delegating work becomes a matter of forking a slice and handing it off to whomever is going to work on it. The slice is put back into the master and updates are synced. All the various parts live within the master where our complete list of items can be found. Having this master list will help us build naming conventions in-sync with the dev team.

Closing The Lid

While the analogy may be a pun-filled storyline, building this system helps center our team around creating a great product. We are better positioning ourselves to iterate more quickly and more calculated. We’ll continue to provide insight into our process as we move forward. Next time we’ll peel back the lid and knead through all the details for any designers out there. We’ll also take it easy on the pizza puns.



Brandon Arthur Roth

Contract Designer & Creative, Co-Founder @RadarRelay, previously Design Director @MadeSays, Board Member @AIGACO