scott berkun continues (see post on part 1) his lessons that he learned outside of school:
(Part 2) What they didn't teach me in Design & Usability school
Decision maker or consultant
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 decisions will be mine to make? If I’m not making them, given that my degree has given me expertise in , who is?
Of course in almost all cases, you’ll do some of both, but be sure you understand which things will fall into which categories.
most senior level designers tend to mostly consulting and the problem is those skills are not taught in design school:
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.
the isolationist vs. the holistic
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.
'little d' designers vs. 'big D' Designers
the former focuses "downstream" and does mostly tactical work (creating icons, layouts) while the latter is focused "upstream" and is more focused on strategic thinking (funtionality, interaction, prototypes, business model, the customer experience).
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.
how to get people to listen to you
- 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?
bone up on basic business skills
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).
scott recommends
The Ten-Day MBA
usability reports need to be useful
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.
snippets from scott's journal - things he learned from 9 years at microsoft
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.
