in Uncategorized

IDSC Followup Thought – Bringing the Disciplines Together

One topic among the many discussions going on at IDSC was the degree to which business types should know design. Do we want the business types to be designing? If not, just how far along that path should they go? The flip side came up, too — just how much “business” stuff should designers be doing, be aware of?

And, we didn’t even mention other people who should be involved, most obviously the technologists/engineers.

For me, I have no interest in seeing business people become designers, designers become business people, engineers become designers, etc. etc. BUT, obviously, all these groups need to meaningfully interact, they do need to work together, and they need to understand the value that each brings to the table.

I identified three key points at which all these disciplines should be working together, side-by-side.

Developing Intent
This is the outset of any project or process. WHY are you engaging in this project. What is hoped to be achieved? What hypotheses are you bringing? How will you go about challenging them. It’s crucial that all voices are brought to bear here. Bad things happen when one group (usually a “business owner” or “product manager” or some such) defines everything for the rest of the organization. All parties have something to contribute here, and this is most definitely one place where no one group has more to offer than any other

I suspect this is pretty obvious. Nothing shocking there. Get the team together at the start. Great. But then what? Typically, either disciplines go off and do their own thing and come back together, or there’s a series of handoffs as the project moves from one group to another.

This is where the two other key points come in.

Observational research (aka “ethnography”)
As Harry Max put it in a talk he gave at the IA Summit Redux, there is only one thing that every business needs – customers. And this means that everyone in that business should be interested in and concerned with those customers.

This is all about empathy, people. And everyone in the organization should be encouraged to be as empathetic with their customers as possible.

The one key place where this appreciation can happen is through observing and interviewing customers. This should not be the purview of some small group in the organization. There’s no reason that everyone can’t engage in this practice. Yes, it might take some practice to learn appropriate ways to observe and interview, but, really, this isn’t a highly specialized skill to only be practiced by vaunted experts. Everyone is better off when everyone observes and listens to customers. It’s essential for getting everyone to recognize what is going on with the customers, what’s working and not working for them, and to really feel what it is like to be a customer.

(I’d also like to note that, contrary to some recent “design thinking” hagiography, that empathy and ethnography are NOT elements of design thinking. In fact, when I first started working with designers, they proved to be among the least interested in truly engaging with customers. And if designers try to claim ethnography, they will be doing it, and their colleagues, a disservice.)

I don’t think that everyone needs to be involved in all forms of customer research. Surveys, market analysis, user testing, trends, etc. etc., can be performed by specialists. But I do think watching and talking to customers is something everyone should do.

Generate Insights from models
This is the one that’s probably the least obvious, but I think potentially quite powerful. After the customer research has been gathered (and not just ethnographic research, but all the awareness that has been built up around the customer), it should all be laid out in front of the entire team. And the entire team should be involved in figuring out what all that research means, what models can be developed to tease out patterns and stories, and what the implications are on the project.

Insights can and should come from anywhere on the team — in fact, this is one of those situations where the more perspectives there are, the better. This is brainstorming. This is generative. This should be about coming up with ideas. This won’t be untethered brainstorming or blue-sky — the customer research should provide a foundation, and a boundary, that insures relevancy. But, again, this shouldn’t be “owned” by any one group. This should be a joining of hands, as the team understands the implications of the research, and agrees upon the most appropriate direction for the project to take.

