By Scott Berkun, April 2004

For a guest lecture at the University of Washington I spoke about what I wished they’d taught me about design in college.

What they don’t teach you and why

Surprise: creating a degree program is a design problem, with many of the same pitfalls faced by software designers. For years it was my job at Microsoft to create and run design education for employees. In the process of designing courses and curriculums I re-examined how colleges do it.

People often say “they really should teach X in school” but they rarely consider what they’d have to take out to make room. Since college is the last formal education many adults obtain, there is understandable pressure to cover foundation topics, rather than what might be immediately useful in the workplace.

So there are 5 reasons why a degree program doesn’t cover something:

• They don’t have time / resources (priorities)
• They don’t think it’s important
• They don’t have experience with it (or can’t hire someone with it)
• They don’t know how to teach it in school
• They are trading long term value over short term

However I don’t think you need courses to teach a subject. It can be enough to expose students to important ideas they can choose to invest more in later on. And that is the spirt of the ideas that follow.

There is no substitute for credibility

Credibility comes from action. As soon as you call on your degree or job title as a defense of an idea, you will probably lose. It’s a call to authority and it’s the last call you should want to make.

Instead credibility comes from being good at explaining your logic. Instead of an engineer saying “I’m right because I’m the engineer” it’s better if they explain their logic, giving everyone a chance to understand their insight and either reach the same conclusion, or be enabled to ask good questions.

Strive to do the same thing for whatever it is you think you know: bring people in, don’t hide behind pretension and pieces of paper. It’s one thing to ask people to trust you “look, trust me on this – I know what I’m doing. If it doesn’t work, I’ll admit that I was wrong”, but that can be done without throwing credentials at people. (And anyway, in credential warfare in the tech sector, non computer science graduates tend to lose)

People who make things happen do so through the credibility they earn over time. It can take months or years to develop the relationships needed to make great things happen, so be patient. Be smart. Be helpful. Listen to ideas from other people and show them that you appreciate their help, and consider what they say. Don’t be a wuss and let people walk over you, but be reasonable, and thoughtful. Work to get comfortable having dialogs and idea exchanges with people. Even if you end up disagreeing with them, if you build good relationships, you’ll still manage to build the respect of the people whose respect you need.

For example, if Steve is the dude that will convert your screenshot or prototype into the real thing, make sure you have a credible relationship with him. Treat him well, because whether you admit it or not, you are dependent on him to make your design a reality. You want him to do his best work for you, and that can’t happen if he doesn’t trust you, or doesn’t understand what’s so important about the details of your plans (a problem which spawns from the “just do it exactly this way, because I’m the designer and I said so” attitude).

The challenge is that what makes you credible to a developer, marketing executive, documentation manager, or any other person you have to deal with might be different for each one, and what earns you credibility won’t always be tied to your design or usability brilliance. Instead, work towards helping the team get stuff done. Be useful. Then when it comes time to bring your grand design vision to the table, you’ll have built the respect and trust necessary for them to be helpful to you.

Usability/design/cool things are contact sports

Every field has certain things that are considered to be cooler or sexier or more generally interesting than others. Invariably, when it comes to technology, one of the coolest things to work on is the front end, or UI, the stuff customers actually see when using the thing. Invariably the most hard core developers in the world have to show their parents the UI or whatever it is they worked on, and odds are good that’s it the UI that their parents will think they made (“Hey Mom, check out this new RSS parser I built!”, “Great son, but what’s a parser?”, “Uh, nevermind.”). For most people, it’s the user experience that represents the entire effort of an organization to customers, and often to the team as well.

Since user interfaces garner more attention than most other parts of websites and products combined, it follows that more people have opinions and interests in UI related decisions than other things. Be prepared for this. Design work is a contact sport. You will almost never work alone, even if you are granted guru like status in the organization. There will always be opinions to contend with, some more ignorable than others. But the wise know that all the feedback can be healthy: reality checks can be easy to find if you are open to them.

Some rules for contact sports:

