ZERO TO ONE // How TO Approach The Design
I’ve been fortunate enough in my career to work on a number of zero to one projects. If you don’t know, zero-to-one generally means building/designing the very first version of apps. It’s going from nothing to something. it’s innovation.
The products I led were diverse and covered a wide range of problems to solve. Those products were:
Boeing’s first suite of mobile apps
I was the lead designer of Boeing’s first mobile team. We built apps for flight attendants, mechanics, and pilots to streamline their workflow.
Facebook Live Experiences
I worked with an agency called ustwo and partnered with Facebook to create live experience frameworks. These were strucutured content experiences designed to make Live more fun and enjoyable. And the underlying framework was in place so other companies (like Spotify) can build their own engaging live experience.
Fanduel Faceoff
At FanDuel, I was design director overseeing the design and launch of FanDuel Faceoff - a real money gaming app. It’s an app where you compete for money against real people playing casual phone games like Wheel of Fortune, Boggle, basketball, cornhole, golf, etc.
Building those zero to one products was a great experience. Here are several themes I learned along the way, along with actionable advice on designing zero to one software.
Go Wide With Exploration
You want to explore the solution space and go wide with coming up ideas. Structured sketch sessions help here. Since the product is new, you’re generally either have a fuzzy idea of what it is, but not really in detail on what defines it as a product.
A snapshot of early exploration for the Facebook Live Themes project.
You want to avoid the first thought that comes to mind. Instead, really push on ideas and concepts. Spending time sketching out ideas will help you:
Think through the product in more detail helping you define what it is
Give you confidence. Since you’re exploring many options and being thorough you’ll have confidence you’re settling on the right idea.
Help you identify underlying themes and key points you want your product to hit on.
Going wide and exploring the solution space isn’t just fun or a neat kick off idea. It’s a core part of product discovery. Think of in terms of discovering your product. Discovering what is unique about it and how it can be offer a competitive advantage.
Looking for sketch sheets?
I have some for ya. Download, print, and get to exploring 🚀
Move Fast
The balancing act that comes with spending time exploring is knowing when to move forward. When dealing with zero-to-one, there’s a lot to uncover and a lot to get through. But you have to keep moving fast.
Zero to one products are fun and exciting yet deceptively complex. It’s easy to get caught up in the early excitement only to find yourself spinning you wheels and not moving forward.
Timeboxing and keeping things lofi (ie sketches, basic wires) helps you move fast through the early parts of the process. TImebox the period for concept exploration - ie a week for example. Use lofi tools like sharpie/paper and/or lofi wire framing software like Balsamiq or Miro.
Pillars Are Your Pals
Have a framework to evaluate your ideas on. Instead of “oh I like this, or maybe this one”, evaluate ideas based on key pillars. Settle in on this key criteria early in your process.
Pro Tip: you pillars should include at least something related to business metrics, value prop, competitive advantage, etc.
For example, let’s say you determine six key criteria for selecting a concept. Evaluate each idea based on that criteria. This will help speed up your decision process. Below is an example graph. The pillars should be determined early on in the project.
An example graph used to evaluate ideas.
Make Ideas Tangible
This is where designers really shine in the org. You’re the first to make the ideas tangible. Once you’ve narrowed it down to a few concepts, start mocking them up. Keep the UX simple and build out a prototype to get a feel of the product.
You can always go back and refine the UX. The idea is to get to something that gives you confidence in the what the product will be. The UX can be basic to begin with and that’s ok.
They value in prototyping soon benefits two parties:
The Immediate Product Team
First, it helps the product team start to realize the vision. It’s one thing to sketch stuff out, have conversations, jot down principles. But once something is in your hand and your tapping, swiping, scrolling, etc, it starts to get everyone gravitating around the same concept.
There’s immense value in everyone pointing to the same thing and saying: is this what we all agree on? Where do we differ? What are we still not sure about?
And this helps shake out alignment. Questions will arise for all parties. Product: is this capturing the competitive advantage we talked about? Design: does this UX fit into the product principles. ENG: how feasible is it to build something like this given the timeline.
Early tangible prototypes promote alignment and surface areas that further need to be explored.
It also allows you to do early testing with users to see if your concept is resonating.
Stakeholders
Prototypes help the broader business unit and stakeholders understand what you are building.
While at Boeing, when we first set out to build mobile apps, one senior director halfway joked: “what are you making, Angry Birds for planes?”. It was a dumb joke but also there was some hidden truth in it. He didn’t really understand what we were building or didn’t see any path forward for mobile apps in the Boeing company. And that’s ok, it wasn’t his job.
But us as the product team, we needed to A) to get clear on the problem and solution we’re tackling and B) help others understand - most notably key stakeholders - what we are doing, why we are doing it, and the business value of what we are doing.
Getting prototypes in stakeholder’s hands is the most effective way to bridge this gap. It instantly clicks, grounds them in the vision and more importantly unlocks that “oh I get it and understand what you are doing here” moment.
And when that prototype got in that managers hands he said “ohhhh now this makes sense, I didn’t think about this. Wait, this can be really good for the company. Have you thought about X, Y Z? I can get such and such to help. What else do you need?” And on and on. It brought alignment and support.
just because it’s obvious to you doesn’t mean it’ll be obvious to others. This is especially true with new, innovative, zero to one products.
Bring In Engineers To Prototype
Ok I know I said this is where designers can shine. And that’s true. Getting designers to prototype early is great. And you want to socialize those designs. It’s relatively cheap for designers to mock stuff up in Figma and knock out prototypes.
A few iterations of prototyping will raise your confidence.
And when you start to develop strong confidence in a few ideas, it’s best to lean on engineering to prototype. Not to build, but to prototype.
I can’t stress that enough.
Make sure your engineering knows they are in the product discovery phase and not a build phase. They need to prototype - not actually make it work. Just look like it works on the surface.
I talk about simplification a bit later, but the general idea is your V1 should be quite simple in design. This would make it easier and more realistic to get engineering to prototype.
benefits of Engineering BUILT prototypes
More tangible ideas are created for testing resulting in richer results
Makes the project more real.
Sometimes prototypes can be seen as a “cool little project”. Once there’s a build and someone has to install it, it just feels a little more real. People get a little more invested. Questions, comments, concerns, support, etc start to pop up. You want to tease those out as early as you can in the process.
The obvious risk here is the ideas can be too real. You’ll have to manage expectations. This can be done with proper timeline management and “branding” your prototypes.Gives engineering insight into what it would actually take to build.
Engineers insight here can help steer design and product. If certain features are going to take months, perhaps it’s deprioritized or the designer can figure ways to design a scaled down version of the feature.
Watch And Listen To Your Users
This won’t be for every project, but for many you’ll want to really sit with your users. Do some proper user research. Interview, talk, converse, and observe to really hone in on the pain points they are feeling.
Usually with zero to one there is some sort of unique problem to solve and therefore a unique value prop you can offer. You may have a high level idea of it, but to truly understand the problem, sit with your users.
Expert Users
Expert users are a good source of information, though it should just be one source of input and not the end all, be all. They’ll definitely give you insights and help you get up to speed in areas you may not be so familiar with. The risk is keeping the balance between useful insights as a whole and insights that only benefit the expert user.
Observation Is A Wonderful Thing
Observation is a powerful technique. And it’s simple. Just observe users in the wild. Notice how they complete tasks, quirks, frustrations, emotional moments, patterns of behavior, and any weirdness.
There’s a classic video on IDEO’s design process where they redesign a grocery store shopping cart. It’s a bit dated, but the general principles apply. They did a ton of observation to understand the problems and solutions were formed from those observations.
You’ll learn unique insights you can build upon that’ll help serve your competitive advantage.
Simplify
Zero to one projects are exciting and you’ll no doubt come up with lots of ideas and features, and all sorts of cool things.
Zero to one projects are also a lot of work. There’s a ton of work that goes into solving problems that are still a bit gray, unclear, hazy and fuzzy.
There’s many different directions you can go. Lots of opinions. Lots of research, data, testing, exploration, concepts, conversations, meetings, prototypes, requirements, principles etc etc. All being worked out in real time, refined and edited. It can be stressful.
The best advice I can give here is to simplify the design. Really pare it back to the essence. Get clarity on what’s the core of the product and focus on that. It’ll be tough to say not to designing many features but it’s the way to go.
And it’s not saying “no”. It’s saying: “not now. Perhaps next release.”
And remember, as long as that product is still unreleased, you don’t really know if those features you want in there make sense. You want to get that product out there in customers hands and get feedback. Sure some features you put off will be obvious ones customers ask for. But you’ll learn more about features you didn’t think of.
Design For The Business
It’s more important to focus your design on UX that directly aligns with the business model. Having an understanding of the value prop, the target audience, and competitive advantage will help steer your design.
For example, if you’re working on a brand new social media app, you’ll probably hit the basics - a feed of sorts, posting, connecting with friends, etc.
Your next inclination maybe be to create a stunning logo, or dialing in the animations on screen. All of that needs to wait. It’s more important to understand what this app needs to succeed. Which probably means nailing the invite friends UX, or perhaps the discover tending posts UX.
Work with the product lead to understand what are the metrics needed, where the focus needs to be and hone in on that.
Don’t Design For Designers
Don’t design for designers is generally a true statement outside of zero to one products. But it especially applies in this case. What I mean for design for designers is designing things that other designers will think is cool. Things that will get a lot of love on social media. It' usually means fancy illustrations and animations.
And it has its place in overall design. Just not in zero to one.
What you design for zero to one may not be exactly what you want to show off to your designer friends (sometimes it will!) but it leads me to my next point:
Be OK WITH GOOD
I know designers don’t want to hear this but you have to be ok with good for the 1.0 release. It doesn’t have to be perfect. They key here is to get a good design out in to customers hands and get them using it. Get the feedback and evaluate from there.
In the subsequent releases you can really work on nailing the designs and making it a well crafted product.
Embrace The Paradox
There’s a paradox that comes with V1 products: the process takes navigating a complex series of challenges that feels like you’re on an unruly rollercoaster. But the end results is fairly simple. Almost basic. You’ll have a core set of features and that’s kind of it.
Don’t be discouraged.
Instead be proud you shipped something. And recognize you laid the groundwork to truly grow a stellar product.
A Design Approach To Zero To One | Summary and Advice
Above is generally what I learned from leading zero to one projects. There’s a few themes in there around speed, simplify, and building confidence. In general if I was offering advice on an approach it would shake out to the following:
Align on pillars
The product team should be aligned on the pillars you are trying to hit. And make sure there is some business connection in those pillars.Explore in Lofi Fashion
Sharpies and copy paper are you friend here.Skip The Middle
No need to do extensive UX mockups. As fast as you can go from sketch to working prototype the better.Learn throughout
Test, observe, circulate ideas, gather feedback, learn and calibrate.Fill up the cutting room floor
You’ll have plenty of ideas but you’ll need to cut plenty. You can pick those features back up in v2, 3, 4…Ship and Learn
The complexity of Zero to one projects sneaks up on you. Get a solid V1 out, learn and iterate on the design.
// Coleman
DO YOU WANT MORE?!
〰️
DO YOU WANT MORE?! 〰️
