Three product design techniques to “just get started”

Often, the hardest part is just getting started, and specifically: picking a place to start. Especially for big projects, how you sequence your work can matter a lot. So how do you pick?

In a previous post, we discussed 2 reasons why product designers struggle to “just get started”: waiting for perfect information that may never come and waiting too long to share our work because we've set our bar too high.

Today, we'll discuss 3 techniques to help you “just get started” on your product design project. My hope is these techniques will help you work smarter, overcome your perfectionism, and make the overall design process less stressful and more fun for both you and your team.

Does it really matter where I start?

When you're at the beginning of a project, feeling stuck, and looking for advice, your manager or colleagues might tell you “don't overthink it, just pick a place to start.” This is often fine advice for small, simple, sprint-sized projects—picking a screen at random and going straight to high fidelity mockups might be fine, especially if you're an experienced designer and only have a few screens to cover. I appreciate the bias-to-action and “better over perfect” mindset.

However, for bigger, more complex, marathon-sized projects, picking a starting point at random may not be the best approach—especially if you are strapped for time and resources (shout out to my design teams of one out there). Try going straight to high fidelity mockups when you have an entire product to design, and you're not even sure what all the screens and functionality are yet—do you just pick a screen to design at random? That's a tough road.

Where you start—and where you decide to focus your time and attention, especially early on—can make the difference between a stressful design process, and a calm, productive, and truly enjoyable one, for you and your team.

So how do I pick a place to start?

Before we get into the techniques, let's talk high level goals and what these techniques can help you accomplish.

At the beginning of a project, it can be hard to see all the work to do. If you can't see all the work to do, it can be hard to strategize and work smart: you might spend your time in one place, when it would have been way more valuable to spend your time in another “yet-to-be-discovered” place.

The goal with these techniques: as a product designer, get a better view of all the work to be done, so that you can pick a better place to start, sequence your work strategically, and work smarter.

To borrow from the book Shape Up, they refer to this as finding the “rabbit holes”—risky unknowns to derisk sooner—and getting to the ”top of the hill” to get a better view of all the work to do, so you can pick a better place to start:

“Every piece of work has two phases. First there’s the uphill phase of figuring out what our approach is and what we’re going to do. Then, once we can see all the work involved, there’s the downhill phase of execution.”

Once you're at the top and you can see all the work to be done, there will still be some “known unknowns,” but—if you use these techniques—what’s left to figure out should be fairly manageable, executional design challenges. Then it's up to you to pick a place to start, and which challenge to tackle first.

When picking a place to start, you might consider:

• What are the key moments of the experience? Where do you have the most opportunity to use design to take the experience from good to great?
• What has the most open questions or dependencies surrounding it? Are there parts of the product that are particularly hard for you and your team to imagine? Are there design needs currently blocking engineers from making progress?
• What will make the rest of the project easier? Are there things you can work on first, to make the execution phase easier and feel more like “going down a hill”? (eg design work that lays a foundation for the rest of the product or feature, and/or has components that will be heavily reused)

There isn't a right or wrong answer here, and you as the product designer on your team should feel empowered to pick the place to start—and to determine the sequence of work overall—that will best set you, your team, and your project up for success.

Alright. Let's work our way up this hill.

📝 Technique #1: Your DRD

This is your recipe. Think of your DRD (design requirements document) as the PRD (product requirements documents), but translated into your own words, as a designer. What is your understanding of the product or feature you are about to design?

(To be clear, “DRD” is just what I'm calling it. The concept of a DRD is not actually a thing in our industry, as far as I know. But for our purposes, it's helpful to give it a name.)

When I receive a PRD, I'll start a new document of my own, review the PRD line-by-line, and parse the information into these buckets:

1. Scope
   • In a PRD, this might look like features articulated in the form of user stories. There might also be other context in the PRD that implies scope not explicitly articulated in the user stories.
   • I will make a bulleted list of all the discrete features I am able to infer from the PRD, minus all the “as a user...” verbiage.
   • For example, for a commenting feature, that might look like: comment on document, edit comment, delete comment, assign to teammate, set reminder, etc. This is simply easier to scan in a list, and the PRD already captures the “as a user...” stuff.
   • I'll also create a separate “out of scope” section, using this same exercise.
2. Assumptions
   • Any scope I've inferred from the PRD, I'll also state in my assumptions list, along with any context about those inferences.
   • I'll also include any assumptions that feel important to say out loud and validate with my team.
   • Beyond scope, this might include (but not limited to) assumptions about user needs and behaviors, how a feature will work, dependencies on other projects, and impact to other parts of the product.
3. Questions
   • This list of questions can easily turn into an exercise of rephrasing your assumptions as questions, which is honestly fine.
   • If it helps, I might focus this list on the most important questions you need answered to confidently proceed with your design work.
   • This might include practical questions like requesting more detailed acceptance criteria for a feature, but also high level questions about user needs and product strategy.
4. Use cases, examples, content
   • I often find there aren't clear and diverse enough examples of use cases in PRDs, so this is a good section to help tease that out.
   • This is where I'll ask more specifically about real life examples of user goals, triggers, and scenarios—and try to get a sense for the extremes.
   • Using our commenting feature example, that might include things like: When does a user leave a comment? Or tag someone? Or set a reminder? Why? What does the range of use cases look like?
5. Design considerations
   • You might refer to this as our design strategy. Thinking of the user's current challenges, how does the experience need to change in how it works, looks, and feels to address those challenges?
   • Using our commenting feature example again, this might include things like: make it easy to track assigned comments, and contextualize comments in the document.
   • While the user may have these features available to them today, the experience of using them is particularly difficult, and we want to bring these goals to the forefront as we work through design.