• Get out of your office. You will learn and benefit more by eating lunch with the programmers and the testers, than by chatting with your peers. Get out of your office and make yourself a part of the team: not just a specialist. Think of the field goal kicker on a pro football team. He comes on the field twice a game. He doesn’t call the plays, and almost never gets his hands on the ball. If you want to be a key contributor, it starts by knowing what’s going on outside your specialty, and that can’t happen if you only socialize with other designers and usability engineers. Its not high school: don’t succumb to cliques, it only hurts your ability to make great designs happen.
• Politics are real and not necessarily stupid. Because of how many other important decisions impact the UI, political and strategy changes can force design changes. Sometimes it’s for good reasons, other times not so good, but be prepared for things to change. If you are smart, you’ll have an ear out for these issues so that you will never be blindsided, and possibly even a hand in their resolution before decisions are made. Uber-designers often pave the way for their work by forging bonds with the business and political powers in an organization. They strive to nail these issues down early, and make sure that the marketing dude understands not only the impact of late decisions, but possibly cares about the design ideas and learns to see their value.
• There is a bigger world than what you know: The UI is at the nexus of many different logistical constraints. There can be engineering, marketing and business strategy decisions than impact the decisions you are making. Those decisions shouldn’t be made without your input, but they may often be made without your complete acceptance. Understand what parts of the project you’re working on are in your control and which ones aren’t. Know who is in control of the those areas that you are not. Build relationships with them. This will help keep you sane. It will prevent you from inventing imaginary monsters in the marketing department who are evil incarnate. Instead, you’ll know it’s Joe, who is a human being, with opinions and thoughts, and an open door to their office where you can come in and discuss issues with them.
• Design work is team work: Expect to share both the work and the rewards. Don’t covet ideas, or have ego battles – this will rarely help you or your customers. Take pride in the end results, not the pretty screenshots that are intermediary steps (Design is not art. If you think it is, make sure the people you’re working with feel the same way. They probably don’t). Instead see design as a process of integrating different talents. While this might mean more overhead early in a project, it will guarantee you more support late in a project, when you really need it. If you need to feel like an artist, find a way to outlet that feeling that doesn’t involve other people. Write poetry. Design your own website. Learn origami. But don’t join a team only to inflict your ego on them: it only makes everyone, yourself included, miserable.
• Get in the game: In contact sports people get their hands dirty. They play hard, and sometimes make mistakes. No football or rugby player ever scores or wins from the sidelines: they have to get in the game. If there is a problem its up to you to do something about it. Complaining and second guessing doesn’t score points. Passive aggression never improved a single design or solved any usability issues. If you feel energy about a problem, convert it into a force that actually has a chance of solving it. Otherwise you’re not a designer: you’re a spectator. When you do show up at work, and there’s a debate or discussion over some important decision, get involved. Raise your hand. Ask questions. Offer suggestions and put yourself in the center of them (“I can do X”, “I will talk to Joe”, etc.). Avoid allowing other people to speak for you, or waiting for them to set the tone.

Secret philosophies of usability

There is an ultra sensitive “never discuss with non usability engineers in the room” secret that I’m going to share with you. It’s about objectivists vs. pragmatists. I learned about this in the year I worked as the usability engineer on Internet Explorer 1.0, and when I switched to program management, they made me swear not to tell.

The objective philosophy of usability engineering goes like this:

“We are scientists. We do research. Welcome to planet Vulcan. We can provide data on a number of precisely defined questions. Please do not ask us to do anything else. We are scientists. We do research….”

The pragmatic philosophy goes something like this:

“We will do (almost) anything to make better products and websites happen.”

Now, if you were in a really tough situation, like in a foxhole during a war, or dealing with a slipping project with tough design issues, who would be more valuable to you? The truth is you don’t have to pick. The real answer is that the best usability engineers do both. They recognize when what the team needs is an objective and scientific view of the situation. However, they also realize that much of the time what is most valuable is a quick and timely informed opinion, and they are willing to give them.

Continually taking the objective stance severely limits the value of a usability engineer (Often earning then the nickname “data weenie”). It puts them at a distance from the psychology and emotion of the team, limiting their ability to contribute. While everyone else on the team gets the right to offer entirely subjective opinions, many usability engineers refrain. This makes no sense. Why are usability engineer’s opinions any less valid than any one else’s’? The trick is to disclaim the difference between data and an opinion: “Umm, look, I don’t have data to support this, so it’s purely opinion, but I think design A is much better.” Done. Opinioned offered without sacrificing whatever scientific purity they needed to protect.

As I understand it the trouble is that many usability engineers come from experimental psychology or research backgrounds, and they’ve received no training or encouragement towards a more pragmatic view of their contributions. There are many ways to keep scientific integrity intact, while still offering subjective contributions to design choices. It starts by remembering that skills (and usability methods) are the means, not the ends. It’s the result that really matter to customers. Who cares what research method was used or what the margin of error of the survey was if the result is a better product? Never fixate or obsess about the skills, unless you’re certain that they really impact the quality of the decisions or the final design.

Continue on to part 2, which covers:

• Secret philosophies of design
• What to do when people don’t listen to you
• Tricky chemistry of marketing and design
• Why usability reports never get read (and why its ok)
• What the VP said