Are we on the same page?

Have you ever had a vision that seemed so abundantly clear that it didn’t even cross your mind that someone else wouldn’t see it the same way?

My vision is…

I explain it as…

  • I want something with a lot of character—you know, the kind you see in older homes.
  • It should be cozy. I love wood burning fireplaces and front porches.
  • I picture earthy colors.
  • Nothing boring; it has to have an interesting roof line and maybe some type of bonus room.

Someone else envisions…

Translating a picture in my head into a picture in yours is a surprisingly difficult task.

Most often, product visions are delivered verbally using bulleted lists of goals or outcomes; it’s left to each listener to visualize the end state and how to get there, and this is where things get hairy. Like Craftsman, Cottage, Victorian-style hairy.

The differences in these visualizations will increase your cost, time, and effort, and decrease the likelihood of your project ever getting accomplished the way you envisioned. It’s kind of like putting the pieces back into the operation game without being able to see the patient. You may end up with spare ribs in the bread basket (an unwanted and costly mistake).

“The very essence of leadership is [that] you have a vision. It’s got to be a vision you articulate clearly and forcefully on every occasion. You can’t blow an uncertain trumpet.” —Theodore Hesburgh

 

For a more technical example, let’s look at this simple vision statement:

“Our customers need to securely share monthly financial results with their trusted partners.”

It seems clear. Your technical experts could immediately start writing user stories and code to satisfy that vision. They will all think they understand the end goal, so they’ll create stories like, “As a customer I need to securely send my monthly profit and loss (P&L) to my accountant.” But what does that mean in pixels? How does the development team picture the final product?

Are they building a system that works like secure email? (I send you a file with results.)

Are they building a system that works like Box? (I put a file somewhere and give you access.)

Are they building a system that works like Google Docs? (I create a file and invite you to view or edit.)

The big, absent, and extremely important step between the vision and the user stories is the creation of the design model; how should the customer picture, in their mind’s eye, this system working?

The important step between the vision and the user stories is the creation of the design model.

What is a design model?

Donald Norman and Bruce “Tog” Tognazzini both have lengthy explanations on design models. But, since you are here, I’ll give you the CliffsNotes version.

Norman’s illustration of the model looks something like this:

The design model is how we want users to understand how the system works. Often times, we create a metaphor, like email, to make concepts easier to grasp.

E.g. “I think it should work like email because I heard users say they ‘send’ the P&L to their accountant.”

The system image is how designers communicate their model to the users.

E.g. “Once generated, a single copy of the monthly P&L report is stored on the server but pointers to that common report appear in each user’s directory giving them the appearance of each having a copy.”

The “customer picture,” otherwise referred to as the user model*, is how users think the system actually works.

E.g. “I send my P&L to the accountant every month, but I have a copy of it in the system.”

How do I avoid multiple visions in my organization?

Often times, the first challenge is clarifying and unifying leadership’s vision. It’s a mathematical nightmare to think about how many different ‘pictures’ could be in your organization if there are five different visions from leadership.

Write things down.

This may sound silly, but how many times have you verbally agreed to something in a meeting, only to hear five variations the very next day?

Get consensus. Write it down. Then get consensus again.

Use more pictures.

Seriously. This is where it becomes clear that somebody is thinking Craftsman, someone else is thinking Cottage, and someone else is thinking Victorian.

Your builder [architect] needs you to agree before he can pour [create] the foundation.

Make it concrete.

You want it to be the exact opposite of an abstract painting—don’t leave things to a person’s imagination or interpretation.

Get buy-in from your technical team.

Engineers need to understand experience goals, not just user stories, to make the best decisions for your product. When they are brought into the fold early, they can assess technical feasibility and provide insight on challenging (and expensive) asks.

They’ll also feel empowered and inspired to overcome these challenges if they take ownership in the vision.

Trust us, it’s worth the time.

Engineers need to understand experience goals, not just user stories, to make the best decisions for your product.

Keep a united front.

There’s nothing worse than agreeing on a vision and getting the company to rally behind it, only to have one person derail the vision six months later. It’s more than a loss of work—you’ll also lose momentum, buy-in, and trust from your staff.

“Dissatisfaction and discouragement are not caused by the absence of things but the absence of vision.” —Anonymous

One last reminder:

Everyone on your team could be satisfying your original vision statement in their own way. They think they get it. Don’t take their word for it—tell them and show them. Articulate your vision in way that speaks to all thinkers.

Articulate your vision in way that speaks to all thinkers.

If you don’t, you risk building a product with multiple design models. This will end badly, with users struggling to understand your system, and maybe so frustrated they leave it all together.