UX design for zero-to-one

tl;dr —make fast decisions, cover end to end flow, and radically shorten cycles to get to “good enough” for your target users.

Today’s goal is to share what worked when designing UX for early stage products.

I want to create products that make lives better. I’m listening to Lovely Day by Bill Withers today.

Disclaimer: there’s a time and a place for everything. The focus of today is strategies and tactics to accelerate UX design for early stage software in product discovery. Not everything here will apply to all situations. It’s important to understand what your team and product needs at the current state of the product lifecycle.

Focus on the goal: a usable experience in the shortest number of cycles/days.

In early stage product discovery, and especially at a startup, time is money (even in big tech, don’t overestimate how long your VP is willing to wait for results). Try to arrive at something usable and understandable enough to unblock adoption by your target users, as fast as possible.

The key word here is “enough” — sometimes designers spend too much time pixel pushing/shading and over-refining a design to make it consistent and perfect. The ultimate goal is that our products solve a real user need, and the key is to focus on solving their needs first — making it beautiful and consistent can come after. As the saying goes, “form follows function.”

from Calvin and Hobbes

When designing a part of the product, there’s a rough lifecycle to the process that I’ve observed most teams do:

1. Understand user needs/problems (aka UXR)
2. Come up with design concepts
3. Agree on concepts to explore further
4. Flesh out designs and decide which ones to test
5. Test designs with mock/live prototypes
6. Decide on design to use in final implementation

Sometimes, teams get stuck in cycles where they keep going back to Step 2 or Step 4. Sometimes, teams completely skip some of these steps and ditch the concept testing or prototype testing altogether — this introduces more risk, but is manageable if you can derisk the UX sooner.

from Dilbert by Scott Adams

Here’s a number of failure modes that can significantly increase the time it takes to get to the last step, and suggestions to address these problems:

• Revisiting and churning on a design for multiple iterations
  If you find your team throwing out one design after another and spending multiple weeks of cycles hashing on the problem, then maybe you need to rethink this. Avoid exploring ideas sequentially, and try the IDEO-style diverge+converge approach, where you generate a lot of ideas first and then can narrow down to explore a few in parallel.
• Taking too long to make design decisions
  If you’re spending multiple weeks on refining and getting agreement on details in a design that don’t radically change implementation effort, then you’re probably wasting time. Time is precious, and if the decision is reversible and if the experience is “good enough”, then opt for making the decision quickly and improving the UX later when you have real feedback from users.
• Starting off with hi-fi mocks
  Most designers I know prefer to make beautiful looking hi-fi mocks. It makes sense, because that’s what UXDs are often most rewarded for and also what looks the best, but it also often takes 2x–4x longer. If your UXD doesn’t think it’d be faster, they’re wrong and they’re just not used to wireframing and sketching first. Always start with sketching the information architecture, layout, and interaction pattern first, and then get into the visual design details around color, typography, etc. You can come to much faster fundamental design conclusions on whether a flow makes sense at all, which saves the entire product team time.
• Not using real copy/images in your wireframes/mocks
  This seems like a minor detail, but it can end up a dealbreaker later. If your wireframes or mocks don’t have an accurate representation of what the data you’re showing will look like (e.g. loren ipsum or short squiggly lines or “this is an example…” text or a fake chart, etc), then you’re more likely to run into edge cases later that break the design. Ask your PM for 5 examples of real data that may show up in the feature you’re designing, ideally get some that represent the edge cases. Design with this in mind and it will help the UX scale appropriately. For example, if you’re designing a feature to preview and edit emails, make sure to mock up examples with long html newsletters!
• Not designing for end to end user journeys/flows
  Some designers take a “component catalog” approach to UI design, where they’ll design a specific component and all its various states, and create a little “catalog” spec sheet in Figma for the team to look at when implementing. This makes sense if the product design is at that stage. The problem in early stage products is that often the overall user flow is not yet fully fleshed out, and you need to take into context the overall goal and journey the user will go through to accomplish their task. If you don’t do this, sometimes you’ll find later that jumping from one screen to another makes no sense, or a component no longer makes sense after it is inserted into the context of the page. Make sure to look at designing the end to end flow before getting into the details on specific components and states. This is an issue that often crops up late when you finally put together the journey and realize something is off, and forces the team to do another round.
• Not thinking through how the design/interaction pattern scales
  This is especially necessary in productivity software or most b2b products, because if any customer/user ends up using it a lot, they will end up with a lot of artifacts and data in your product. An initial design may look nice, but the moment your users have more than X things on the screen, a good UX gracefully degrades or scales for the situation, and a poor UX breaks. Whenever you design something that may have multiple items a user has to browse or click through, make sure to think about how it scales if there’s 10x the items there (think galleries, menus, lists, navigation, selection, dashboards, etc). Consider this for object editing patterns too, although often less of a problem unless it becomes a common need. This is one of the most common reasons I’ve seen designs get sent back for another round of iteration.

Lastly, it’s important to remember that UX design is an important part of the cross-functional product team. If your UX team or UX designer is not working as scrappily as you’d like, don’t jump to firing them — work with them to figure out the right collaboration approach and help them grow into early stage ethos. I’ve found it more effective and creates more bridges and opportunities in the long run.

UX design is crucial to the success of many early stage products, because it’s what enables users to easily intuitively use the product. I won’t say no to a beautifully designed product… if it solves my problem. :)