Designing without all the requirements

What it’s like to design in a fast-paced industry without a full set of project requirements

Intro

Each time we start a new project at 4C, our goal is to follow a thorough design process full of research, testing, and iteration. Ideally, that process looks something like this:

• Identify the problem you’re solving and break down the requirements
• Conduct preliminary market and user research
• Brainstorm and sketch out your high-level wireframes
• Validate your ideas with team members and customers
• Create a prototype and conduct usability tests
• Iterate on your design and plan for future improvements

Regardless of the project we’re working on, we always aim to incorporate customer feedback and several rounds of design iteration. Unfortunately, it’s not always possible to complete every step of the process. In this post, I’ll talk about one specific challenge of working in a fast-paced industry: designing without a full set of project requirements.

First, here’s what I mean by “requirements”

In an ideal world, a project’s requirements answer the following types of questions:

• What problems are we attempting to solve and why?
• Which customers are we designing for and what are their goals?
• Which problems are included in the scope of this project and which ones will we tackle later?
• Who’s working on the project and what is each person’s role?
• When are we aiming to have each step of the design process completed?
• How will we measure our success?

As a designer, I sleep well at night when I have answers to those questions. In our industry, though, you have to learn to live with a little insomnia.

A couple examples

Sometimes we just have to move fast

To help our customers reach their audiences at every touchpoint, our platform integrates with big social media sites like Facebook, Instagram, Snapchat, and Pinterest. We connect to a lot of other publishers as well, but we’ll talk more about that another time. Naturally, companies like Facebook and Snapchat make regular updates and improvements to their products. If we don’t move quickly when one of our partners updates their API, our connection to their platform can break, causing all sorts of trouble.

Similarly, when one of those companies releases a new product or feature, our clients often expect us to offer a compatible 4C integration. This doesn’t always leave us as much time as we’d like for research, design, and testing.

Sometimes the requirements don’t exist yet

R&D never sleeps at 4C. We’re always testing new products to help our clients stay ahead of the game. We also partner with the social media platforms on designing new functionality for their customers and giving 4C clients early access to some of their not-yet-released features. We’re conducting experiments in these cases, and most of the “requirements” are really just hypotheses about the value we’ll be providing our customers.

Strategies for designing without all the requirements

1. Talk to your team, a lot. It’s crucial for the product manager, developers, designers, and customers to all be on the same page. It’s okay if we don’t have all the answers yet, but we should all know what we collectively don’t know.
2. Ask a lot of questions. Whenever you realize you’re making an assumption in your design, highlight it and seek clarification. Mockups (especially the high-fidelity ones) have the tendency to become gospel pretty quickly. Make sure everyone understands which parts are still up in the air.
3. Experiment with different solutions. There’s usually more than one way to solve a problem, so don’t assume your first design is the best one. Even when you’re confident that Option A is best, people tend to provide better feedback when they can compare it to Options B and C.
4. Commit to iteration and the Minimum Viable Product (MVP). Especially when you’re designing something without a full set of requirements, assume there are always going to be ways to improve it. Design is never done, but that also means you need to feel comfortable releasing a beta product before it gets the final coat of paint.

All that said, some requirements are truly required

As designers, there are certain things we just won’t budge on. If you can’t answer the following questions, you’re probably in trouble:

• What problem are we solving and value are we adding?
• What’s included in the scope of the initial project?
• Who are all the team members working on the project? Who’s responsible for what?
• What’s the project timeline? For example, when does research and design need to be done for the developers to have enough time to write the code? (Note: answering “ASAP” to everything isn’t sustainable)

In summary

It’s easier to design good products when you have an instruction manual, but product designers are often responsible for working without one. Even when a project’s requirements aren’t fully defined, you can still make forward progress by talking to your team, asking good questions, and committing to iteration.

We’d love to hear about your experience working with (and without) project requirements. Please feel free to share success stories, struggles, or recommendations for our team in the comments section below!

Original images sourced from https://www.vecteezy.com/