The Downside of How Geeks Describe the World

"Start with Why" is widely espoused as the ultimate stake-in-the-ground for designing any solution or any change. Who can argue with this? It's a great place to start.

Describing why leads to describing what is needed and for whom. Ultimately, describing what leads to describing how it will be designed. Why leads to What, Who and How.

Starting this discovery conversation quickly leads to a predictable set of statements that are helpful in describing what is ultimately motivating the change and for whom:

• We need [some notion of a solution described here] so that we [experience a benefit described here]
• I want [some notion of a solution described here] so that I [experience a benefit described here]​

Nestled in each of these statements is a description of the motivation for the envisioned change or needed solution. The envisioned end result exists to bring about some desired future state.

Captain Obvious stuff, for sure. However, my guidance is directed at the more fledgling officers who so easily and routinely fall into the following easily avoidable pitfall.

---

Beware: The Pitfall of Using Solution Language

How this works out practically is easily described by way of example.

Consider the following statements:

1. We need a new iPhone app so that we engage our mobile market better.
   
   
2. We need a way of interacting with our potential and existing customers so that we have the opportunity to be connected with them anywhere at any time.

When motivation statements are framed in design elements (e.g., iPhone, mobile, buttons) the solution design effort risks veering into a pitfall because describing "how" is not the same as understanding "why".

Now, consider the following cross-checking questions as it pertains to these statements:

• Which statement is more durable?
• Which would be just as valid ten years from now as it is today?
• Which one assumes a solution?
• Which one has a clearer statement of benefit?

Now, imagine you are a solutions designer trying to solve for one statement or the other.

Exactly.

A designer's choices are severely limited by statement #1 whereas statement #2 leads to further exploration in discovering important notions that drive design clarity:

• Who are the people in the market?
• What are some representative personas we can create so that we can design for them?
• What would the ideal solution look like for each of those personas?​

---

Understanding "Why" Matters More Than Describing "How"

When motivation statements are framed in design elements (e.g., iPhone, mobile, buttons) the solution design effort risks veering into a pitfall because describing "how" is not the same as understanding "why". 
​
Describing "how the solution is to be built" in the early stages of learning and discovery disrespects two critically important voices in the solution conversation;

• Users
• Solution Designers

Don't disrespect users and solution designers by leading them by their respective noses to your envisioned solutions.

Users want solutions that cater to them. If you bring them a solution that does not respect who they are, it will not resonate with them and will ultimately not be a viable solution to their problem.

Solution designers want a clear description regarding the problem, who it affects and what the envisioned benefits of the ideal solution entail. Thy need this so that they can define a solution with respect for who it is for and how it affects them. If you bring them a solution statement, you have disrespected their opinion.

Don't disrespect users and solution designers by leading them by the nose to your envisioned solutions.

- Chuck

Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic, but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity.

I hope you'll join us.

Free Updates by Email