How I turn chaos into product vision (and detailed requirements).
By the time I was 15, I had lived in a dozen different places across 4 different states.
We moved house so much that packing and unpacking was nearly part of my daily grind.
Moving so often meant I had a dozen chances to create an entirely new world out of the contents of a pile of cardboard boxes.
As a design consultant now, every time I join a new project team I feel that same excitement about “the new house.” The funny thing is, I often come in to find my client staring at a figurative pile of boxes with no idea where to start.
Someone labelled half of the boxes “closet” without saying which closet. The movers put all the boxes into one room, burying the coffee maker somewhere in the back of the mass. Where do we start?
1) Get everyone’s ideas in one document.
This is kin to opening the moving boxes and peeking at what’s inside — but not unpacking anything just yet.
Make a note of everyone’s wish list so everyone feels heard and included.
Ideally, you’ve done user interviews during discovery so you’ll have your user’s needs in your document.
2) Prioritize the big ideas.
Once the boxes are open, make a smaller pile of the stuff you will use every day. Laptop charger. Coffee maker. Towels. Check!
Ideally every roadmap or feature prioritization would be based on data-driven user insights and detailed development requirements. But most developers won’t estimate how much work something is without seeing a design. And most users don’t know what they want (or don’t want) until they see it.
Take your best guess at which big ideas are most important. Trust your team to make an educated guess — just as long as you have someone representing the user, the business and the product team.
Sometimes I even do this exercise on my own and then show it to the client. It’s funny how quickly a client goes from “I don’t know.” to “Definitely not that.” when you draw a line around which ideas are in the MVP. Whether the client exactly agrees with my prioritization doesn’t matter. What matters is bringing focus and consensus to the overall vision and scope of the project.
Don’t get too detailed in this phase! Analysis paralysis is super boring. Plus, this early in the project it’s too soon for lots of details.
3) Design something.
This is going to be controversial, but I swear it works. If your client really doesn’t have any idea what they want, what the project requirements or even where to start — just start designing something based on your top 3 priorities.
The “something” you’re designing, isn’t supposed to be the final product. At this point the design is only about bringing focus and consensus to the overall vision of the project.
This is like when you’re moving and and put paper blinds on the bathroom window. It’s not the final vision. But it’s quick. It’s cheap. And nobody sees you naked anymore.
4) Get feedback (aka, requirements).
Most of your project stakeholders are not designers. So why would we ask them to provide design detailed requirements (which make them visualize a product in detail) before we even start sketching ideas?
It’s crazy.
Clients often need to see a few ideas sketched out before they can imagine what they do or don’t want in their product.
Using design sketches to gather early requirements moves the conversation from “what do we do?!” to “if we did or didn’t do this specific thing, how would that go?”
The same is true of users. Asking your users to design something out of thin air in a workshop session can be fun, but most users don’t know what they want until they see it. We all know the adage about how most users would design “a faster horse” because they can’t imagine an automobile.
So I like to let designers take the first crack at doing the work and then getting feedback. The combination of client feedback and user feedback on early sketches becomes your first draft of project requirements.
5) Vanquish chaos. Savor your vision.
Now you have a pretty good idea of where to start your design. Reference the sketches, feedback and draft requirements to keep design ideas flowing in the right direction. Because the team has visual artifacts as a reference it’s easier to keep the team focused toward a vision that feels more tangible to everyone.