My Take on Big Company Suckage

Scott Berkun wrote a good post on Why Big Companies Suck, at popular request on his site. It made me think about my own experiences at small, medium, and large companies over the past 20 years. I'm assuming Scott and his readers were mostly talking about "why it often sucks to WORK at a big company," rather than why big companies suck from the outside looking in.

The individual is lost in the machine. The opportunity to be noticed, to get feedback for doing a job well, or for improving someone's life in or outside the company, is that much less. Which may limit your chance of a promotion, or just make you feel your job is pointless. One company I worked at had a famous management mantra, "If you're not making the product or selling it, what are you doing here?" Which is absolute bullshit, and dismisses the administrative roles of accounting, the benefits department, travel and admin staff, tech support, and other critical team members at a large software business. Functional companies need a lot of people doing different things, otherwise the people writing the code can't do THAT job.

Communication from the top is often poor, intentionally or not. The message that trickles down from management, or that's delivered from main stage at company meetings, tends to be diluted for the common denominator, which means it's not really addressed to anyone in particular. Sometimes it contains no information at all, as a result. Scott may have covered this under "they believe their own bullshit," but I think there's another slant on it: They don't know what's going on. The more levels and divisions there are, the more distorted the signal is, and the more likely you are to hit people who aren't sure they're supposed to be telling you something that they know.

Secretiveness. I don't get it - but bigger companies tend to keep more secrets from their own employees. I have nothing to say about this right now, because I'm just baffled by it.

