When you write a brief for a project, think about how you word it. Titles matter. You might know how to fix the issue, but do not mix up the solution in your head with the problem. They are not the same thing.
What is a solution?
“We need a modal to show people how to make tomato soup all in one pan.”
…vs. identifying a problem?
“We need to make it more obvious how to make our tomato soup in one pan because we’ve heard several complaints that our soup recipe creates too many dishes.”
We don’t necessarily need to make a modal to solve the problem. Do you see the difference?
Why does it matter?
It matters for a few reasons.
When you come at a problem with pre-baked solutions, you are less likely to be open to trying different approaches. Designers and engineers both get easily locked into a solution before exploring other options.
Depending on who you are talking to, they may take your “idea” as a “directive” rather than an idea. Especially if you are in a position of power.
You cut off creativity and miss out on collaboration.
It’s human nature not to want to discard hi-fi work (or something we’ve already started coding) even if it’s not the best solution.
Rushing into solutions can lead to wasted time refining high-fidelity designs or code, only to start over when we realize that the solution won’t work or better ideas surface. Staying in problem-solving mode longer saves development and design time.
I have an idea to solve it, though. Can I propose it?
Of course, we are all encouraged to propose solutions. I’m suggesting a shift in mindset and approach, which includes the following:
Shift your wording instead of
We need a modal to show people how to make tomato soup all in one pan.
...try
We need to make it more obvious how to make our tomato soup in one pan because we’ve heard several complaints that our soup recipe creates too many dishes. One idea is a model that pops up as soon as you see the recipe.
Always start with the problem we are trying to solve and frame your idea as “one idea is…”
Stay open to other ideas.
Giving great design feedback (as a non-designer)
The same rule applies here: first, identify the problem you are trying to solve.
Sound feedback:
The instructions to make the soup all in one pan doesn’t seem prominent enough. I had trouble finding them. The one-pan soup recipe is a significant revenue driver, so we must make that front and center. How might we make it more prominent? Maybe a modal that pops up?
Not as good:
Can we move the soup recipe into a modal that pops up as soon as you hit the page so users see it?
Sound feedback:
Option 2 is more successful because I immediately saw the callout box, clearly showing soup can be made in one pan.
Not as good:
I like Option 2.
Why does it matter?
If you don’t give a solid reason why you like a particular option, we may lose that part you thought was successful in future iterations. Example: A new design happens iteration on Option 2, and the callout box is now very subtle and not easily seen or gone!
To create an environment of free-flowing problem-solving, it’s best to change our mindsets on both ends: the person giving feedback and the person receiving it. This way, both parties are open to full collaboration and don’t get stuck in the proposed solution. It focuses on the problem we are trying to solve for our customers.