The interactive feature in the July, 2014 issue of HOW Magazine is an article I wrote about the the relationship between expertise and experimentation. It’s called Digital Expertise is Experimentation…
When was the last time you said “I don’t know” in a meeting?
Better yet, when was the last time you said it confidently, knowing that this admission was in no way in conflict with your expertise?
Probably never.
In our culture, these are words rarely spoken — especially not in the conference room. And especially not in the midst of interactive projects. Few words are more costly to one’s confidence or prestige than these. They go unsaid because of fear. We are afraid to admit that there are things we don’t know. We are afraid that admitting we don’t know something will undermine the confidence we’ve earned from our clients and colleagues. We are afraid that the expectation we’re projecting on them is true, that they’d be right in rejecting us because we should have known that thing we didn’t know. We’re afraid they’ll expose us and then everyone will know that we don’t know things.
But you can’t know everything, can you? The longer you work — no matter what you do — the more you learn about some very particular things and the more you learn that there are far more other things you don’t know. That is the truth about expertise in the digital age: It’s very small. For designers, there are few words more simple and honest than “I don’t know.” We should say them often and feel good about it.
I want to offer you a way to embrace that ethos in the midst of the most complex interactive projects. The key to doing that is experimentation. That may sound crazy, but I’ll share with you two particular methods that I guarantee will enable you to do your best, most informed work. But first, we need to better understand the relationship between expertise and experimentation.
The Bipolar Designer
Expertise has nothing to do with knowing everything. The sooner we accept that, the better fit we will be to do our work. Which is, of course, design.
Design is at once enormously broad and intensively specific. A designer must continually zoom in and out, capturing the big picture while also grasping the smallest details. Interactive design — with all its variables, complications, integrations, and algorithms — makes this experience even more extreme. Interactive designers sit in the eye of an information storm that churns around us far too quickly to be fully understood by any one person alone. When you don’t know 90% of what you must work with, something interesting about your identity is exposed: You are bipolar.
The biggest scandal in our industry is that we designers are bipolar. We’re 50% unjustified confidence and 50% unjustified fear.
But the scandal isn’t really the ratio, per se. The scandal is that we pretend this isn’t true. We hide it. We deny it. Why? Because of that fear problem we have. We’re afraid of losing our place at the table. We’ve got executives, marketers, project managers, engineers and plenty of other intimidating people staring us down and waiting for answers. So we smile and casually say, “I got this” while inside, we’re virtually paralyzed. Bluffing works every once in a while, but it’s a lousy way to live. It’s too stressful!
This fear cycle we are caught up in must be broken. We’ve got to find some way of balancing our reality — of keeping the meter steady between our bravado and our terror. The only way to do that is to start thinking of design a bit differently. Design itself, after all, has a bipolarity of its own.
The Reality of Design
Good design is the result of 50% expertise and 50% experimentation. In this arrangement, by “expertise,” I mean that refined skill and knowledge that you bring to the table — the stuff you know you know and you know you will use. But the experimentation is the important part. It’s comprised of the questions you know you will ask and the methods you might follow to answer them. We now know it’s OK to not know things, but it’s not OK to not know how to get answers to the things you need to know. The methodology will vary, of course, and just what method you use may be unclear in very early stages. Hence all the “I don’t knows” you’ll need to say. You can always add “…yet” if it will make you feel better.
Now, this all sounds very well and good. It’s neat and tidy and theoretical. The problem is that nobody really accepts experimentation! (That is, unless it’s part of some corporate coolness doctrine, like Google’s 20% experimentation allowance — which they’ve abandoned, by the way.) When it comes to real, deliverable-based, working relationships — the kind that bring people like us to those intimidating conference rooms — experimentation is practically anathema. For a designer, this is terribly frustrating. We need to be able to experiment!
There is, after all, a professional spectrum along which expertise and experimentation lie. The variable that moves along this spectrum is the problem you are working to solve. As the problem grows in severity, the necessity of experimentation increases. Simple, right? Law knows this. Science knows this. Medicine knows this. In those areas, if you have a minor problem, like a small claim or the common cold, you’re going to get a rather boxed solution. This is entirely appropriate. But if you bring a truly severe problem to their office, the first thing out of a doctor or lawyer’s mouth will always be, “We can try this…” But marketers? Forget it! They typically recoil in horror at the word “try.” But designers work with marketers. And interactive design blurs the distinction between design and marketing even more. To be honest, we are marketers, too.
So our job is to work experimentation back into the professional vocabulary. Experimentation and confidence are not mutually exclusive, of course, so we can be honest when we’re trying something. If you say “try” with even the slightest apprehension (fear can be smelled, I tell you, smelled!), don’t expect to be given the chance. But if you do so confidently, you will.
Well, theoretically. I didn’t say our job would be easy.
We’ve now put our own fear into proper perspective, but to be fair, experimentation — no matter how professional it is nor how stably executed — is prone to introduce a new fear we must grapple with: our client’s. But their actual fear, not those fears of ours that we otherwise project on to them. Our client’s fear is often uncommunicated, but subtly shapes the tenor of our communication with them and the decisions they make along the way. It is composed of lingering doubts and questions that they sense but don’t know how to express. But if we can anticipate these doubts and questions, draw them out proactively, and answer them, we will build a strong trust with our clients and create a much better solution for them. All while preserving the professional integrity of experimentation for ourselves and demonstrating to our clients that it is indeed a good thing.
This is experimentation that looks — to the observer — like the expertise they expected.
How to Experiment Like a Digital Expert
“Experimentation that looks like expertise.” That sounds like an oxymoron, doesn’t it? But, so far, I’ve built a case for experimentation as an integral component of expertise. If design is 50% expertise and 50% experimentation, that means we can’t have one without the other. All experts experiment… expertly. Try saying that three times, fast.
Here are two methods of interactive experimentation that, if done well, will not only feel like the expertise your clients expected when they hired you, but will be the stuff they value most in their engagement with you.
1. Discovery
It’s not uncommon for your client to hire you without having done much preparation. Many of the questions you will need to ask them will not have been considered, and ready answers will not be available. This is why it’s almost irresponsible for designers to not build in time to work through those details. A good agenda for an interactive discovery phase should include:
Mission: Your client needs an official statement of purpose. Who are they? What are they trying to do? For whom? How will this be accomplished? Generalizations are OK at this stage; they’ll get fine-tuned in due time. The important thing is that documenting it forces everyone to think through it intentionally and provides an accountability tool for the entire team.
Strategy: Put yourself at the center of a strong team of differentiated experts within your client’s organization. Their input will be indispensable. Starting with the business objectives outlined in your mission document, moderate a group discussion about how to meet these objectives. Identify the audience and develop a content strategy that addresses their needs. Map out the entire marketing ecosystem, which establishes the site you’re designing as a platform on which integrations with inventories, contacts databases, and marketing automation suites can be supported. Remember, websites don’t just display information; they gather and process it too. Then, get an opinion on how long the work might take and estimate costs. Write all of this down, too.
Scope: Once the strategic objectives and a possible plan of attack have been worked through, you can narrow in on a detailed assessment of the scope of work for an initial phase (from start to launch) as well as a more generalized idea of a potential phase two (post-launch). Scoping is not about producing an exhaustive functional spec — with bulleted lists of functionality and pages — but to identify and prioritize key functional objectives in light of constraints like personnel, budget, and timing. Scoping tends to force revisions to earlier estimates, which is a good thing. It’s why you do it — to get closer and closer to reality. Make note of what’s changed and use your documentation to guide your client through the decisions that need to be made in order to move forward. It’s your role to help them use their time and money most effectively.
Perhaps you’re thinking this just sounds like talking, not experimentation. If so, you’re right; it’s mostly discussion. But neither you nor your client really know exactly what will come of it. That’s why it’s called “discovery.” What is experimentation if not a method of discovery?
Taking this approach gives your client the opportunity to discover truths about their business and customers that they hadn’t considered before. These epiphanies point everyone in the right direction. Without them, there is no plan nor protection for you from some of the common pitfalls of interactive projects, like indecision-driven delays or scope creep.
Oh, and remember: You are leading them through this, which is why you can confidently charge for it. After all, talking about work is work.
2. Usability Testing
Usability testing is essential. It’s not a discrete thing we do sometimes; it’s an integrated discipline. It’s as essential to our practice as Photoshop, or even pencil and paper! And yet, few of us ever do it. Why?
Many people hear “usability testing” and envision labs, expensive equipment, and trained technicians. And, while it could be like that, it doesn’t need to be. In fact, the more complicated you make it, the less likely you are to do it. Complicated is too time consuming, and too expensive. You need a simpler, faster way.
All you need is a quiet space, a computer running screen-capture software, a volunteer, and a moderator (that’s you). The key component, though, is a task-based test plan designed to evaluate whether users are able to recognize, understand, and do things that are central to the strategic purposes of the site. That’s it. If you do usability testing in person — avoiding remote testing services — and often — after discovery, during design and prototyping, after building, after launch, and periodically ongoing — you’ll never stop learning things that will make your design stronger.
The Best Expertise We Have to Offer
Contrary to popular belief, the best expertise we have to offer is not a solution or craft. It’s the wisdom of asking the right questions and the journey we take in answering them. Discovery phases are simply a stable container for experimentation that can properly align any project and team, while usability testing is a disciplined, but experimental, methodology that can be interspersed throughout any project. Together, they make for a reliable and valuable journey.