#31 What they didn’t teach me (part 1)

Scott Berkun
- Home
- Blog
- Hire Me
- Books
- Essays
- About
- Contact

#31 – What they didn’t teach me in Design & Usability school

By Scott Berkun, April 2004

Classroom A few weeks ago I gave a guest lecture at the University of Washington on what I wished they’d taught me in college about HCI, design and usability (I studied these and other things at CMU). Here’s an essay based in part on what I told the kind audience that showed up to listen.

What they don’t teach you and why

For a few years it was my job at Microsoft to teach people how to make software and websites for people. In the process of designing courses and curriculums I re-examined how colleges do it. Surprise: it turns out creating a degree program is a design problem, with many of the same pitfalls and traps faced by web or software designers.

In examining university degree programs, I realized in 4 or even 6 years it’s impossible to teach all the things needed to be a senior professional in any field (or perhaps more importantly, a happy and well educated person). It can’t be done. And since undergraduate and graduate degrees are the last formal education many adults ever engage in, there is understandable pressure to provide coverage of foundation topics, rather than things that might be immediately useful in the workplace. One of the things I studied at CMU was Computer science, and I remember at the time thinking how strange it was to learn about esoteric things like the Church-Turing thesis, or abstract models of object oriented programming (instead of just the languages themselves).

But looking back, I realize that much of what I learned was fundamental enough to make it easy for me to learn any programming language or understand how any operating system worked (not just how to use any OS, but to understand how the OS did what it did). I certainly didn’t study Javascript or Flash while I was there (they didn’t exist yet), but what I did learn was the fundamentals that led to those things. My education was more valuable over the long term after graduation, than it was the over short term.

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

So what follows are some of the things I wish were at least mentioned, even if just in a workshop on “things you may need to know that we didn’t have time for” or some professional focused workshop run by alumni or something. That would have been super helpful to me as a new graduate to get a boost of practical information before heading off into the professional world (Or perhaps even better, would be to offer this 6 months or a year after a graduation, when many folks are still dealing with their first jobs). With all this in mind: if I could go back and teach or inform myself about things, here’s what they would be.

There is no substitute for credibility

Credibility comes from action. Degrees and job titles don’t buy much when a tough decision has to be made. It’s how a person applies their knowledge in a situation that earns them the trust and respect of the people they are working with. As soon as you call on your degree or job title as a defense of an idea, you will lose points. Imagine if an engineer said “We should build it my way, because I’m the engineer”. They might be right, they might be wrong, but using their job title to support their opinion leaves no way discern the difference. If instead they explained their logic, and some of their knowledge, they would give everyone in the room a chance to understand more about the engineer’s perspective on the problem, and either reach the same conclusion as he/she did, or offer good questions into the engineer’s logic. 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 credetional 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

Football game 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

Picture of silly usability person 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: