Understanding clients and their project requirements is one of the most exciting and challenging parts of my work. Last year, I published what I still think is one of the best posts on this blog, “Trust is a Must: Thoughts on Successful Project Collaboration”. In that post, I discussed the importance of clients and consultants engaging each other on their areas of expertise.

The “Trust” post was inspired by a great talk at InfoCamp Seattle 2011, and, one year later, I found myself thinking about similar issues following InfoCamp 2012. The plenary talk for this year’s conference was by Dan Klyn. He presented ideas I’d thought about before in a way that was so clear and straightforward that I just had to share them.

Need => Solution => Product

Much of Klyn’s work is based on the writing and thinking of Richard Saul Wurman, an architect who helped start the field of “information architecture.” In his talk, Klyn shared this quote that caught my attention:

A common obstacle to understanding and communicating our needs, and to realizing solutions to them, is our habit of asking for a specific product we have used or seen (even if it has been a failure) rather than analyzing our need. ((This quote, with citation, and the others can all be found in Klyn’s slideshow: http://danklyn.com/infocamp2012.pdf.))

In the context of what I do, a “need” is the reason a client has for building a website and a “product” is the graphical element, layout, or site feature that best addresses that need. In reality, each website has to address multiple needs with complementary products. To summarize, the product is the solution to the need.

When working with clients, I frequently find one or both of us skips to identifying products before sufficiently assessing—or assessing at all—the needs and goals that the project is intended to solve. ((I think this happens for a variety of reasons. One particular culprit is the Request for Proposals (RFP). This process can mistakenly encourage clients to define the products they need without the involvement of any people with web expertise.)) Overall, I think this is a common problem in the website-building industry.

An Example: “Mobility, not highways.”

Wurman was kind enough to create a fable that illustrates this idea. The fable is set in a town. The town has many needs, but they are unable to satisfactorily meet them because they only use products that they already know. Wurman’s solution: state their needs to find a solution.

The issue was learning, not schools.

The issue was safety, not the number of police.

Mobility, not highways.

…

And recreation, not parks.

Make more sense? The town’s ideal mobility solution might be rail-based, ((I live in Seattle where this particular example is also my opinion.)) but if highways are the only product you know that solves the need for mobility, it’s easy to short-sightedly build more of them. If we jump to solving our problems in ways we already understand we may be, to use another metaphor, trying to jam a square website in a round tube (which as we all know is the basic structure of the internet).

A Couple Examples

On Web Projects

One common request for websites is to have a big slideshow at the top of the front page. ((This example is also borrowed from Klyn’s presentation, during which he quipped, “If I asked you to put a slideshow at the top of a company’s homepage or stab your eye with a pencil, we’d be out of pencils.)) Can you recognize the problem? The client is asking for a product without identifying a need. If you’ve read my blog before, you may know that I think slideshows are not appropriate for most situations, but they are appropriate for some websites. The problem with slideshows is not the underlying technology ((Though, as I’ve mentioned before, there are a lot of horribly implemented sliders that are almost entirely inaccessible.)) but that people use them regardless of whether they address a need.

Moving forward, I hope to refocus myself so that each project begins by exclusively identifying the needs of the client. To continue the slideshow example, does this website have lots of visually-interesting content to showcase? Does it need to tell a story with photos and text to new visitors? Those are great reasons to use a slideshow. But if the slideshow is only used because it “looks cool” ((What is “cool”? happened to be the topic of another great InfoCamp presentation by Aaron Louie.)) and is familiar, that’s a problem.

With Troubleshooting and Support

This abbreviated script is everyone’s favorite stupid tech support question:

Caller: "Hi. I think my power button is broken."
Tech Support: "I'm sorry to hear that. Why do you think it's broken?"
Caller: "When I press it, my computer doesn't turn on."
Tech Support: "Is your computer plugged in?"
Caller: "No…"

This type of miscommunication is called the “XY Problem.” Here’s one formulation:

You’re trying to do X, and you thought of solution Y. So you’re asking about solution Y, without even mentioning X. The problem is, there might be a better solution, but we can’t know that unless you describe what X is.

The caller asked about Y (the power button) when the problem was X (the computer wasn’t plugged in). This stark example might seem pretty off-topic in a discussion about making websites, but the type of miscommunication is the same. It happens when one or both parties get ahead of themselves while assessing a situation. Even worse, the chance of realizing this as quickly as Ms. Support above is near zero and the stakes are often much higher.

It’s About Working Together

Just like describing the root symptoms of a computer problem, defining the needs and goals of your organization in a website project will save time, reduce frustration, and vastly improve the project’s result. As I wrap this up, I want to take one more step back to get a bird’s-eye view of collaboration and how discussing needs can lead to better results.

When I’ve found myself in a discussion debating the merits of two mutually-exclusive products—”I WANT A RED BUTTON!” “I WANT A MAROON BUTTON!”—I try to recognize it as a case of “positional bargaining.” ((This is the opposite of “mutual gains bargaining,” both of which I encountered during mediation training and conflict resolution courses in college.)) When arguing over positions—red vs. maroon, sliders vs. videos, highways vs. trains—people get more attached to their position rather than the problem that everyone in the room wants to solve together.

Collaboration can’t be successful without identifying the problem, need, or goal being addressed. That doesn’t guarantee that collaborators will immediately agree on how to solve the problem, but having that debate in terms of the agreed-upon needs makes the discussion less contentious and the solution more successful.

Talk Back

Does this ring true? What are your examples of people talking about “highways” instead of “mobility”? How do you flip the script for better projects and collaboration?