ByScott Berkun, May 2004

This is the dramatic and stunning conclusion to the last month’s essay about what I think they should have taught me in college about design and usability.

Decision maker or consultant

I don’t know that it’s the responsibility of colleges to inform students about the likely jobs their degrees will suit them for, but it would sure be nice to mention it along the way. Somehow through osmosis students accumulate bits of knowledge about this, but it’s never from very strong sources. Usually it’s from job postings (which as we all know are stunningly effective pieces of writing), bits of advice from professors, and other less than direct sources. So here’s some direct advice: in any jobs, some decisions are yours to make, and some are yours to influence others to make. How happy you will be depends heavily on how well you understand what kind of job you’re signing up for. It’s a simple question to ask of a potential employer: Which kinds of <insert topic here> decisions will be mine to make? If I’m not making them, given that my degree has given me expertise in <insert topic here>, who is?

The job titles product designer, information architect, or usability engineer can imply varying levels of decision making authority. In most cases, it’s less than you think. In some cases, it’s more than you probably want. But it’s authority over design or usability issues that define the real difference between being a decision maker, and being a consultant. If you are a decision maker, people will be coming to you and asking you to decide things. If you are a consultant, you will be going to other people and trying to convince them to do things. Of course in almost all cases, you’ll do some of both, but be sure you understand which things will fall into which categories. Enter professional life knowing that it might take awhile before your team or your manager trusts you enough to make you a decision maker over matters of design and usability.

In most cases, the sole usability engineer or designer on a team tends to play a consulting role. Not that there is anything wrong with that. They are hired for their specialized expertise, and not their general knowledge of making project level decisions. Consulting can be a ton of fun, provided it’s what you’re expecting and suited for. The main problem is that since consulting skills are not part of Design and HCI educations (not even mentioned really), you’ll have to learn on your own how to go about gaining positive visibility on a project team, how to gently teach others the basics of your expertise (so they’ll understand your value), and being persuasive in making arguments to people without your background. (All topics that should be part a 2 day workshop for seniors in design and usability programs. A decent place to start is the cheezy sounding yet quite good, Getting to yes: Negotiating without giving in by Roger Fisher).

Secret philosophies of design

No matter whether they come out and say it or not, every college, university, or degree program has an inherent philosophy behind it. Even if they don’t intend on having one, it turns out that there is one anyway. By choosing the professors, courses, resources, and students, a certain set of beliefs and attitudes will tend to be instilled in everyone that comes through the program. Or I suppose in bad cases, a lack of coherent beliefs and attitudes.

After a decade or so in the industry I’ve come to realize that there are some secret, mostly unspoken philosophies and attitudes that many people with design backgrounds, in particular, embody. I’m not saying that they all do, or that most do: only that many of them that I’ve met do. There are two of these philosophies, and here they are:

The Isolationist: “I will meditate in my office, and return with the ‘grand vision’. Follow it to the pixel and leave me alone. I know more about design than you do, so it’d be best if you just did what I say (although I don’t really say much). If things don’t work, or the project fails, it won’t be my fault.”

The Holistic: “My job as a designer is to help get the best design possible out the door to customers. I influence, and work with, the goals and collaborate with or lead whoever necessary to achieve success. You will not agree with me all the time, but I will be a visible and active member of the team.”

(Warning: unavoidable criticisms of isolationists follows) Since many design programs teach design as an isolated activity (projects and assignments are done by individuals) it’s not surprising that many turn out to be isolationists. They prefer to work alone, because they were trained and taught to design alone (or at best, trained to work with other designers, of whom there is a minority of in the business and technology industries). They are not used to having to place design inside another context (business, engineering, team). They may also not be comfortable with critiques or feedback from people who know nothing about design, or be willing to educate those same people about design.

Holistic designers on the other (admittedly positive) side seem interested in the process, or at least aware that one exists. They are willing to discuss (and argue) with engineers and business people about issues that impact design, and take the time to educate and inform those around them about design, while simultaneously learning about expertise they do not have. Most holistic designers I’ve met come from Industrial design programs (or have no formal design training at all), since unlike graphic design, ID programs require considerations for modeling, engineering and thoughts of production: things that require the acknowledgement of a larger process beyond the pure aesthetics and quality of the design. Thinking holistically doesn’t mean never spend time alone: it just means to be aware that work done independently will eventually fit back into something larger.

It’s not surprising that in a team environment, isolationists tend to lurk in the background. They sit in the back of meetings and keep quiet. They prefer to listen instead of providing alternatives, and respond to actions of others instead of taking the social risks of leading for change. This might all be fine, except that many isolationists I’ve talked to seem unhappy with their relationship to their team. (How many designers do you know that are truly happy at work? I’ve only known a few, and guess what, they were holistic). It seems they want the team to follow their ideas and instructions, and have an auteur kind of role, but aren’t willing to the non-design specific activities (teaching, collaborating, participating, leading) that are needed to make that happen. This creates a certain kind of trap for isolationist designers: they want a different world, but don’t want to be the ones doing the work to make their world that way..