It is at this point, with a fair amount of shared, common understanding about the problem to be solved, that people can once again firmly put on their discipline cap and focus on execution. The idea being, since the strategy and direction is shared, the disciplines, even as they do their own thing, or working toward a common goal.

  1. Peter, didn’t you just describe Cooper’s Goal Directed Methodology? (sans terminology and a few steps)

  2. Well, Cooper is a huge proponent of designers being the ethnographers. and I don’t see why it would be a disservice for that to be the case (resource time in a rapid development environment put aside).

    For while I agree with you that most ‘designers’ don’t care one iota about engaging with customers, I’d also say that those ‘designers’ are not cut out to be ‘interaction designers’ (or to avoid a nomenclature discussion, a designer of interface behavior based on a cross-section of modeled needs). They (and our products) would probably be better served by focusing on graphic design, animation, etc.

    In my experience, ‘revelation’ is why I want to participate in/lead user interviews. The more I go through a middle-man to understand users needs or intent, the less accurately I can model behavioral needs. I agree with Harry on a conceptual level about group interest, but corporate culture hasn’t advanced to that degree yet. Roles have responsibility and output. Time = money. Capitalism.

    Cooper’s method is more thorough, but you touch upon the primary elements of Research and Modeling with brainstorming worked in to present, iterate, share and evolve the product vision and modeled persona.

  3. Ah, okay. I get it.

    Again, I can’t speak to Cooper’s methodology, but in your post, you mention only designers engaged in ethnography and modeling. The point of my post is that it shouldn’t be only designers doing it, but the whole team — across disciplines. There’s nothing so special about observing people that anyone couldn’t do it.

  4. Well, logistics alone won’t allow for the entire team to run a set of interviews. Add the impractical nature of 4 to 7 people grilling someone in their work/home environment and maybe you see why Cooper espouses two people to an interview; one interaction designer and one design communicator.

    My take is that each case could dictate the size of the interviewing team, depending on factors such as where the interview would take place (work, home, client site, etc.) and the personality of the respondant themselves (as much as you can ascertain in the recruiting process, that is).

    Look, I’m not trying to add onto the myth that a designer has the corner on the empathy gene. As a matter of fact, the term empathy has gotten way too much press (almost as much as design thinking, but that’s a whole other conversation). Whatever you call it, the designer does derive insight from extremely subtle gestures and utterances of the interviewee, which makes it imperative that they are included/leading research.

    In the real world, businesses make choices and divide work roles/tasks to be productive (as well as defend the status quo). Now, is that just a reflection of the hierarchical, ivory tower model of business? Somewhat. But it’s also the fundamental mechanism of how capitalism runs and sustains itself, and if you’re talking about changing the participation model of serious businesses, you’re stepping into the realm of capitalism. In that case, make sure you bring a ton of value propositions and ROI (hard, not soft), a strong-willed conviction for change and some mace.

    Personally, I’m completely open to who (and how many) roles joins a designer in the research mix, and it can be judged on a case by case basis, according to experience, subject matter expertise, desire for inclusion, etc. But my primary concern is that it is someone who can take notes, ask the right follow-up questions, communicate with an easy going tone and work closely with me while I model user needs patterns post-interviews.

    Otherwise, participation is worthless. They can watch the DVD if they want to be included.

  5. > There’s nothing so special about observing people that anyone couldn’t do it.

    I’m glad I gave this post several days before I responded; that’s what I thought you were saying in your post, and I must strongly disagree.

    Of course, let’s get this out there right away – user research (or whatever you want to call it, although I’d say that “observing people” is a description that misses the point) is my profession, it’s how I make my living, and I’m obviously motivated at a variety of levels to defend the uniqueness of what I do. So, you’re going to filter my thoughts that way anyway, I want at least to be honest with that.

    Typing is a fairly straightforward skill. But writing is not. It’s a mistake to confuse them. Having a conversation and operating a video camera and leaving your office are straightforward skills. Conducting user research is not, and it’s a mistake to confuse them.

    I’ve been in the field with a lot of people over the years who are comfortable doing interviews, or who may even describe themselves as doing user research. Many of them are terrible and will never get any better.

    There was a time when the creation of user interfaces was owned by software engineers who said that an interface was easy, obvious, and anyone who could code could go ahead and make one. The struggle to demonstrate value and explain process and create artifacts that represented a more enlightened way of thinking has changed that to some extent; so I’m chagrined to see Peter repeat that behavior by similarly dismissing the unique skill set of a different discipline. Those programmers thought they were perfectly good at creating the right user interface; do designers similarly think they are (by default) perfectly good at research?

    There may be an issue here of “good enough” – not every project requires a level of insight, and some simple observation may get you there, but let’s acknowledge the range, and not dismiss an entire profession.

    Not covered in this comment are the ranges of “participation” that allow a variety of differently-skilled researchers to maximize insight, exposure, empathy, contact, whatever. I’m addressing the bias of treating research like observation/conversation.

  6. In an attempt to make my point clearer, the following are a few research study & participation scenarios (all including design participation), arranged in the order in which I would feel most comfortable:

    1) A researcher (say, Mark Safire from Sachs Insights or you Steve 😉 leading the study, with an interaction designer acting as the notetaker.

    2) An interaction designer, one with experience running an ethnographic study, leading with another IxD or design communicator taking notes.

    3) An IxD leading, with a commited, engaged member of the product team who has the patience, ear, time and inclination to add value to the research study.

    You’ll notice that “anyone and their mother” isn’t a choice.

    As a designer, I’m more than willing to have a trained researcher as the lead, but, as a designer, I feel that it’s imperative that I’m at least a part of the actual study.

    For me, the ability to ask a question which might lead to an experience twist in the product as I model usage scenarios, is way too important for me to pass up on… in theory of course. Most companies aren’t set up like this, unless they follow Cooper’s method.

    This conversation always reminds me of where the hand-off between IxD and UI design lives.

Comments are closed.