In the context of the first 48-hr cycle of a project, I'll typically do some version of this exercise in the first hour or two of the cycle, and send it off to the client as soon as it's ready. It's a quick, low-fidelity way to get aligned on product and design direction, very early. The client will often let me know where my gaps are and where I've missed the mark, before I've spent any time at all on visuals.

You might say: “But if I already have a PRD, what's the point of a DRD?”

The challenge with PRDs: they are written with multiple audiences and purposes in mind. Doing this exercise helps you translate that information for the express purpose of design work: getting clear on what's needed from a design perspective, and honing in on your needs as the product designer—your gaps and questions—so you can get the answers and alignment you need to proceed confidently with your work.

Don’t have a PRD? Take what you do know, write it down, extrapolate, and share it with your team for feedback. Get comfortable making assumptions. This is okay to do, when it is in service of creating definition with your team in the early stages of a project. It is much easier for people to react to and pick apart assumptions and statements that sound like decisions, compared to a list of questions. Draw a line in the sand, articulate your opinions and assumptions, share it, and have others tear it apart—this is a good thing.

🔪 Technique #2: Breadboards

This is your mise, ie all your ingredients gathered and prepped, before you get cooking. You’ll use breadboards to rapidly outline all the screens you think you’ll need, and the content and actions for each—independent of any visual concerns like layout, hierarchy, etc—also borrowed from the book Shape Up:

First, I'll refer to scope in my DRD, and create a quick bulleted list of all the screens I think I'll need.

Then, I'll review the list of screens and pick a place to start, keeping in mind the considerations we discussed earlier: Where are the key moments? Where are the most open questions and dependencies? Where might we start first to make the rest of the project easier?

Once I have a sense of priorities for my screens, I'll start mapping out my breadboards, which consist of 4 components:

• Moments: This is your list of screens, and what the user sees moment-to-moment in the experience. I prefer the term “moment” because it's more descriptive of the discrete moments in time we want to capture in our breadboards.
• See / content: This is the list of content and information that the user sees during each moment.
• Do / actions: This is the list of actions the user can take during each moment.
• Connections: These are the connective lines that move the user from one moment to the next, via actions the user performs.

You'll notice that we're not worrying about layout or visuals at all here. Breadboarding is a super low-fidelity IXD (interaction design) technique that allows you to focus on content and functionality, without the distraction of visual concerns. This separation of concerns and low-fidelity approach will allow you to work both more quickly and more thoughtfully through IXD-specific issues. Speed and high-quality thinking, together—that is the goal here.

Do I breadboard every screen? No. I’ll typically focus on the screens that feel most important to the experience, and where I feel the most unsure about how things will work.

Do I use breadboards for every project? No. I don’t follow a set process, and I use breadboards like any other tool: use the right one for the job in front of you. That said, I do use breadboards often, especially for 0→1 products or large features.

In a 48-hr cycle, I’ll start breadboards right after I send my DRD to the client, in those first few hours of the cycle. I think of breadboards as my first design iteration. I will very quickly move into wireframes once I feel confident about the moment-to-moment experience, I have a clear picture of what the user can see and do when, and any hard interaction design problems feel mostly solved, or feel solvable in wireframes.

🥘 Technique #3: “Solved Enough” Wireframes

This is your first pass at cooking the recipe. You’ll use low-fidelity, pen-to-paper wireframes to establish a safe and “solved enough” baseline experience, end-to-end.

Why safe and “solved enough”? Because you shouldn't be worried about getting it all 100% right in your first pass. Let go of your perfectionism. Accept that your first attempt will never be your best one. Be okay with sharing things while they're rough and unfinished.

Don't want to reinvent the wheel? Then don't, at least not this pass. Copy from other products, shamelessly. See a UI pattern in the wild that basically does what you need it to? Steal it. Remember: "solved enough." You can change it later. Mockups are fast, cheap, and malleable.

This first pass is still partially about getting to the “top of the hill.” You want to paint the experience end-to-end, in broad strokes (think white boxes with words in them), so you can then step back from the canvas and really see all the design work to do, and strategize:

• What parts of the experience in front of you need the most design love?
• What ended up being more complex than you expected? Why?
• What do you most critically need from your collaborators to confidently push forward?

I read once that user experience starts, where usability ends. What you're doing here is creating a solid, usable, end-to-end foundation—so you can spend the larger portion of your time in the design phase making the user experience the best it can be.

I promise you, once you have this foundation of “solved enough” wireframes, you will feel much more freedom to run with the design and focus on the fun stuff. Having a baseline solution end-to-end means: if you explore something new, and it doesn't work out, you have a fallback. The fallback is unsexy and boring, but it's supposed to be.

If you've reached this point and followed the techniques, you'll find that you've already done the hardest parts of the project:

• With your DRD, you've articulated scope and design considerations in one place—you don't have to hunt these details down. If your team has anything to add, they can, because you've shared the document with them.
• With your breadboards, you've already done the core interaction design work. You have a clear picture of what the user can see and do, when, in one place. You don't have to hunt down missing screens, content, or functionality.

You have all your ingredients collected and prepped, and you can truly focus on designing, with minimal context switching.

Now, just pick a place to start. (Here are those considerations again: Where are the key moments? Where are the most open questions and dependencies? Where might we start first to make the rest of the project easier?)

The last thing I'll point out here: You can get through all these steps and techniques, without waiting for permission or more information than what you started with.

2 quick reminders:

1. Get comfortable making assumptions. Draw lines in the sand, articulate your opinions and assumptions for your team to react to, and let them tear it apart. This will create clarity and alignment, faster than waiting to be handed answers or information from others.
2. Stop being precious with your mockups. Stop thinking of mockups as the endgame or final outcome, and more as a tool to facilitate better conversations and create definition around the project with your team.