Consulting 101: The Missing Design Phase
Quick note: For the purposes of this article, Balanced Team refers to a product team made up of Engineers, Product Managers, and Designers. For more on Balanced Teams, check out Pam Dineva’s awesome article Why Balanced Teams Work Better Together.
Problem: The client wants to start coding, but they haven’t done user research. They may have a PRD (Product Requirements Document), but the requirements are vague.
Solution: Talk to the real users of the product to validate assumptions and reduce risk to the client before launch. Involve every member of the team to build empathy for the user and buy-in for the product.
Many projects, big and small, follow a similar process.
For valid reasons like budget, allocation, and other deadlines, an eager client may want to jump right into development.
While it might seem like a good idea to save time and money by skipping the design phase, especially when the client has already done the work to gather requirements, “execution” (i.e. developing your product) can feel less like a thrill ride and more like a sentence down the road. The worst part is, you might not even know you’re on the wrong path until you launch!
Consider an alternative: form a small team of complementary disciplines (Product, Design, and Engineering) and allow them to validate assumptions about the product idea, building empathy and understanding as they go. By the end of the design phase, everyone on the team will have a personal understanding of the challenges faced by the users, making it easier to make decisions in the future. If in the process they confirm the requirements you selected, great! But chances are… they won’t.
So, what can you do?
If you’re a consultant…
Do:
- Ask about user research
- Question assumptions
- Test their ideas with users to establish a baseline
- Start small. If certain features of the core experience seem less risky, start there.
- Show, don’t tell, the value of a Balanced Team
- Encourage the client to be involved in the design process
Don’t:
- Take the requirements at face value and blindly start building
- Promise to deliver specific features by a certain deadline
If you’re a client…
Do:
- Get the right people in the room who know the history of the project and can make product decisions.
- Keep an open mind and support the team. They may discover a different solution is actually a better fit for the user and ultimately, your business.
Don’t:
- Accept unvalidated product requirements handed down from other departments unfamiliar with the constraints.
- Assume you can learn what you need from data after the product launches
- Put pressure on the team to “build faster”
—
Have you faced the challenge of managing vague requirements as a client or consultant? How did you deal with it? Leave your comments below!