designers vs. Designers

Going beyond isolationism and holism, I think a more useful categorization might be designers and Designers. Little d designers tend to live are at the tail end of the process (Downstream). They are involved in tactical decisions, and respond to choices and decisions made by others. This often puts them in the position of doing icons, simple style and layout work, and other production activities. Big designers take on strategic design thinking (Upstream): what features will be in the website? How will they work? How can we prototype not just the style, but the business model, and the customer experience? How will it all fit together? What prototypes do we need to convince the team this is the way to go? How do we get business and engineering involved? Etc.

In organizations where design plays a passive role, someone else is doing the heavy design thinking, deciding which ideas and concepts drive the website or software product: most of the time these people are not designers and have no formal design training. Sometimes it’s engineers, who drive the concepts as a by-product of the engineering and technical choices they make. Other times it’s a project manager or team leader that inherits the responsibility This means that the Big D designer, is not someone with the word design in their job description. It’s someone else.

So if you wonder why a company with dozens of good usability engineers or designers doesn’t seem to produce a quality level that matches, guess what? Those folks are probably not driving as much of the show as they’d like to.

What to do when people (or animals) don’t listen to you

As a general rule of thumb, important people are busier at work than less important people. This means that the more important the things you need to do are, or the more important the people who’s help you need are, the harder a time you are going to have in getting the attention you need (or want) from them. They often have many people who want them to do things, or make decisions in a certain direction, and have to spend time managing the input of those opinions. Feeling ignored comes with the territory. People won’t always prioritize things in the same way that you have, and your top issue might be at the bottom of their list.

This means sometimes people will not listen to you. Sometimes they’ll blow you off, other times they’ll tell you flat out that what you want isn’t going to happen, but either way, you will have to figure out different approaches to take. And no amount of work in Photoshop, or in the usability lab, or other HCI skills will help you here. In fact, those specialized skills in all probability have nothing to do with your ability to get someone to listen to you, and your communication skills have everything to do with it.

Here is a short list of common bad ways people deal with this situation:

• Say whatever it is again, only louder.
• Threaten to Tell Mom (Mom = authority figure)
• Complain to whoever will listen that no one listens to you. ( A sure way to add them to the pile).
• Make moralistic and abstract arguments (the weenie method): ““If you really cared about users, you’d…”
• Try to rely on some external (but unrecognized) authority: “The International committee on theoretical but mostly ridiculous doctrines says you should always…”
• Actually tell Mom
• Offer bits of tasty food
• Hide in your office, wait, then complain again
• Fall into misery and bitter despair, and drag everyone within reach down with you

Here is a short list of what effective people do:

