ABSTRACT
Requirement identification/analysis interview, client/user interview, stakeholder meeting, requirement interview, insights research,… whatever it’s called and whichever part of the process it can be applied, some people (with whatever title) get to talk to stakeholders and/or clients, in order to understand their problems, needs, and wants. Here are seven tips I find to be quite useful when conducting those kind of interviews (or discussions, meetings, … whatever it’s called). Some may seem controversial — that’s exactly why discussions are great!
—
In the old days sales people, marketing persons, software engineers got to sit down with clients and/or stakeholders and asked about what their requirements are for their software projects. In some cases, rather abruptly, it got as bad as starting with “so, tell me about your requirements” or something semantically equivalent. The intention may be in good nature, but the results sometimes went astray.
The classic insight about the process of talking to stakeholders/clients to understand their problems is that, the clients either don’t always know what they want/need (“The User Is Not Like Me”?), or they don’t often know how to tell you, or, even worse, they keep telling you the wrong things and keep misleading you.
They’re not to blame. You probably ask the wrong questions and communicate in a less-revealing manner. You don’t really understand their problems correctly and fully. And, worst, you don’t realize that it’s your fault — whatever your title claims you are.
Here are 7 tips to right your wrong. I expect your comments, because “if you find yourself in agreement with everything… you haven’t been reading closely enough“[1].
#1. Encourage Constant Storytelling
ARTHUR: Okay, here’s planting an idea: I say to you, “Don’t think about elephants.” (SAITO nods) What are you thinking about?
SAITO: Elephants.
Asking“what’s the process/workflow of that task” is quite risky, because your clients could immediately get stuck in the very concept of “process” or “workflow” — they’re framed, and you almost can be very sure that what their interpretation of the concept is different from yours.
As a result, you don’t get them thinking in their usual way as in real work, they’re instead struggling with the framed concept of “workflow” and thus taking the descriptions out of their familiar usual context of actual working. It’s equally bad to ask something like “tell me about your requirements”.
Do NOT push any framed concepts. Instead, try to keep your clients in their own context, with plain language: “can you tell me how you do that?”
Let them introduce their going-ons in their terms, and the best way to do that is to encourage constant storytelling — just let them tell stories about whatever you’re up to understand. Stories are the key things you’d like to know or understand, combined with rich contexts of your clients’ scenario. Asking them to tell you those key things simply doesn’t work — they’re framed with abstract concepts and taken out of context. It’s always up to you to get those key insights or critical factors in the rich contexts of their stories.
One really interesting thing that happens during such storytelling is that the clients may describe lots of seemingly unrelated things and issues. When you try to make sense of all those things, you may find they’re not unrelated after all, and they usually reflect important insights about relations or structures about the clients’ current tasks or problems.
In one case I was talking to a client who wanted me to help improve their department’s internal workflow. I started by asking them to tell stories about how they do their work. (Not?) Surprisingly, they talked more about cross-departmental communication than about their internal how-to, and soon it turned out that their problem lies more in their company wide communication protocol than their internal department workflow. It could very difficult to know that when they’re framed to tell specially about their requirement of improving internal workflow.
In another case I was supposed to help analyze and identify UI issues in a client’s existing application which was used by their internal and outsourced staff. After I heard what the client representatives had to say, I went talking to their staff who actually were using the application. From all kinds of “usage” stories I encouraged them to tell, I realized that, although UI did have quite much space for improvement, the real pain in the ass for them was where manual work bridges with IT systems, a.k.a. certain process designs, technical limitations, and bad executions — and I’d never identify those problems if I specifically ask everyone to reflect something about the user interfaces.
The bottom line: Don’t make people think about elephants.
#2. Paraphrase to Clarify
Client: “…and I have to check everything manually.”
You: “You always have to manually check it?”
Client: “Yes, that’s right.”
That’s merely the worst conversation you can possibly have with your client.
Never repeat what your client just said. Always paraphrase — up to the point that can introduce contradictions.
By saying it in another way, you bring about a few interesting issues:
- You use different words, concepts, and/or interpretations to detect and confirm whats, hows, and whys.
- You encourage your clients to clarify their ideas and descriptions.
- You intentionally (and appropriately) introduce contradictions, so that your clients’ are forced to explore and clarify their own descriptions further (See Tip#3).
“Should/Can I put it this way…”, “Does that mean…”, etc. could work.
The bottom line: Never repeat what they tell you, always paraphrase.
#3. Contradictions Are Great
One common case for me is that, the stories I encourage the stakeholders to tell pose quite some contradictions. And that’s great!
Those contradictions among different stories, regarding different perspectives, scenarios, angles, or topics, reflect the stakeholders’ different emphasis and focuses which usually can be difficult to identify or recognize in just one “whole story” told once by them.
Through those contradictions and your questioning them, both the stakeholders and you can probably have a better idea of the whole matter. In order to explain away those contradictions, both of you are forced to identify something you either omit or get wrong.
Oftentimes, whenever the situation permits, I intentionally exaggerate in my paraphrasing, so that I bring up potential contradictions in a very explicit way. When there did be contradiction, my clients would try to explain; and when not, my clients would usually paraphrase to oppose me.
While there’s a fine line there. Sometimes, e.g. when a friendly communicative common ground hasn’t been previously established between your clients and you, they may find your exaggerating or posing contradictions very annoying or irritating. Thus when do we know we can get a little bit “aggressive”? The simple answer is: trial and error. You need to try and observe people’s reactions and adapt accordingly. The long answer can probably be found in Interviewing Users (yes, users, but you know what I mean).
The bottom line: Contradiction means more to know, you’d better have it before you know it all.
#4. Don’t Fix The Direction
Branching is great. Choose-your-own-adventure. Multi-ending branching-story role-playing games. Interactive fiction. Improvisation theater.
For an interview you’re supposed to gain insights about people’s requirements or problems, it might not seem to be a good idea not to be focused. But really, whenever the situation permits, try going all directions and branch the topics as much as possible.
Just because the more branches and directions you have in a certain problem space, the more depth and breadth you get. But how to manage that complexity? Mindmapping of course. And it’s sometimes better to mindmap along with clients (when they or you make them comply).
It’s probably always good to encourage your clients to go in depth here and there, and to spawn multiple directions regarding a specific topic. You get to know how they develop and interpret ideas or topics, which may help you align with them. To me, branching almost always brings an additional benefit: contradictions.
The bottom line: Get as many dots as you can before trying to connect them.
#5. Visualize The Concept Development
The back of a napkin does work. Visualizing the process of development often works.
When appropriate, I frequently use mindmapping tools (Mindjet, etc. or even just the plain old text document) projected to a big enough screen or simply just on screen, and invite the stakeholders to participate.
More often than not, there’re already previously briefed information on the maps, and the discussions build on or break it. It also helps you keep track of all the directions (see Tip#4) you’ve been covering during the conversation.
The stakeholders can see their thinking influences on screen and participate in a creative, instead of interrogative, way.
It’s not always appropriate to do that with outside stakeholders or clients, but I find it absolutely beneficial when working with internal ones.
It’s nothing new and many good blogs and books already out there. While I still want to emphasize the power of being visual by repeating it. Regarding getting visual, it’s always about the means, not the ends. The mere presence of meaningful visuals helps people think — and that’s not magical, but scientific.
The bottom line: Visualizing is externalizing.
#6. Ask For User Stories
It could be a useful “reality check”.
Your clients are probably stakeholders, but not often the end users. You need to know how and what those stakeholders think of the user scenarios, so that you may identify their primary concerns in the whole matter. What they think of the users actually doesn’t matter quite much. It’s their doing so that may give you the insights.
Exactly because they’re not the end users, they’re probably more likely to ignore certain issues when forced to describe a user perspective. And what they ignore is important to your understanding their concerns and motivations, you can build more questions on it.
Of course, it’s not always practical or appropriate to ask your clients to do that. But you get the idea — sometimes “how would you envision/imagine a user does…” results in knowledge of ignorance.
The bottom line: Dig your clients’ various perspectives, especially their ignorance.
#7. Always Ask About Context
Context could mean anything. When connecting dots, the context is their relationship. In storytelling, the context is the story world. When your clients are telling you about their problems (or what they think their problems are), you ask for context in order to know why they say such.
For insights, the stories are the context. Sometimes, when hearing the clients’ telling, I’d intentionally paraphrase in a “narrowed-down” way (e.g. “does that mean you do this only when/where/if/…”), so that the clients could go like “no, not only…” and the context for a certain action or decision in the story would then be revealed. Of course, the actual situation can be much more complex than that. But you get the idea.
Don’t take anything for granted. There’ll always be a bigger context you may or may not need to consider. And it’s probably good, whenever the situation permits, to ask about the context just to check or verify a certain point — haven’t all those infamous jokes about software requirements everything to do with the misunderstanding or ignorance of proper contexts?
The bottom line: Learn to zoom out/in, because context is infinite.
Conclusion
It may be unnecessary to bare all the above notions in mind while discussing fluently with a bunch of stakeholders. It’s probably more about constantly practicing and therefore infusing that awareness into our way of doing things — e.g. interviewing clients. And visualizing things during the process may help a lot.
There is of course much more to life than a mere interview. We identify and analyze problems, needs and wants in a combined, multi-faceted way. You can’t expect nailing anything down through an interview, but it’s always better to get the most out of it.
To me those tips are quite general because they’re actually about communication skill — and you need it all the time, everywhere. It becomes an integral part of UX or design just as it becomes that of any other field.
Designers, or problem solvers, as long as they’re in a goal-oriented context, always need to distill insights from storytelling, not from premature distillations.
You can’t ask for requirements, just as you can’t ask for insights. You can only ask for stories by asking good questions. Insights come from later reflections. The dots in those stories are connected through their contexts — the stories themselves.
{E N D}
[1] Chris Crawford on Interactive Storytelling 2nd Edition
This work by Noah Fang is licensed under a Creative Commons Attribution 3.0 Unported License.
Noah Fang 