Managers are rarely evaluated well or fairly at any sized company. Even in times of turnover or economic distress, management are the last to go (unless they're a very public, board-threatened figure, like a CEO, in a very bad political environment). Scott mentioned the Peter Principle, but I think it's more profound -- with power working as sum of the people below you, the weakest point in the tree is the bottom. Even when the bottom is arguably the most valuable part of the workforce. Companies with a lot of management structure will have fewer people doing quantifiably good work, occupying the org chart and protecting themselves at the expense of the workers under them.

Evaluation of what's good or valuable often happens on idiotic scales. When I worked at AT&T Labs 15 years ago, the company didn't think about anything but a sure business that would pull in billions -- never mind betting on smaller startup ideas to see if they could create new markets or businesses. Other companies like 3M and Google have since made this a visibly stupid way to do business, but it's definitely an easy way that managers can avoid risky bets on new verticals or product lines.

The small company made crap, and now the big company has to support it. Staff in big companies are sometimes stuck in trying to repair what was made by the small company, or what was acquired from the small company. This really sucks for the people in the big company. Bad design that was produced in a "proof of concept prototype" as VC's pounded on the door and the cash ran out -- well, those guys saying the good old days were great got rich off that crap, and now it's everyone else's job to "fix it."

Because the small company made so many mistakes, and the bigger company learned from them, there is more process and review of decisions. Face it - a lot of the processes and checks and balances in bigger companies exist because of bad things that happened when the company was smaller. The big company "learned." It decided it was too risky to do that stuff again. Stuff like having no usability review of the most important feature of the release!

Smaller companies sometimes feel more homogeneous -- the individuals know each other better, and there's usually less role differentiation and processes involving a lot of people you don't understand. This can make it more pleasant, give the impression that you're "getting things done," but it can also mean less original or high quality work is produced in the end. See above, about producing crap and making mistakes.

People who have their own money at stake, or make a lot of money from something they did, tend to be very engaged and happier about their contribution. This is a guess, but I think this study about hourly workers supports it. The study says people feel a stronger correlation between happiness and rate when they are paid hourly, rather than by salary. There's a direct reward connection between money and time. People who got a lot of money from a startup --either from selling one, or being there and getting the stock profits -- no doubt feel they were rewarded by the world for something of value that they did. It's less easy to feel rewarded either monetarily or by subjective feeling in a big company. Because the individual contribution is much harder to make or to recognize.

Finally, a few ways in which small companies can suck, too: There's never enough money, or for long enough; there isn't enough staff to do things that need doing (travel booking, accounting, etc?); the hours can really suck, related to the money issue, no doubt; there are STILL cowboy coders and often secret politics about decisions and design directions and what we're hiring for next.

Tips and Tidbits from the UI14 Conference

Back to blogging after a long hiatus of work and travel... UI14 in Boston had some good stuff for designers and managers! I heard a lot about techniques for creativity and design generation before winnowing; good reminders to generate multiple approaches before "settling."

Dan Rubin had his workshop group generate 20 different thumbnail sketches in 5 minutes. (Maybe it was less - it seemed like less.) Then combine the best aspects of their favorites into one bigger one. Hard, and a good way to make you get crazy early, if not go crazy, or just to think very broadly.

Leah Buley's charming "How to Be a UX Team of One" presentation is worth watching online. Her link includes her templates for wireframes with notes - useful for her excercise of 6 designs in 5 minutes (or less? again, I forget). After doing those sketches, she took a room vote on which idea in the 1-6 range the audience preferred out of their generated sketches. Most of the votes indicated it was not the first idea drawn.

There were some other interesting creativity exercises in Scott Berkun's excellent "Myths of Innovation" workshop (based on his excellent book of the same name). For a stuck team that's gone dry on good ideas, try brainstorming the worst product features possible for a while -- this will open up the wild and funny ideas. Then invert them, for the germ of some good ideas to pursue. Another alternative was to go from completely unconstrained brainstorming (such as "ideal features of the perfect cell phone") to slightly more constrained ("ideal features of a $10 cell phone").

I found Scott's most entertaining activity to be one in which the group listed 30-40 (again, early onset memory loss) random words - nouns describing things/activities/states and adjectives. Each small group had to pick 3 of them, brainstorm a new product or service around them, and create a pitch for it. All in ten minutes.

Strangely, from our workshop list with "TiVo" (I did not propose it!) and "guitar" and various sports... many of the groups picked the word "tomato." No idea why. But their weird product pitches were all very clever and funny. Scott pointed out afterward that this illustrates how a bunch of people who had never met before could self-organize, be creative, and even have a good time doing something that initially seemed impossible. On the "self-organization" topic, he noted that the person who takes notes in the group (self-nominated, of course) is usually the person who ends up delivering the pitch for the group, which also seemed to be true for several of these groups. As a conclusion to that one, he said that the reasons for this activity being difficult for many people (despite their success!) were these:

• Creativity creates confusion
• Unclear roles [group self-organization takes a few minutes or lots more]
• Responses to uncertainty differ
• Responses to subjective criteria differ
• Group dynamics influence decisions
• Time pressure [creates more stress]
• Lack of trust / relationships [although I noticed that one team had a bunch of people from the same company, a team I wish I'd observed during the activity]

Scott gave out copies of his newest book, Confessions of a Public Speaker, at his second UI14 talk. That talk was great fun as well.

Dan Rubin's short talk on Visual Design tips was excellent as well. A couple of his tricks will definitely go in my toolbox, especially the use of an image that a client chooses for setting a color scheme using kuler. (My take on it: Choose a bunch of images that might convey the mood of a site or product that a customer wants, and be sure the palettes are sufficiently different. Ask her to choose the "mood" she likes, and generate the colors from sampling that image.) Another of his tricks - using a 1 pixel sample of a photo to generate a gradient lighting effect with layer blending - was deeply cool!

UI14 is a great conference, and this year it was in an even better venue than it has been before (a plush hotel in more accessible South Boston instead of cramped Cambridge). Some things that make it annually so good: power strips under every table, and working wifi; a great drinks party; long workshop sessions as well as sampler short talks; accessible speakers who hang out and attend each other's sessions (or else, just check the bar). For a tech-industry conference, it does an excellent job of being gender-balanced for speakers. UI14 also has the odd honor of being the funniest conferences I've been to in a while -- possibly because Berkun, Gerry McGovern, and Jared Spool are all very entertaining! Check it out next year.

In Defense of Hard Skills for Designers

The other day I was in a meeting in which evaluation criteria for developers came up; nice concrete stuff, like writing code that other people can read and modify, putting in comments, resulting bugs, etc. It made me pause and admire the local weather of that strange country. In my experience, it's vanishingly rare for an interaction designer, usability specialist, or User Experience professional to have such nice hard criteria applied in evaluation of their work. Far too often, we're judged on mushy subjective factors like whether some team likes working with us, or feels we're doing something valuable--often outside their expertise or range of view to make this judgment, but that rarely stops anyone. I have some stories about this subjective mushiness in my article in HCI Remixed, titled "Designing 'Up' in the Software Industry."

Why is this--sign of an immature field? evidence of double standards, for sure, but also imprecision of job role? Poor management, perhaps contributing?

I suspect it's related to the observation that many designers have trouble achieving credibility in their role. Scott Berkun's seminar for UIE on Why Designers Fail advocated working on "soft skills" over hard skills, such as learning ways to win friends and influence people via negotiation, diplomacy, and other interactional condiments.

Not to pick too hard on Scott - it's hard to disagree that people skills are valuable and most of us in the computer industry are weak in some of them - but I think it's generally NOT true that designers have sufficient hard skills. I think gaining and using hard skills are our best bet for being taken seriously in places full of skilled workers. Most interaction designers spend too much time in "soft" areas that can too easily look like matters of opinion to others, or overlap and sometimes threaten other existing professional roles like product management: user testing (which often looks like "anyone could do this"), observing people work and suggesting improvements to their tools, pointing out issues in existing products that could confuse users (heck, everyone has an opinion on that), scheduling and managing stakeholder meetings, writing requirements documents and functionality specs. Most of these activities are politically difficult, and don't make other colleagues drop in their tracks and say, "Oh, you're so valuable and provide skills we don't have!" As I pointed out in my HCI Remixed article, a common reaction to much of this work is, "Didn't we already know that?" Finding problems with software is relatively easy; creating solutions is not.

We can convey solid, indisputable value when we focus on creating concrete, skilled deliverables that NO ONE ELSE CAN MAKE. In economic crunch times like now, consultants hear this from the front line. If a client or potential client has someone on staff who can apparently do what they do, they're not a clear asset. Never mind that they have 15 years of experience doing it, if their value looks like primarily "opinion" or "process," it's not very convincing when it comes to opening the bank account.

Here are some of my suggestions for hard skills, that many interaction designers and usability folks could stand a more training in:

• Technical prototyping skills: Flash programming, javascript/ajax, css, html site design, Flex, Expression. Use of the tools that are used by developers, at a basic prototyping level, is a solid PLUS, because you can make things that everyone can see are relevant to the end product.
• Ability to make high quality visuals: Visual design training, skills with Illustrator, Photoshop, page layout applications, and other design tools for good looking mockups. Low fidelity may be useful and helpful with fast user testing and concept evolution, but you want to be able to make something your client or non-designer colleagues can't make. I know one case of a visual designer hired into an interaction design role because of the caliber of his mockups. Never mind how wrong this was for him and his manager eventually-- it got him the job to start with.
• Data analysis: For user research, learn some solid statistics. Even just pivot charts! Maybe some VBA for automating actions in Excel. Eventually, data mining, increasingly important with the large amounts of data around. (This is a career growth area all on its own right now.)

I'm with Scott that it's not a highly valuable proposition for a usability engineer to learn to do a cognitive walkthrough when they already know how to do 5 other methods for usability evaluation. But that's the wrong "hard skill," in my opinion. One who learns to make beautiful designs, which no one else could have made, will have a serious edge in their job role. Same goes for other skilled, niche deliverables. True story: A client with a budget problem told me recently that she had people in-house who could do an InDesign layout project, and that my value to her was in the data analysis and recommendations I could deliver for her that no one else could do. Good thing I'm working on that array of hard skills!

If only the university programs for HCI, UX, and usability thought like this, designer credibility issues would start going away a little faster. And performance evaluations for more designers could be done in concrete terms like how much good stuff we MADE during the design process, not how much we talked in meetings and if the other people there liked us when we did.

Why Failure Isn't Working for Me

A response to a number of posts and talks on failure recently, particularly this one by Michael Krigsman, Five Reasons to Discuss Project Failure, linked from Scott Berkun's blog.

Based on Krigsman's points, I wonder, Is failure really instructive? In my observation, there are a lot of people who don't learn from other people, or even hear what they say. Maybe they're "experiential" learners. Maybe they don't think like researchers--who are trained to build on other work--or they aren't smart. I personally hope they are genetic dead-ends. It seems a rare person who takes on board the lessons or advice from others; at least, it takes a listener, and someone who isn't arrogant.

On the subject of arrogance: A lot of organizations suffer from "not invented here" syndrome. They're in successful companies, don't see why they should do anything different, don't think they need to do other than tweak their current environment. And they're unlikely to hear from outsiders or new people. No matter how much they say they embrace change, learning, growth, new ideas... in general, in practice, it's not so true. Or it's better coming from someone internal with an extremely tailored message for that environment.

Do success stories really not work? The fun book Made to Stick doesn't entirely agree. One of my issues with stories of failure is that they end up being a lot like usability test results: Show you everything you did wrong, but provide no solutions for how to fix things. And it's hard to get the "right" lesson, because lessons are almost always hypothetical. IF we hadn't cut this feature, it would have sold better. IF we had done user testing earlier, we would have caught this. IF we'd had longer to develop the right architecture, this would be faster and people wouldn't be complaining about performance. IF IF IF. No one really knows, it's all just opinion.

If you don't understand your successes, you can't replicate them. And you can't use them to inspire anyone. You had a project team that cleaned up a disaster in record time and shipped something people loved. What was different about that team? What did they do better? Okay, it may be partly a comparison with the failure before, but it's surely instructive!

Root cause analysis of failure always has to skirt around sticky, difficult, subjective personality issues. This is often unproductive to discuss, and doesn't lead to positive outcomes. The people who name names look bad, and often suffer for it later. That guy who's the blocker for a zillion projects - everyone hates working with him, but he's critical path. Yes, it's been elevated to his boss before. VPs have been involved. Multiple VPs, on one occasion, during which ego bristles poked everyone. Nothing has changed. That guy is going to continue being a root cause problem on a lot of things. Talking about it means VPs and bosses are implicated too. And isn't it just personality issues for everyone involved? (Note, I advocate firing his ass, or moving him to another role; but I'm not in charge. The organizational dysfunction, which is usually just human nature, is in charge.)

Now, to switch onto on the subject of design failure. A hot topic among design gurus right now (see Spool on "Failure is Not an Option, It's a Requirement" and Scott's recent talk on "Why Designers Fail"), we're being told that good design involves failure and failure is important for innovation. I'd argue that designers themselves often know that design is iterative and exploratory, with important dead-ends that lead to strong results, but their managers or other necessary stakeholders don't know this. I hope Scott and Jared are being heard by these other folks, too, and not just by designers.

The people with the money are the ones that matter. They determine what constitutes failure, in the short term, like it or not. Many design consultants worry that client judgments don't take this iterative process into account. We are paid to be fast, creative, and accurate, all at the same time. Mistakes or dead-end work aren't seen as productive value for the money by many hiring managers. And their own sometimes flawed design judgments are at play in their judgments of our work. What should be a success is seen as a failure, through the squinty eyes of a manager that doesn't get it. It takes design talent to recognize design talent, yet most hiring managers aren't skilled or talented in this way.

This phenomenon leads to failures that shouldn't have been failures - good work was thrown out, bad work was done instead. Happens all the time. Happens on every dialog, every icon, every wording argument. Most of us live with failure very regularly: The little voice inside blaming us for not arguing the point just a little longer, for not standing up to that bully on the team about this important issue, for not getting to that other issue that's probably more controversial and yet more important for the user in the long run, for not making one more mockup to try to show how it could be better, or moving to Flash to show how it would work for real.... Oh yeah, we've got a lot of failure all the time. And our failures are much more visible than the guy writing some code on the backend that thrown an uncaught exception, which may not be noticed for years!

My point of greatest concern about these homages to failure right now is that they don't take into account power dynamics in most engineering organizations. (To be fair, Scott's talk does, and he found that managers who aren't skilled in design are a major cause of failures.) Designers are a minority discipline, and often we're trying to change processes and methods while also delivering on our work. We're trying to set an example with our deliverables and methods. The odds of success are already long against, given the weight of org history and number of people we need to convince. As minorities, we're often trying to argue for more headcount, and every misstep can be seen as another argument against hiring more of us.

Visible failures aren't generally a positive option, when disciplinary credibility is at stake.

CHI 09 Panel: Moving UX Into Strategic Importance

At CHI 2009, I took a lot of notes at the panel "Figuring Out the 'One Thing' That Will Move UX Into a Position of Strategic Importance." This is a rather random summary of it; see a similar topic in my post on User Experience Organizations discussed at BostonCHI a couple years ago.

Jim Nieters, Director of UX at Yahoo!, advocated speaking the language of business, and addressing business concerns in our design work and priorities. UX at Yahoo is now in marketing, after another reorganization. They will be providing input on the product funnel, helping to prioritize company efforts.

He reminded us that even at the executive level, it's a life or death battle, and everyone has someone to answer to at the end of the day. Convincing stakeholders of the design profession's value is less important than delivering as individuals; we need to be personally accountable for our work and stay focused on the right projects.

Regarding the standard issue of having too few resources: Invest in projects carefully. A team too diluted on too many projects can't be as visibly effective. Turn things down, and focus on the most important. Work on the revenue generators, and work with the business to understand the right problems and the solutions that can come from design.

During questions, he revealed that for products to move forward at Yahoo, they need "3 in a box": key stakeholders from Product Management, Engineering, and UX have to all be in agreement before work proceeds. Sounds good to me!

Laurie Pattison, Senior Director of UX at Oracle, was up next. Her message was that you get one chance, and have to sell yourself well. You only get one chance to make that first impression. At the management level, you have a calendar quarter to make an impact. Since you can't succeed at everything, you need to pick projects carefully, and provide business value. Businesses are in the business of money, after all.

As part of the sales process, deliver something other peers at the company can't do themselves. Make smarter wireframes, prototypes, or more attractive deliverables. Come up with innovative ideas that they can't think of themselves and the value will be clear.

Her example case study was a project to help reduce tech support calls. The team did simple usability studies and discovered that users couldn't find answers to items that were in the documentation. Their redesign put answers in context and reduced the need for the search functionality; the number of calls reduced as a result, and the bottom line was visible. The CEO was educated about the process and methods and it was a clear win for the team and their methods.

One questioner asked her why not just do this on every project, it's the standard research and design process. But resources limit what you can work on. "Pick projects that matter to the bottom line. You pick mind share or market share."

In a somewhat depressing note, several panelists agreed that your team (or your contributors) are only as good as the most recent success, that failure follows them around forever otherwise. "If you spend only ten minutes working on something because you don't have time, and it fails, people will remember you were associated with it and blame you. Better not to work on it at all." I'm disappointed when I hear this sentiment, given the recent discussions in other places about taking risks and embracing failure during design. I'm afraid failure may be a luxury for very well established teams.

Craig Peters, consulting as Awasu Design, argued that we need to pay more attention to the individual contributors in our organizations and their basic skills and effectiveness. "No matter what the strategy, if we don't think about the individual level interactions, the big picture won't be helped." He described a situation at Wells Fargo in which a UX team had reached a limit on their effectiveness; and he investigated and found that non-UX colleagues had had varying types of interactions with the team and found no consistency in their expertise or work. (I'm reading this in - Craig was pretty vague about the actual details of the findings and recommendations for improvement.)

During the questions, the panel and audience debated some on whether we count as a "young" field after 20 years of CHI conferences. Regardless, it does seem that different skills may be needed to convince different organization types and sizes.

Lauri represented the absent Killian Evers, UX Program Manager at PayPal, who argues for the need for program management skills in larger companies. Program managers can successfully bring metrics and rigor to UX and bridge UX and development. (I myself agree with the need for project management everywhere, but think that UX teams need to be able to work with software culture metrics, processes and tools, and there's no excuse for requiring a third party to manage this. But I may have misunderstood the points here.)

Some comments made during the question period, not all of which I was on board with:

• If your company doesn't value your contributions, move on to another one. Corporate Darwinism works.
• Don't waste too much time on ROI attempts. Testimonials from internal folks can go a long way. If you can find someone who needs something and you make an improvement, communicate it afterward with a story. Could even create internal portfolio of examples to help support your value.
• "If you're in a confrontation or argument, you're already lost." (I find this of some concern; many dev cultures produce lots of argument and confrontations, and if UX people aren't allowed to play in those, the field is not level and we're really handicapped.)
• The impression of many UX teams is "often you come in too late, you don't understand our jobs, our deadlines, our deliverables." My comment: Who's fault is this, actually? Bring us in earlier, etc.
• UX teams without domain knowledge can be seen as liabilities. Response: Get them educated about the domain, it's part of onboarding.

Finally, there was an acknowledged tension between the desirability of being an outsider brought in for point expertise ("like a lawyer") or a team member long term. These are obviously very different models, for staffing, for hiring, for seeking positions of corporate influence.

At this panel and at the one on "Fault Lines of UX," individual contributors asked how they can make change as single UX people alone in non-UCD environments. There were no simple answers for these folks. I particularly feel for the student who said to me after the Fault Lines panel, "I was taught UCD very rigorously in school, and I thought everyone did it. Now I find out most companies don't. How can I proceed, what should I be doing?"

An ongoing exercise for our profession, as mentors, educators, and colleagues... We need to help her.

So You Need to Do a Usability Test... But the Product So Obviously Sucks.

Most of us in interaction design jobs have been asked to do a usability test on something that we don't think is ready for prime time. You think it needs some design work before it even gets to users. The usual scenario is that your company or client is unwilling to listen to another stakeholder with design opinions (yours, or your team's), but will believe it coming from users. Either that, or they don't know what design is yet, but do have an idea that usability testing is a good idea.

Some strategies for turning this to your advantage, if your ultimate goal is being involved in the design, not the evaluation:

• Make it a test that's just Pass/Fail. Don't allow room for wiggling on the results, or you wasted your time getting them data they don't want to hear. Agree up front on what this thing is supposed to support, scenarios they think it has to handle, and be firm on delivering the news afterwards. It's too easy to get wishy-washy about informal usability testing, and leave room for argument, otherwise.
• Create alternate designs for use in the usability test. One of the best ways to educate the organization about the value of design is to DO IT. And to turn the test into an evaluation of multiple designs will help build your credibility and turn post-hoc evaluation into formative, and more useful, usability testing. Throw in some mockups at the end, or at the start, and ask for comments on those in comparison to the product that so clearly has problems, from your perspective.
• Write the report before the test. No, not as unethical as it sounds - you won't deliver it, but you're checking on your skills to predict what's going to be hard to use. So, you got all worked up about how this thing is hard to use, for obvious reasons; now check to see if you were right! Better yet, have more than one person on your team do their own reports, privately, before the test, and seal them up. Afterwards, see who was the best at predicting the disaster. Chances are, the users will fail in ways never imagined (thanks to Kevin Berni for this line), and you'll be a little less cocky next time this situation comes up. But if you get it all right, you're building your case and confidence for pushing back on this kind of request next time around.
• Ask others in the org to predict what might cause the users problems in the current design before the test. I used this tactic once when a QA organization felt the way I did about the usability of the product we were testing. I gave an award to the person with the most accurate prediction of user difficulty after the analysis. You want everyone in the company to know who has good insights into design and usability, right? People with good instincts need to be making the judgment calls, in the future. And you need to be able to illustrate that not everyone's opinion is equally valuable when it comes to making design decisions. Design insight requires talent and skill. This contest before the usability test helps identify talent-- skill development can come later.

Again, the only way you'll get involved in the earlier stages of design is if you show you can do that part, and what it entails. Make alternatives, and show why they are better. Next time, you'll be at the table for that part of the job instead.

CAD is Just a Tool: SolidWorks World 2009

The guest speakers at SolidWorks World 2009 really brought home to me how wonderful a rigorous design process can be - driving the product development, rather than struggling to catch up! There were 3 guest speakers that hammered on this: Sir Richard Branson of Virgin, and design managers from New Balance and Sony Ericsson.

Branson was charming and very sharp, as one might expect from his serial business successes. Rather than just a greedy mega-money maker, he came off as a human being, and reminded me of the late Randy Pausch in his advice to "have fun, or find something else to do." His approach to business showed him to be a design thinker from the get-go: His prime advice was to talk to customers and do a ton of research before you ever start making anything. And that the details will kill you: If your airplane seat is second most comfortable, you lost your edge. Hey, let's have standup bars so people can stretch their legs on long flights. Think differently, and solve real problems no one else has tackled!

Then we met designers from New Balance. Jon Hirschtick, a founder of SolidWorks, was shown on video interviewing them at the office first. I was amused by his physical dismissal of the pre-CAD design - he pushed it behind them, visibly, and wanted to get to the CAD part. Makes sense for a guy from a CAD company, but it's not the reality of the design process for the customers.

They showed many iterations with industrial designers sketching the soles and talked about "capturing the designer's vision" in the CAD tool - because that vision is driving their design. It's not the CAD tool or what's possible in it that's driving the product design! Few of their industrial designers use SolidWorks, they use Illustrator--noted by the Sony Ericsson manager up next to be "at least as complicated as SolidWorks if not more" (I say, YES - CAD manufacturers need to comprehend that other tools are professional caliber, too, and also quite complex). New Balance designers were shown drawing by hand on the interview video, as well.

CAD is the "middle part" of their design process. We saw nice rounds of 3D printing, and then an excellent example of making a mold in-house for a real prototype sole to glue onto the bottom of another shoe for field trials (see smooth-on.com).

The physical prototype on the shoe bottom was the "end" of that interview, but I shook my head sadly. The design process isn't over: They're field testing it now! There's a whole range of feedback to process, and design revisions to be made, based on how it feels to walk on! The design manager himself was wearing prototype soles on his feet during his presentation.

Oh, the frustration of getting the truncated design process, to focus only on CAD. Design is computer-aided, not computer-exclusive.

Then came Sony Ericsson. SE works hard to stay competitive in a crowded mobile market. In keeping with Branson's advice, they do a lot of research up front, and employ more cultural and social anthropology approaches than most companies. They look at consumer and design trends or "tendencies," to try to predict what will resonate in 2 years, to keep ahead. (Hirschtick acknowledged this was "a great model for all of us.")

Again, SE design starts in 2D with sketches and Illustrator. About half of their industrial designers want 3D CAD in hand, the others use other tools to express their vision. Their prototyping works the way software prototyping should, using less detail and fidelity initially, to get the egonomics and scale right. He talked about a "form language" they are trying to express first. The design teams produces product animations early in the process, to show to customers for input and feedback, well before development.

Like (most?) other designers, when asked what their biggest challenge is, they said, "Internal politics." Apart from politics, the other challenge cited was "staying fresh." Sometimes it pays to go off on a "no rules, no assumptions" design kick and get crazy. Question what makes the front different from the back of the phone, and why? Why should we sell through normal channels? What if we didn't??

Sony Ericsson wants tools for design that are very accessible, with fewer features for quick and simple use. Again, Photoshop and Illustrator are already more complex than most CAD tools, and industrial designers are experts with them. What I liked about this was the recognition that their design expertise and skill wasn't seen as useless simply because they didn't use CAD: It's the tools that have to speak to the designers better. (And, quite possibly, an employer that could make more time for learning more tools on the job.)

As a software designer who has spent more than the last decade trying to get design pre-coding taken seriously, I could only hope that the owners of software companies in the audience were thinking about how these successful businesses might teach them something. Important points, for me:

• Design requires a lot of customer input up front - take the time to do it, and do it seriously. Consider using skills from anthropology, sociology, or cultural studies while doing this - because those people see things differently. (They might not, for instance, shove the pre-CAD design behind them to get to the CAD part of the company process.)
• Design is iterative, even before coding/modeling: Review ideas, discuss them, and revise the design. For software, this can be a simple as mockups and sketches.
• Prototypes are a part of design, in that they give the designer and team something to feel and play with and revise.
• Prototypes should start low fidelity and get higher fidelity, as the design progresses. This means breaking the problem down into "first part" and "second part" etc. In software design, this is also doable, but rarely done and requires sufficient time and analysis.
• Tools of a variety of types might be wanted and needed. A designer might still be great, even if they don't speak your tool language. Can you tool be made to speak their language? Can you change your process to incorporate other tools and, even better, other voices?
• Good design can save you expensive mistakes - the CAD world has been preaching this for years, but few software companies have gotten it yet. Design it before you code it, if you want quality products.

Go forth and design better software, folks!

Brainstorming Doesn't Necessarily Help

At my last permanent job, an expert on brainstorming techniques came in to give a talk to the design and development managers. See, we had a phase of our dev process we optimistically called "brainstorming," the tiny moment in which ideas should be generated--regardless of plausibility and regardless of source--for the problems we wanted to address in the release. I think I invited this fellow in to talk to us all about tricks for doing this well.

Oh, my naivete! The response to the talk was not as expected. The last thing this development group wanted -- particularly the managers-- was ways to generate more ideas. Like many companies, we had way too many ideas, and way too few resources to assign to them; and way too many bullheaded managers who wanted to try it their way, not some peon's way.

Bob Sutton, author of the famous No Asshole Rule about which I've blogged before, has a nice post that gets at this issue and others related to brainstorming. It's must reading, amid all the talk about "innovation" and idea generation that companies produce today.

Some of the most relevant quotes:

But I assert that brainstorming only makes a difference if it is part of a larger create process, as you see at IDEO, Pixar, and other places that do real creative work. If the group doesn't do some preparation and doesn't use the ideas generated -- if they don't later battle over which are best, prototype some ideas, test them, try to implement them -- then it is just a bunch of useless ideas and perhaps a fun meeting. ... Brainstorming is something that doesn't work well in organizational cultures that are very authoritarian, where people view meetings as places to crush others and their ideas, where people have trouble with ambiguity, or where people do not feel otherwise psychologically safe.

At that old company, I think we changed the name from "brainstorming" to something dull but honest, like "idea discussion." And even that was optimistic in an unsafe, authoritarian, argumentative culture.

Women in Computer Science and Tech Jobs: It's Getting Worse

Two recent reports of women in tech careers that are not encouraging. First a link to a NY Times article, "What Has Driven Women Out of Computer Science?" (Thanks to @joandimicco from IBM Research for the link via twitter!) Women have actively declined in computer science programs over the last few years, shown in their chart: Women in other technical and engineering disciplines have increased, but not computer science. Why not? The article recaps theories including lack of computer games for women; "nerds" not being who girls want to be (hey, Willow on Buffy and Mac on Veronica Mars made girl nerds look just fine, if you ask me); and women going into interface design rather than programming - via other college programs rather than computer science. And a possible perception that there aren't jobs for women who major in computer science.

The Stanford Clayman Institute for Gender Research recently published the report "Climbing the Technical Ladder: Obstacles and Solutions for Mid-Level Women in Technology," based on study of Silicon Valley companies. The findings aren't unsurprising for any woman who's been working in computer companies for the last 10 years, even outside Silicon Valley. Some of the observations that rang true for me:

• "Women are more likely than men to perceive workplace culture as competitive. They do not see their workplaces as true meritocracies; rather, they see cultures that require connections to power and influence in order to advance."
• "Consistent with prevailing gender stereotypes about women’s abilities, women in management positions are perceived as less technically competent than are their male counterparts. This can create an environment where women are viewed (and can view themselves) as “not fitting in” with the company culture."
• "Survey results show that mid-level men and women strongly value teamwork. Further, men and women perceive that collaboration is key to success in technology. However, mid-level women see a sharp divide between cooperation and competition at their companies. Mid-level women describe this gap as being especially acute during the promotion-review process, where they find existing promotion and evaluation practices reward competition instead of collaboration."
• "Mid-level women are more likely than mid-level men to suffer poor health as a result of work demands."
• Family responsibilities remain a significant problem for women - staying late and flex-time are necessary and often difficult for women to arrange. Women are far less likely to have a partner at home who can manage the family life for them than men are. Men also perceive a "family penalty" in the competitive workplace.

One of the recommendations is to provide opportunity for ongoing technical for all mid-level staff, to allow men and women to retain and sharpen their technical skills, and as a side-effect, give them more networking opportunities. I would agree whole-heartedly; most companies don't invest enough in ongoing skills maintenance and new skill development, for male or female staff. (As a consultant, I'm responsible for my own development, and I've found it amazingly liberating not to have to ask if I can take a course or go to a conference!)

And then there's the supposedly obvious, but rarely acted on: Provide a workplace that shows it values teamwork, rather than competition (most company performance evals and bonuses are handled competitively). Cultivate a workplace with flextime and reasonable hours. Have a diverse executive staff and board (not just a female VP of HR), to signal respect for diversity and also help change the culture from the top down.

At a lot of companies where I've worked, it was well-known at the mid- and sometimes ground level that executives didn't "get along," that there were power games and competitions rather than cooperation and teamwork at higher levels in the company; that long hours were an unspoken rule for success on impossibly demanding jobs.

Most of the time, I just think women are smarter in opting out of the whole tech management game. So why is there any mystery about lack of women in technical management? And in computer science departments?

Pixar on Successful Creative Teams

I've seen this on a number of sites now, but it's rich enough to keep passing on. Requiring payment from HBR, the article is How Pixar Fosters Collective Creativity, by Ed Catmull. Some of his points are business management truisms or even cliches, but as with most management-related things, it's not the concept that's tough, it's execution that's tough. Especially in a creative environment.

On People. Most of his points here are about handling diversity and collecting lots of input from lots of sources. Less dictatorial hierarchy, more feedback and empowerment of teams to decide how to handle the feedback. Some good quotes:

• "If you want to be original, you have to accept the uncertainty, even when it’s uncomfortable, and have the capability to recover when your organization takes a big risk and fails. What’s the key to being able to recover? Talented people!"
• Creativity isn't about finding one big good idea. "However, in film making and many other kinds of complex product development, creativity involves a large number of people from different disciplines working effectively together to solve a great many problems."
• And yet, talent isn't evenly distributed, he acknowledges. But this does not mean anyone tells anyone else what to do - a creative team gets input and makes its own decisions about what to do with it. A "brain trust" of the truly excellent people with track records can be called on for input when teams need help, but they don't dictate anything. Ironically, this frees everyone up to talk and listen more effectively.
• Having talent on staff isn't enough. "What’s equally tough, of course, is getting talented people to work effectively with one another.That takes trust and respect, which we as managers can’t mandate; they must be earned over time." If people trust each other, they can be less polite in meetings, apparently. Ideas are under discussion, not personal status and power.
• "An important lesson about the primacy of people over ideas: If you give a good idea to a mediocre team, they will screw it up; if you give a mediocre idea to a great team, they will either fix it or throw it away and come up with something that works." I note, they can only do the latter if they are given the freedom and authority to do something radical.
• Pixar's "small incubation teams" that consist of a director, a writer, an artist, and storyboard folks. Whereas in my experience most software incubation project teams are weak on the creative staffing and very heavy on the implementation side, not a good balance of skills for the stages of creation.
• It's critical for an incubation team to function well internally: "During this incubation stage, you can’t judge teams by the material they’re producing because it’s so rough—there are many problems and open questions. But you can assess whether the teams’ social dynamics are healthy and whether the teams are solving problems and making progress. Both the senior management and the development department are responsible for seeing to it that the teams function well." I note: presumably there are non-subjective, non-gossipy ways to evaluate social dynamics. I've seen this rhetoric applied to very bad ends at one company.
• Catmull says, "Treating one another as peers is just as important as getting people within disciplines to do so. But it’s much harder. Barriers include the natural class structures that arise in organizations: There always seems to be one function that considers itself and is perceived by others to be the one the organization values the most." Overcoming that is a huge management and process challenge... Catmull seems to be saying that time together helps, but I think the deliberate creation of well-rounded incubation teams is a big aid in changing these biases. None of this "we'll add a user interface designer later" stuff, like you hear from the software company incubation teams!
• Newcomers to an organization can be threatening, because of the "not invented here" syndrome that they may cause with their new ideas. But constant change, not taking success for granted, and acknowledgment of mistakes made can make newcomers less threatening to current employees, he says.

On Processes. So they've got a good staff who encompass both technical and creative backgrounds, now how do they keep it all working and on track?

• Dailies are watched, by lots of people (the animation industry version of footage of the day). Sharing unfinished work and inviting comment helps creatives get over the fear of showing the incomplete, and that in turn means work isn't wasted if it's on the wrong track. I note, a healthy culture of regular software design critique does not exist in most software companies (barriers to this are a political subject for another time). Agile development processes seem to be better off in this regard than waterfall-like models of development: producing and showing in-progress work is critical in that methodology.
• Input on work-in-progress is collected widely, because the work needs to be great before release to the real world. TiVo executed on this principle when I worked there, too; employees all used the beta software at home and we had to like it, too.
• Post-mortems are done regularly. Rather than just "what went well and what didn't go well," his suggestions include having groups list the top 5 things they'd do again, and the top 5 they wouldn't do again. Now, in a creative environment, people often assume that you can't evaluate the creative process. But Pixar uses data to ground the post-mortems (making me wonder how they track it, who does the analysis, etc). "Most of our processes involve activities and deliverables that can be quantified. We keep track of the rates at which things happen, how often something has to be reworked, whether a piece of work was completely finished or not when it was sent to another department, and so on. Data can show things in a neutral way, which can stimulate discussion and challenge assumptions arising from personal impressions." The fact of being "neutral" prior to interpretation is important, from my perspective. Using data in a post-mortem shouldn't lead to finger-pointing so much as conversation about root causes for data peaks and valleys.
• Management challenge for their corporate processes: "Clear values, constant communication [across and around hierarchy], routine postmortems, and the regular injection of outsiders who will challenge the status quo aren’t enough. Strong leadership is also essential—to make sure people don’t pay lip service to the values, tune out the communications, game the processes, and automatically discount newcomers’ observations and suggestions." And I say: Easier to say than to execute. Leadership is so rarely evaluated well, at any company.
• Catmull says they keep up with academic research. Being cutting edge means staying on the bleeding edge, and being able to attract people who want to work on that edge, too. Why do so many companies sneer at research and research conferences?

It's a good article, and I think worth the $6 cost. It does leave a few questions I had unanswered, like how they handled the massive overtime and repetitive stress injuries he describes during one "failure recovery" period.

As a final point, something I've said here before: Post mortems may be unpleasant, but understanding how a team was successful is just as important, or more so, than understanding how it made mistakes. I don't think most companies use the positive particularly well in setting up their downstream teams. I think Pixar probably does, to have such a string of successes.

Good UX from Happy Employees?

More on creating good user experience from good organizations: a short blog post by Adam Richardson at CNET entitled "Good user experience comes from good employee experience." He points out comments from airlines with happy employees who convey happiness to their customers, like SouthWest and JetBlue, as opposed to American and other airlines with rather surly, unhappy employees.

Over the years, whenever reporters would ask him the secret to Southwest's success, Mr. Kelleher had a stock response. "You have to treat your employees like customers," he told Fortune in 2001. "When you treat them right, then they will treat your outside customers right. That has been a powerful competitive weapon for us."...

"There isn't any customer satisfaction without employee satisfaction," said Gordon Bethune, the former chief executive of Continental Airlines, and an old friend of Mr. Kelleher's. "He recognized that good employee relations would affect the bottom line. He knew that having employees who wanted to do a good job would drive revenue and lower costs."

I've worked at more than my share of offices in the past dozen years, and I think there may be something in this. Watch out if you've got customer-facing employees who don't answer internal colleague emails, are rude or curt to peers in their organization, promise stuff but don't deliver, hold onto information for their own advancement rather than the sake of the team. You probably also have a customer relations problem at the very least. Is this person answering customer email or calls politely? Sharing customer problems with other people who can help? Looking for help in solving the problems that the customer has?

Then look at the tools your employees have to use... if you find crappy tools in use internally, then double check that this isn't exposed to customers in some form. The MathWorks has an internal usability group that works on design and development processes for corporate tools. I think it pays off in many ways, not all of them related to internal efficiency. It's a sign of respect for your staff to give them the best tools to work with.

If you hire well, trust your employees, and give them a reasonable job to do, they can be your strongest advocates for hiring, referrals, and posting nicely about you in their blogs! And they'll go the extra mile on the job. Besides, a lot of your employees, past and future, are customers too.

Staffing for User Experience: What Can Go Wrong

You decided to hire a bunch of interaction designers and "user experience" people to improve your product, service, or general business from a customer-focused design perspective. You were lucky enough to find some experienced folks, who've proven their worth at other companies.

It may not be obvious, even if you hired evangelists to help convince the rest of the company of their value, how many ways you can still get it wrong AFTER the hiring. It takes more than headcount! Your new people need to be empowered to make a difference on the product. The issues below amount to (a) cultural and process openness around adding more design into the team software mix, (b) how the dynamics of decision making in your company can impact design for evil rather than improvement.

1. Did you hire the right people? Let's assume you did, but a couple reminders here: Your biases and your interviewer biases may be some of the problem you are actually hoping to solve. Did you hire looking for collaborative people who get along with everyone (and cave in an argument, in order to preserve the peace?). Did you hire people who do evaluation of other people's designs, or did you hire designers? Did you hire GOOD designers? (Would you know how to evaluate their design skills?) What kind of power dynamics are going on with the interviewers you lined up: Are any of them threatened by the whole idea of outside new people influencing the product? Are they looking for "yes" people or new ideas? Remember they may say something quite different from what they really secretly feel after 3 beers.
2. Does anyone other than development or product management get a say in how things turn out? How much will these expert new hires be heard? A development manager who is used to being in control may not like having to invite someone new to his planning meetings; a product manager may be unhappy if your new hire questions her market research based on usability data. How much of the time will your new staff be looking for data and ways to convince people to listen, versus actually making an impact on the product? If you had to hire evangelists, you're set up for this problem from the start - expect a lot less productive impact on the product from your new hires, and a lot more organizational time suckage.
3. Do you have ugly cultural problems you don't know about: Prejudice against non-"technical" input, assumptions that women aren't as smart or good at software or technical decisions. Women are more likely in UX/design than they are in engineering jobs, even if they started in development positions. Check out the dynamics at the whiteboard here, a scene I've watched many times...
4. Will other people take UX team work as optional input to modify, redo, ignore? Does someone else secretly want their job; not realize it's a separate real job in the process; or actually HAVE their job on the project. I've seen teams where two people were meant to be the customer design input, and didn't agree, and it led to time-wasting fights for the whole group around them, with people taking sides on issues and duplicate work being done. I've seen plenty of QA teams forgetting about the spec, developers not reading or forgetting about the details, and other errors of omission that prevent design from being fully effective.
5. Do you have decision processes that are functional in your company - or do you regularly have meetings that bog down with "votes" or too many inputs, and open more issues than they close on a regular basis? This environment won't scale well to adding players especially in design discussions. (If your team is arguing with the designer about whether to use radio buttons or checkboxes, you have a dysfunctional decision process which means you are wasting resources and time.)
6. Is there enough time in your shipping cycle to actually add design as a separate process? Not a trivial question to laugh off; mistakes made early, in requirements and design, are much easier to fix than anything after some code has been written, assuming you have processes in place to catch them before you get too far. This well-known fact doesn't make most companies happier to slow down. I think it has something to do with what's seen as "progress" and "work" in the development cycle, and the glorification of risk-taking that exists in so many software companies that have money to burn.
7. Does your company regularly bite off bigger projects than it can deliver in a release cycle? These giant projects are unlikely to be high quality when they ship after all the cuts and compromises are made to squeeze them in. Partial functionality is usually worse than no functionality because your company looks like it just didn't get what the customers were asking for. No UX person can entirely save you from this, but a good one consulted and involved in the process from the start might keep you focused on the must-haves for minimal usefulness.
8. Have you got project management to track team issues and milestones and make sure things aren't grinding down to a halt, or loaded with bugs and unresolved issues. Are they also concerned about tracking design stages, and blocks to those deliverables, rather than just safeguarding developer efforts? (Before you say "of course," maybe you should check with the designers.) These things can add up and make everyone less useful in the end; software is a team effort.
9. What will you do with the designs your designers produce -- they can make mockups till the cows of management come home from their offsite, but that doesn't mean it's useful in your process.
10. Do you have your new UX people spread too thinly to be effective -- with an average of 20 developers to one designer (who is shared over multiple projects), there will be a large number of meetings they miss; bugs they don't have time to provide input on; bugs they don't have time to file; builds or releases they didn't get to see closely enough to catch last minute errors; bug review sessions they weren't at to push for the usability/experience bugs; doc they didn't look at to see if it covers the main use cases and important details; customers they didn't have time to call or visit. And spec modifications they couldn't keep up to date. Their morale will suffer proportionally to the things they don't have time to do that decrease their effectiveness.
11. Is the UX person involved early enough to be (a) able to influence the crucial early decisions (b) and to be a true team player in the project, rather than an end-game consultant check-mark on your process? It's often in an overloaded (dysfunctional) environment that the designer or usability specialist is involved only at the end of the cycle to "review" and "bless" things. If you're tired of hearing from your new hires that they didn't know something had been decided, or that they wish they'd been consulted earlier, then you've got this problem headed your way. Remember it's much harder to effect change after code is written! And they want to be able to make an impact, otherwise they will be wasting their skills.

There are lots of ways to miss, even with good staff. I've been in good teams and bad teams for design process, but seen a lot of these failure modes. I'm keeping score of how many companies have teams that argue with their designer about radio buttons versus checkboxes, wasting valuable time in their cycle. The stats aren't looking good. But if you take care of your processes and oversee design as a separate stage and responsibility, your company can be better than that.

Let Your Designers Design!

We all know now that good design is a crucial element in a crowded market. But just because people in your company have strong feelings about design, doesn't make them good at it. Some of their ideas may be good, but that doesn't make them good at executing either. In the worst cases, they both think they have good ideas and think they can execute, and they can do neither. (Remember, incompetent people don't know they are incompetent.)

Signs of the problem in your org:

1. You have designers on staff, but they're demoralized and frustrated. Designers are a special breed of person, more likely to leave when they can't accomplish what makes them tick than many others; they're driven by their skills and talents more than promotion opportunity inside a company or a domain in which they work.
2. Consensus-driven culture has ground projects to a halt. You can't break out of decision-making meetings with a clear goal, and there are too many cooks involved. Because the designers aren't empowered to make the final design decision, and other (incompetent) people are weighing in or fighting with them. (See Scott Berkun's recent take on this, and an old take on why products don't end up usable that covers all this organizational stuff too.)
3. You may have a lipservice executive level belief in design as important (ever since Apple made it profitable), but you have no headcount for it, and no org process for it. There are no goals in the marketing pipeline that focus on it, there are no metrics to measure it, and it's no one department or person's job. It's handled diffusely, and not managed effectively.
4. Secretly, you or other middle-level managers think design is a technical thing, or the "fun" part for the technical folks, and it's best handled by developers as a kind of prize for the good ones. Don't bother trying to hire in this climate!
5. Final decisions about what gets in the product and what's shippable are based on criteria or opinions that don't know much about how customers respond to your stuff. Bugs that in a one-in-a-million system configuration cause a crash are prioritized about correcting a layout problem that makes you look amateurish, or a typo that makes you look like a busload of idiots.
6. You think it's all about the documentation - the customers just need to read more.
7. You outsource all of your visual design, and that's what you mean by "design" anyway.
8. You didn't realize people get degrees today in usability, human factors, interface design, interactive design, etc. In these degree programs they learn the correct ways to collect and interpret data, deliverables that communicate at different levels of fidelity, how to go from abstract to concrete, how to validate designs, and how to prototype. Corollary: You also think design is work that's "obvious" and easy, probably also because it doesn't involve writing (much) code.
9. You don't have actual project managers on your staff. You make it someone else's job, usually a development manager's; this means design as a phase and design deliverables are not scheduled and monitored in the way that code production is. Instead, it's all "where's that damn spec, we need to start making this thing."
10. Your designers are actually trying to steal the project management, so they can get some control over the process, but this is leaving them too busy to actually do design. They schedule meetings to get stakeholders together, they try to get the PM's to articulate what the heck the requirements are, they hire visual designers, they call customers... they never actually get to design, except after hours.
11. You've got innovation projects going on in your company, but there aren't any designers working on getting things right from the start. (Chances are, they are too busy with 9 and 10 to be contributing even if invited.) But basically you feel that design is "icing" to make it look pretty after the big ideas are implemented. You think the real breakthroughs come from technical ideas, not ideas that come from watching people work or new interaction techniques or novel workflows. Never mind how expensive it is to get requirements wrong up front and have to "fix" things later. (There are any number of software studies on this, drop me a note if you want refs. I've seen startups go under from this, before they even got out the door with their product.)
12. You've got internal folks like usability testers who are told they "facilitate" group processes but aren't empowered or able to make overruling design decisions. This is explicit support for consensus design or committee design, dangerous when everyone else is opinionated but incompetent.

Okay, I admit it felt good to get this list off my chest today. It's not the last time you'll see the subject cross this page. Let's hear it for design moving up the org chart; and for middle management and technical management understanding there are skills that might help with product big picture and end-game success!

Open Source vs. Organizational Code

An interesting, free article from Harvard Business School working papers: Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis (scroll down for PDF link). From the abstract:

Specifically, products are often said to "mirror" the architectures of the organizations from which they come. Such a link, if confirmed empirically, would be important, given that product architecture has been shown to be an important predictor of, among other things: product performance; product variety; process flexibility; and future industry evolution. We explore this relationship in the software industry by use of a technique called Design Structure Matrices (DSMs), which allows us to visualize the architectures of different software products and to calculate metrics to compare their levels of modularity. We use DSMs to analyze a number of matched-pair products--products that fulfill the same function but that have been developed via contrasting modes of organization; specifically, closed-source (or proprietary) versus open-source (or distributed) development. Our results reveal significant differences in modularity, consistent with a view that distributed teams tend to develop more modular products. We conclude by highlighting some implications of this result and assessing how future work in this field should proceed, based upon these first steps in measuring "design."

I've seen work on this subject before (including similar diagrams that show code module relationships)-- not usually in business press, although it's nice to see this get a wide audience. Recently I read Becky Grinter's essay in HCI Remixed which reflects on Parnas 1972's "On the Criteria to Be Used in Decomposing Systems into Modules" and on Conway's Law: The structure of the code mirrors the communication of the organization that developed it. Or lack thereof.

More than that, I'd say the UI design and the broader corporate outside facing design often reflects the organization's internal structure and different goals. Marketing groups that don't talk to engineers, executives who don't get along, customer support and sales who don't speak -- these things all hit heavily on the face that a customer sees for the company. All of which can be reasons why "User Experience" as a group can't live low-down in any one part of a company, especially a big one.

More personally, I've started using R, an open-source competitor to MATLAB, and wondering about this stuff as I try to track down the open-source resources I need. I've been enjoying ramping up on R despite finding the documentation available and code quality of some libraries very hit-or-miss. MathWorks's doc team and their demos are one of their strengths. Regardless, R has a growing number of books and sites, and I've learned some simple concepts faster in R than I ever did for the same concepts in M-code. In many ways, I prefer the language to M, despite my belief that open-source usability is generally very poor [here we might have a discussion about usability of the language itself, for different tasks, versus that of GUIs or tools available for programming support, but I'm still thinking about the topic].

In short, R works; plus it's free, and it's powerful and extensible. (For just how free is free: compare about $4K for what I'd need for statistics and database access plus some reporting, with $0K, and that's pretty free.) I wonder how the code compares to to MATLAB's.

2007 Usability Salary Study

The results from the 2007 Usability Professionals Assoc. salary survey are now available to UPA members. I am one, so I'm posting some highlights plus some new charts I made from their numeric data. Sadly, I can't get the raw data to try anything very interesting. A caveat first: The "usability" profession is only a sample of the jobs that relate to interface design, customer experience, interaction design, and other related titles. The survey reflects this (as you'll see) but does not necessarily reach all related disciplines. I'm particularly suspicious of the low numbers who responded from the US west coast, and suspect this is to do with general organizational regional politics (who belongs to what, who reads what, who cares). California in particular might bring up some of the numbers, from what I know of their salaries and consulting rates.

In general, salaries have gone up since 2005 by about $5000, most markedly outside the US (UK and Canada) and for women (who are, however, still paid less than men). Consider me irate that women aren't as valuable as men in most organizations, for most jobs, except secretarial.

Some charts: there are linear relationships between salary and experience and salary and education level.

I don't know if there is any additive effect; for example, if you're me and have a Ph.D. and 12+ years experience, do you get even more? (That is, if you're not a hand-to-mouth consultant like me.)

There are interesting relationships between job title and salary. "Directorial" are the highest job bin reported, which is disappointing (in that I keep hoping there will be C-level design folks soon). "User Research" titles are the highest paid individual contributors. This makes sense to me if UR jobs are being filled by advanced degrees. I feel they should be -- statistics, experimental design, ethnography, strategic input -- these are not activities to hire a junior usability testing person to perform. And I think the software industry understands this more and more, based on the job ads I see. Note that "usability" as a title component is now outpaid by "user experience." There were more respondents with the title "user experience practitioner" than for any other job title. This is good news, and appropriate; if a company understands that there is more to a good user experience than making it usable, then there is more involved in the job description and hiring criteria and it's also worth more. We're moving forward! (Even if women still lag behind.) Related to this, I'm personally interested in the chart of job "activities" practiced by the survey respondents. Usability testing is still way up there in frequency of mention in this surveyed pool, despite the shift in job titles. Design prototyping is close, but not at a par yet. I'm sorry to see this, since I don't think design should be done by non-designers and I don't think UX folks should be evaluating design produced by non-designers. I'm disappointed by how low quantitative activities and market research fall, but I assume this will pick up some steam as more senior quantitative user research folks are employed by UX departments. I'm especially disappointed by how low "requirements gathering" falls -- this being the number 1 cause of poor quality downstream, as found by many studies of root causes of software defects.

For a change of topic: In a sobering news story for those of us still trying to get design taken seriously as a strategic role, IT development salaries are projected to soar in the next year, well above what the data in the UPA survey shows. Read about it here.

Consumer Design is Easy?

Steve at tingilinde sent me a link to David Pogue's NYT piece on design flaws in digital picture frames. From the intro section:

"We learned deeply a few hard lessons," he said. "Consumer electronics is a very difficult business. It's difficult to get it right." ...

Maybe this particular guy is rightness challenged. Or maybe he meant that getting things right takes time, money and effort, which is true.

But it sounds like he's saying that it's hard to know what's right in product design, and he'll never convince me of that. A ten-year old could have identified the design flaws in the frames I tested this week.

I don't agree on all points -- Some of the design flaws he identifies are tricky "icing" on the consumer cake that it takes a clever designer and a budget to go after: like having a little pocket on the frame back for a remote control. Nice to have, but not mandatory, even for a good consumer experience.

But getting things right does take time, money, and effort; as well as "big-picture" design management of the sort lacking at all but few companies. Someone needs to remember the people you're designing for, and to represent that by stepping backwards out of the details of schedule and bug counts and putting into perspective: "...Hey, can your Grandfather use this for the baby pictures you're sending?" It's the responsible executive's position to make the call to change the schedule to accommodate the experience-breaker issues that will threaten you in a crowded market, and to champion processes like in-home user testing as part of the design cycle.

Kodak, who comes out pretty well for their frame design in his piece, hires interaction designers, although I don't know if they have a Chief Design Officer. So why hire an interaction designer instead of, say, a 10-year old? Because most 10 year olds aren't up to arguing with project managers and engineering schedules, and generally keeping their head both in the gritty details and well outside, for that important user perspective.

Pogue's piece is still good and also funny. As a former TiVo designer mystified by the crapness of most "consumer" electronics design, I especially liked this one:

Question 10: Which is the right way to label the jacks and buttons: White lettering on black (or vice versa), white on white (Momento), or with no text labels at all (eStarling)?

We did think of this at TiVo (of course), but I still wish we had added a little LED flashlight dongle to the back, since there's always bad light at the back of your cabinet!

A Look Inside SolidWorks

SolidWorks World, the annual user convention for SolidWorks CAD users, is going on now in San Diego. I'm consulting with the company, and have been doing usability research out here. (Rather strangely, I appeared in a photo posted by one of our blogger users here. The gentleman I am talking too was just made extremely happy by a brief chat with the founder of SolidWorks, who remembers his name every time he sees him.)

SolidWorks' latest release featured some major changes to the UI, which caused a bit of a ruckus among the experienced users. Matt Lombard, author of the SolidWorks Bible, is one of the ruckusers. Along with posting pictures of me (hah), Matt also just posted a YouTube interview with one of the best guys at SolidWorks and one of my clients there, Jim Wilkinson. To see some inside scoop on how the company works, you can watch it on YouTube linked from Matt's blog.

A final note: It's a credit to SolidWorks that someone like Jim exists there and has authority. Not only is he a good manager, but he's universally well-respected AND well-liked by everyone who meets him, internally and externally; and he's active in the user forums answering customer questions on top of his ever-expanding day job. Jim saw a need for a usability team long before most CAD companies found out such a thing exists (for the rest of them, that was only 2.5 years ago). Kudos to SolidWorks for having such great employees and managers. It explains a lot about the product success.

Designing Your Home Page

Kicking this one off, here's a good article by Joel Spolsky about the design of the product home page for FogBugz, which nicely spotlights the badness of committee decision-making in design. They tried to achieve too many things with too much input, the results frayed, and finally they [he] had to make the tough decision to start over and stick to a single unified vision with fewer "votes" on the matter. You can track this in the mockup screenshots.

Joel also makes a good point about the difference between the company page and the product page in terms of their goals. Nice willingness to go with entirely different styles, as a result. A brave decision!

I've been involved in a few home page design discussions the past year of consulting. They tend to be wicked problems (i.e., ill-defined, messy, and circular). Some of the reasons for this:

• There may be a difference between who you are and what you do, which may be important and hard to describe. Or hard to recognize.
• There may be a difference between who you WANT to be and who you are. This is hard to design for, because when you stray from what you are, you tend to confuse people.
• Conveying who you WANT to be in a clear fashion can only happen if you have a clear idea of who you want to be, and test your methods of conveyance on people to see if it flies. This is different from usability testing as usually understood.
• A bunch of company stakeholders who disagree on these things (who we are, who we want to be) can't communicate this to a designer very successfully. Design will then take a longer time, with more iterations, and may turn into a committee consensus nightmare.
• Design directions can be contradictory -- sometimes you can't say two or more complicated things, and you can't do both well enough to succeed at either. Let alone 10!
• If your business is confusing or going through a change of some kind, it's almost inevitable that the design reflects this, without a very strict control on it. No designer will succeed in clarifying confused input when the underlying problem is actual confusion. The designer may see this going on and be able to point it out, but that won't get it solved. The problems may be too high, too deep, and too wicked themselves. Solving them is much harder than the simple design problem at hand.

One client was working on a new project that was barely outlined in a development spec. He asked me "What do we do for our home page? We're really worried about that." It was premature for this, because most of the business plan didn't exist yet. The design input they REALLY needed was "Your business idea is a little too complicated right now. Can you simplify it first? Here are a bunch of others in your space with successful 3 bullet explanations on their home page. Can you meet that level of simplicity?"

Sadly, most designers aren't in a position to spur you to clean up your entire business plan. Or to make it clear that this might be needed because it's hard to make it sound simple when it's not. (At least, without lying.)

I think design is a strategic activity - requiring hard, brave, high level decisions in order to direct the minds and hearts of customers; and a creating a good business plan is therefore partly a design activity. To create a business that is clear and attractive to prospects, and therefore portrayable as such, requires high-level decision making inside a company. If more business leaders thought like designers, or more designers were in business roles, the execution of the home page would be a lot simpler.

Food for Brains

It's been a tough week - minor road accidents in snow, encounters with consultants that earn $2500 for a few hours of phone time [I don't earn this!] - so here's venty post on something that bugs me: People with bad memories. I don't mean bad in the sense of "I lost my keys again," more in the sense of "Weren't you going to schedule that meeting?" No, you were, you said you would! Why do I suddenly feel so defensive, when I did nothing wrong??

Any number of excellent books have been written about project management and scheduling, but few of them confront this phenomenon head on, and I've now seen it at a bunch of companies. Someone important, or even just useful, can cause a lot of damage by having a bad memory. If they're a manager, it might become their employee's second job to stockpile email in case they need to "prove" who's mistaken at review time. If it's a peer, they don't pull their share of the work because they conveniently forgot to do most of it and someone else has to, or some schedule slips. This might be passive aggressive (if they're not a psychopath or an asshole), but since it's the holidays, let's consider that it might be a medical problem. Maybe they're eating badly?

A few suggestions for coping: Start ordering in veggie platters. Take them out for sushi whether they like it or not. Leave them Secret Santa Ginkgo Biloba supplements by their monitor. And finally here's a list of some nice articles from Psychology Today on food for your brain, which I rather enjoyed:

• A Taste of Genius
• Top Ten Smart Foods
• Eat Drink Man Woman (on foods for long lives)

Happy holidays, and eat better! [Edited to add: Consider hiring a chimp instead if your team mate or manager can't remember things after eating better.]

BostonCHI Panel: User Experience Organizations

There was a good cross-company discussion of organizational models for User Experience (UX) teams at Boston CHI on Sept 11 (check that link for full bios on the speakers). Companies represented by managers, directors, and VPs of UX: EMC, Oracle, Symantec, and Fidelity (with Sun and others in the audience).

Some themes that emerged:

• Need to maintaining standards and cross-company guidelines requires having high level management or at least view that spans the organization — with creative org charts and management across sites often happening as well;
• Difficulty getting enough staff to meet demand (settle instead on doing fewer things well rather than over-extending, and making the case for more people that way);
• Organizations have more interaction designers than usability, by 2-to-1 or more (again, a separation of design from testing roles);
• Assumption that "good user experience" is no longer something that has to be argued for, it's seen as an obvious competitive advantage (the only mild disagreement from Fred at Fidelity);
• Engineering pay scale for their UX staff (common except for Fidelity, where pay didn't come up — since Fidelity hires a lot of low-paid contractors, I suspect they don't pay their internal folks by engineering scales ).
• Get the design right up front, or pay for it later. Very broadly assumed to be understood here!

Less obvious themes that resonated from my past few years in the field as manager and individual:

• UX people can get bored working on the same thing, or the thing with too small a scope. Being able to move across projects will help with this issue.
• Not having to be accountable for all your project time means being able to do cross-product things and user studies that will improve design work downstream (it doesn't mean goofing off on long lunch breaks!).
• Long-distance management working remarkably well with the right management attitude.
• From Oracle, being responsible for good products, not just good specs (teamwork in an organization). [Adobe, while I was there, was terribly concerned with the checkoff that UI had delivered a spec on time and were not "blockers" on the product schedule; this was an ill of centralized UI management that wasn't very flexible in the development process or in terms of their deliverables on each team.]
• Value of being managed and reviewed by people who know what you do, not being dependent on managers who don't understand your process, contributions, and work products.
• Investment in prototyping and development.

Relevant past post on my blog: my study of the job postings for UX folks on the BayCHI mailing list for 3 years. Oracle, Symantec, and EMC are on the graphs, but not very high in terms of number advertised for relative to overall size of the company. Fidelity doesn't appear at all, but it hires mainly in MA, I believe.

I have a full report (albeit sketchy) from the panel and the questions posted here. Scroll down to get past this recap on the top!