• Stop and listen more carefully to what others are saying. What are your assumptions?
• Step back and make sure you see all angles to the situation. Is what you want really as important as you think it is? It is possible they are right, or that this isn’t the issue to spend your limited influence on.
• Clarify the goals and objectives: are you trying to do the same thing they are? What are they trying to achieve, that what you want to achieve contributes to? (Note to self: if there is nothing, you probably screwed up weeks ago, by not knowing ahead of time the direction things were going in. This is rule #5 of consulting).
• Learn how to be persuasive (won’t find this in usability books, but may in good business books such as Getting to yes, mentioned earlier). Who makes effective arguments in the group? Who is effect at convincing Important person X of things? How do they do it? Can you ask them for advice?

Tricky chemistry of marketing and design

Among the many misunderstood professions and disciplines in the modern world, none perhaps scores higher than marketing. Somehow marketing has been pigeon holed to mean only sales and advertising, which as anyone with an MBA will tell you, is only one part of the process. MBA type folks define marketing in terms of the 4Ps: Product, price, place and promotion. Marketing, from an MBA perspective, defines not only how a product is positioned, but the definition of the product itself. Although this may or may not include a limited understanding of product design (depends on the school), their understanding of product development is, from their view, complete.

So it’s not surprising when you put a person with an MBA in the room with an HCI or design expert (or say a team of programmers), that there is some conflict over who should be in charge of what. Or more accurately, there is no confusion in the minds of the MBA dudes folks: the business and marketing come first. The MBA dude can point to his degree, and claim dominion over much of the thinking and planning for what a product should be, since he or she is trained in how businesses function, and has an understanding of how to make money. Designers and Usability engineers can not make this claim, at least not by pointing to their degrees.

It follows that to do well in an environment interested in profits and revenue, a designer or HCI expert needs to know something about the MBA philosophy, terminology, and outlook on the world. They certainly don’t need to know everything, but something. The basics, some fundamentals, the kind of core stuff that could be conveyed in a long lunch in front of a whiteboard, with an open minded and friendly business expert (and a few cocktails first wouldn’t hurt). If relations are good, often designers can learn from the business and MBA types themselves, in real time, as decisions and discussions can provide opportunities to compare approaches, philosophies, and other good things. (I read the book the ten day mba a few weeks ago. Not bad. The section on marketing was worth the purchase).

It turns out that once designers and MBAs are speaking the same language, and share enough understanding about where their philosophies converge (Designer: “I want to make great products”, MBA dude: “great products will increase our revenue and ROI”. Crowd cheers). However until that happens, much bad blood can be spilled. Passive aggression and resentment can dominate behavior, and this often works against whomever is outnumbered, or has less authority (which tends to be guess who?)

Why usability reports never get read

If you write usability reports, how much do you understand about whom you are designing usability reports for? Have you ever applied user centered design principles to usability reports themselves? Why or why not? My guess is that you haven’t, and if you did, the results would surprise you. What you’re providing is probably not quite what your team (aka your second set of users) needs from you. What they are looking for is probably at odds with what you want them to look for, and the usability report becomes some kind of philosophical battleground. Generally, the authors of the reports lose.

Most usability reports seem to be written to validate the study, and prove that the data found is reliable. Unless this is the first usability study for a team or corporation, scientific validation isn’t very important. They trust you. They pay your salary and give you an office (and probably shiny computers, and fancy equipment for the labs). The most important thing about a usability study is how what was observed should impact future decisions. Should some features get cut? Added? Changed? If so, how? If the study can’t answer these questions directly, or contribute to conversations of this nature, how else can it be of use? All of these things are what programmers and managers want to know. Statistical validation or details for how many people were able to do what, in what amount of time are all secondary. They are only helpful in determining answers to the questions I just listed.

The best usability engineers I’ve known tended to see the actual reports as a formality. Instead they focused on email, in person discussions, and post study (akin to post-game) breakdowns of what was observed. By focusing on the relationship between the usability engineer and the team (or client), the usability engineer can replace the report as the primary conduit for information. They make themselves available for discussions, for brainstorming sessions, and for less formal debriefing presentations to the team. In the infrequent cases where deeper analysis was required (say, a benchmark study) enough trust was built with the team that they would wait for the full report when necessary, and understand enough about the process to see why that time was necessary.

Pop quiz #1: How much of what you are asked to read at work do you read?
Pop quiz #2: How much of what the average programmer or manager at work is asked to read do they read?

In both cases I assume the answer is less than 100%. This means people prioritize. They try to figure out what is most important, and what information can be best obtained through other means. Don’t bet everything on doing well in that competition for their attention: that is unless you are providing things you know people need to do their jobs, instead of what you need to do. If you have earned the support and buy in from your team, and are doing work that directly impacts decisions they are making, you won’t have to push very hard to get them to come to the labs, or read the (well written and not overly scientific or jargon heavy) reports.

What the VP said

In the years I worked at Microsoft, I had conversations here and there with several different VPs. I can’t say they were all brilliant or likeable, but many of them were smart, and interested in sharing what they knew with the people that worked for them. Since I worked in program management, I was privy to many of these conversations and meetings, where-as often the designers and usability engineers (and testers, programmers, documentation, etc.) on those projects were not (a side-effect of the decision-maker vs. consultant thing. In important meetings, with small rooms, guess who needs to be there, and who doesn’t).

Anyway, here are some nuggets that I remember related to high level discussions of strategy, design and user experience work. The quotes are followed by what I wrote in my journal at the time, trying to interpret what I though it all meant. Hope it’s of use.

I don’t care what you know, I care what you do: Knowledge is irrelevant if it doesn’t act. So I’d rather have a team of smart people who know how to apply their knowledge to the product, that brilliant people that don’t. Your skills are the means, not the ends. Please never get distracted from the ends.

Usability or <insert job title here> is irrelevant unless it helps us be successful: You have a salary because the organization sells products you contribute to. This is a corporation, and though we want many good things to happen, we focus on good things that will earn us profits. Usability is only of value in how it helps that process. Same for programmers and everyone else. If we didn’t think they helped in that process, we either change their focus, or stop paying them. The same is true for every job title, every discipline, employee you see here, or at any of our competitors.

To be important you must lead…To lead see beyond your job title: Leaders cross boundaries, but rarely get fired upon. Get involved in how things fit together, not just how your piece is built. That’s who has impact, that’s who gets promoted, and that’s who earns the authority to make decisions.