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.

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.

Animated Drawings (and Meta There-upon)

Today I ran across a whole class of items that are oddly similar, in different places: drawings animated, in not your usual way.

First, "Notebook," a video of a world in which paper and books are computers, in unexpected ways. What you draw is what you click on. It's more art than engineering, and I like the whimsy, especially the toaster.

Second, a wonderful new game you have to play to fully appreciate. CrayonPhysics Deluxe is remarkable. The demo video might look too good to be true, but it really does work exactly as shown, and I found myself grinning a lot as I played. Great for kids and casual gamers like me, it's forgiving, mellow, and can be played in short chunks. And I'd rather be playing it right now, to be honest! (I gather the iPhone version is not so impressive. You really need to be able to draw and immerse yourself in the screen world for this.)

Crayon Physics Deluxe from Petri Purho on Vimeo.

Last was a video I re-ran across while looking for some tips on animating stick figures. I pretty much stopped wanting to animate stickfolks after watching it: in case you haven't seen it, it's Animator vs. Animation. The sequel (Animator vs. Animation 2) is even more extreme, because the stick guy takes on the entire Windows OS. Satisfying!

My (Renewed) Love Affair With Amazon: Video and Kindle Books

I remember when people sniffed at the idea of Amazon being more than books. When Jeff Bezos reinvested all his profit into opening up other shops, people said, "Diluting the brand?" and other naive things--I might have been one of them.

This week, I looked at my credit card statement and realized they were getting a bunch of my money. More than the usual regular book purchases for work and play. And I wasn't unhappy about it. I had a warm glow when I reviewed my charges for movies and other digital downloads. Amazon has become my main digital content provider. Other people are buying from iTunes more, but I'm a movie/TV/book girl, and Amazon has me covered right now!

I got two pieces of gadgetry this year that reinvigorated my love affair. The first is the Tivo Series 3 (HD), gotten in expanded and discounted form from WeaKnees.com. (Another highly recommended company with good service, by the way!) As you may know, I was a TiVo UI designer way back whenever (version 2) and still own stock and love for most things TiVo. The Series 3 works nicely with my Verizon FIOS which feeds me good bandwidth and HD TV.

Back to Amazon. The other day my cat unplugged one of my TiVos and I missed an episode of Chuck. Remember the days of looking for friends who recorded stuff? I could've found it online in various ways for free, but it was convenient to just browse for it on Amazon Unbox via the TiVo, from my couch, and order that missing episode just like that. Worth the $2 for savings for my time and hassle.

Early in the year, I cancelled my Netflix subscription which I was never using, because of Amazon Unbox. I don't want to watch video on my PC, either. Now that Netflix and TiVo finally get their act together on streaming, I'll probably check that out over the holidays and see what it's like in terms of content amount and quality of streaming experience.

Gadget Two: This year I also got the Kindle, Amazon's ebook reader. In a year in which I got a new GPS, a Wii, an Ipod Touch, an eeePC, a new laptop from Dell, and a treadmill - this is hands-down my favorite new toy. Especially since I did a lot of international travel this year. I love that I can bump up the font, and read it in bed one-handed. The physical industrial design has gotten a lot of internet flack, but it does what it needs to do just fine. The book and blog experience are terrific, especially for fiction and feeds without too many pictures and long articles. (Pictures don't render fast or well on the b&w e-ink display.)

A typical Kindle set of experiences, which I can personally vouch for:

• A list of Best Books of 2008 from Amazon editors' top picks -- I'm not so convinced by some of the capsule reviews, but hey, I'll send free initial chapters to my Kindle to check out! In a couple clicks, I've got 8 books to try out.
• I read and like the first few chapters of one, so when I get to the last Kindle page, I click on "Order this book now." It checks that I'm not making a mistaken click, I confirm, and it downloads in seconds. Hooray! No regrets.
• Make to Stick keeps getting good press among recent business books. I'm not willing to take up room on my increasingly groaning shelves if I can get this by Kindle - and yep, I can! Sample checks out as actually interesting, I can now read it as one of my background non-fic reads.
• A friend recommended the Dresden Files books; earlier this fall I got hooked on the bad but addictive Twilight series. These literary wonders-- and more importantly, their sequels-- can be had by Kindle without driving to a store or waiting for mail to come. One click from a late night bed and I can keep reading.
• I owned The Diamond Age in paper form but did get around to reading it. It's long and the font is small. You know what -- I read it by Kindle instead, since the font can be jacked up to a more reasonable size and carrying it doesn't require muscles. I also own the wonderful Jonathan Strange and Mr Norrell in hardcover, all 1000 pages of it. I will not have to carry THAT around again, I'll be able to read it on the Kindle next time. Er, no, it seems I can't yet - so I'm clicking that link on the left side of the page requesting it be made available by Kindle format. Same for Foucault's Pendulum!
• I can't keep up with long blogs, or most blogs anymore. But I sure can read Cognitive Daily and MIT Tech Review and a few others by Kindle, when I have a spare minute for the short stuff.
• Cory Doctorow and a number of other writers are making free ebooks available for their stuff. Cory's "Little Brother" got raves this year. I loaded it on my Kindle by USB cable.
• Fanfiction - in a moment of weakness on a business trip, I started reading fanfic again, after a few years off. I can send PDF's and Word docs to my personal Kindle address, without having to even plug it into my computer. Yeah, I suppose you could use that feature for something worklike, too. It's unfortunately convenient. There is a LiveJournal community all about this fanfic-on-Kindle habit.
• I like switching between genres and books and being able to bookmark pages, save clippings for later blogging, etc. I used the "lookup word" function a ridiculous number of times while reading The Diamond Age. It was all that Victorian English.
• I don't love the web browser "experimental" functionality - it's slow by phone WhisperNet, but it will do in a pinch! I can read my twitter feed on it. I once settled a discussion of what the male version of "ballerina" is using my Kindle from a wireless-free zone of Northern Maine on a bird watching trip.
• Tom Disch, a poet I liked reading on LiveJournal, killed himself this year. In a sad weekend, I copied and saved all his journal poems into a Word document and loaded it onto my Kindle. Now I can kind of keep him around.
• Free ebooks... Manybooks is one site, and if you load this Feedbooks guide, when you click on any of the contained book title links, it will automatically download the whole thing to your Kindle. I got myself a bunch of old Rafael Sabatini adventure novels for one trip this way.

I could go on. The Kindle has something to do with me starting to read a lot again, like I used to as a kid. There are some minor negatives, like slow page turning (I would NOT use it for holding reference books), but nothing that overwhelms the good. I still order paper books, and always will; but I have a house busting at the seams with bookcases, and carrying them around isn't always convenient.

The combination of a very long battery life, and small form factor, WhisperNet with excellent Amazon shop experience and sample chapters, make the Kindle way more than the piece of white plastic a lot of people dismiss rather easily. I wouldn't get a Kindle if you expect great web connectivity, a multi-app computer experience, or a backlight... but get it if you read a lot of popular books, and especially if you travel a lot.

In sum, Amazon can take my money, for books and movies. Thanks, Amazon!

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.

My Twitter on the VP Debate

I couldn't watch it all, and made a mistake in not having my twitter in front of me while I did. But here's, in a glance, a big reason I love twitter. There's a slim chance that 2 of these people know each other, but I don't think the others do, although I bet they'd like each other if they met. (Assuming they won't mind: tingilinde whom I know from Bell Labs/AT&T, Nancy Baym from grad school mentorship days, Jared Spool from being, well, Jared, and Greg Raiz, a colleague from Boston.)

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!

Mandatory Post on Twitter: A new form of MUDding?

Everyone else is doing it, so I'm posting about Twitter too. I admit I've been enjoying it, probably more so since I have less time than I used to for blogging, Bloglines, and keeping up with friends on LiveJournal.

Everyone who writes about Twitter has to compare it to other things. For me, it's most like what we did in MUDs when I used to hang out there (a kind of chat world, see MUDs and MOOs on wikipedia, and my book about one). We used to connect while working, and "idle" much of the day, but "wake up" to post links to things we thought were interesting, or to say what we were doing "in real life." We even watched TV together in a MUD group. In a MOO, you had to do something special to direct comments to someone, just like you do in Twitter (where you prepend "@name"). Voila, c'est Twitter; except that in a MUD you had to go somewhere to be in the space by connecting specially, it was less public, and a lot more synchronous. Plus not searchable from "outside" the MUD client. So, okay, it had some differences.

Other things it's like: How people change their "status" message in a chat client, and sometimes riff off other people's status messages. That's not archived in the way Twitter history is, though. And it's like SMS, in that's it's terse, but for a party. And it's like a very slow chat room, where no one really knows who's listening in or who might look at what you said later. (Watch out.)

Brief geeky research aside: There's an old paper by Clark and Brennan (1991) that's a goodie among people who study CMC (computer-mediated communication) that describes potential aspects of communication media, including whether they offer co-presence, visibility, co-temporality, and sequentiality of messages. To really consider how Twitter stacks up, you would also want to consider system features that characterize rich Internet communication tools, such as the potential for users to have private one-to-one and multi-party conversations that aren't recorded, what kind of message size is possible, availability of threading/sorting/filtering tools, ability to archive exchanges and/or prevent it, possibility of editing posts after they are made, ability to block messages from certain people.

Twitter is less synchronous so less co-temporaneous than internet chat or face-to-face or phone talk, the reviewability is possible but only fair in practice (in that you have to do some work to go back in a history to check what you missed), and interruptions between two-person exchanges are common. Threads are possibly even impolite. Private messaging is possible depending on the client used. Editing isn't possible after posting, but deletion is. The message length constraint strongly restricts the type of exchange that can happen, by design. Blocking of a kind is possible. You can filter your list of followed people to a "favorites" list if you want.

Which reminds me - all communication media allow for genres or registers of speech/writing, in which the style and topics can differ tremendously across groups of users and occasions of use. Generalizations about how people use Twitter will only be applicable to local groups of followers and their following. So I won't try. Give a look in and see what you think.

Because of the very public nature of Twitter, we get the possibility of search tools like Summize. Which means you can look up keywords or people and find out what's up with them. You can even subscribe to these searches by RSS, so thatt you can follow public chat that mentions your favorite product or TV show. (When I mentioned FIOS once, someone who works at Verizon started "following" my comments on Twitter.)

Summize also allows for interesting meta-search applications like Twitter Spectrum, allowing you to contrast word environments for two terms. Just for fun, here's a few charts of contrasts I find interesting. You can see who's talking more about what here.

Anywho, I'm enjoying Tweeting, although I still miss ElseMOO after all these years.

Mini-UPA conference in Boston

Boston's mini-Usability conference is coming up on May 28 at Bentley. This is a reasonably priced one-day event that attracts quite a local crowd, and not a few non-locals. I had a good time at this last year, when I was a speaker on online community design. This year I am speaking about life as a consultant, and mistakes I made in my first year. Here's my abstract:

One year ago, I quit my job and started consulting full-time, after 10 years of industrial wage slavery. I was financially successful in this year, but made a lot of mistakes. I managed to fall into bad headhunter relationships, make mistakes in my accounting that required a 101 class to fix, became thoroughly confused about whether to be incorporated or not, and generally made a lot of newbie mistakes with a handful of clients ranging from garage startups to established software firms. Other local consultants gave me advice and I learned from my mistakes. I can tell you how I did it and what I could have done better; and how it compares to what other local consultants say. I will cover:

• Your use of the internet to advertise yourself (search engine optimization, job sites, Linked In, blogs, etc.)
• Portfolio work
• Branding (logo, name, etc.)
• Proposals
• What to charge (the many factors and equations; plus: "they're charging WHAT and someone is really paying it??")
• Headhunters and job offer pressures
• Basic accounting and expenses to track
• ... And other things I learned the very, very hard way, like the portable office equipment it might be nice to own because the client site is a cave with rocks to sit on.

You'll get a handout with the Top 10 Most Important Consulting Considerations in case you too want to do this!

BIO:Lynn Cherny has a Ph.D. from Stanford that she hasn't used in years, except for some statistical skills. She has 12 years of experience working at and/or managing interface design at companies including TiVo, Excite, Adobe, The MathWorks, and AT&T Labs. Her current consulting identity is Ghostweather Research & Design, LLC. She can be reached at lynn@ghostweather.com.

There are interesting names on the list of speakers, including Jared Spool and Chauncey Wilson, Beth Loring and Joe Dumas, plus a host of other local employers. The talks range from research methods to design case studies, with a bit of business thrown in (thankfully, for some of us!). It's even multi-track, reflecting how many submissions they get. And their cocktail hour is fun and well-stocked.

NASA Tech Briefs: Create the Future Contest Awards in NYC

New York City, April 2008: In New York last week, the Create the Future Contest award winners were honored in a nice ceremony. The awards were presented over a swanky dinner and drinks at the Water Club in NYC. (Good thing I changed when I got there: a classic NYC taxi driver let me off early saying, "I can't turn right here. You have to cross there and go under that overpass, past the helicopter landing, and then it's on your left.")

While I was pleased for all the qualified entrants-- almost 1000 this year, a record probably due to having a website -- I was most happy about the two student category winners. Jeremy Connell, a junior in Virginia, actually used SolidWorks for his cargo carrier design. Here he is holding the paper edition of NASA Tech Briefs, which features his winning design on the front cover! Jeremy would like to get a job designing boats. I'm also hoping he'll intern at SolidWorks if he's available and we can work out the details.

The winner for the Transportation design category was student Corban Tillman-Dick, who is actually an economics major at Johns Hopkins. He's the designer of a more efficient engine, the Internally Radiating Impulse Engine. His brothers were all present for the award; they are trying to get funding to base a company on this design. Sadly, their father, who helped with the design, died suddenly in a car accident a few weeks earlier and could not attend with them. Here is Corban and a brother with Jeff Ray, CEO of SolidWorks:

A few other winners -- Joseph Hollman designed a beacon locator for mine workers, shortly after a serious mining disaster last year. Here is Joseph receiving his award:

And Dr. Ajay Mahajan and colleagues were there to receive their Medical category prize for a 3D ultrasonic neuronavigation system for realtime image guided brain surgery.

I'm afraid my camera batteries, bought for €1 in a Venice shop, did not hold out long enough for everyone's prize.

As you may recall, I was the consultant that designed and project managed the contest site for SolidWorks. This was the first year that SolidWorks was a major sponsor, as well as the first year there was any website featuring visible entries (and featuring a frenetic, viral "page view contest" which galvanized many students, not to mention bots). Jeff Ray also accepted the SolidWorks award for "Product of the Year" given by readers of NASA Tech Briefs, entirely coincidental with the co-sponsorship of the Create the Future Design Contest. (Obviously the contest was not judged based on software used by any entrant, and SolidWorks did not participate in the judging in any way.) Instead of a boring talking shot of Jeff Ray, I like this pic of him talking over drinks to our student winner who used SolidWorks.

Apart from the chance to see the sometimes wacky but always creative inventions, I got a lot out of seeing young designers do so well in the contest up against professional engineers. And in general, there were a lot of ideas that could make the world a better place with the right exposure and funding. Providing webspace for inventions and inventors is a good thing for us to do. We'll (and I'll) be doing the site and contest again this year! Stay tuned for another June launch.

Business Week Top 50 is Out; Autodesk at TED

The "best performers of 2008" (already?) are up in a list at BusinessWeek Online. Despite what many (including BW) would call a recession, there were some healthy net incomes. Their interactive chart (sortable) is kind of fun; but in an interesting discrepancy, the sector identified for each company does not agree with their print mag's reporting, and this makes me a little suspicious of their rankings which were tied closely to sector identity. Apple (#6 this year) is called a hardware company in print, but IT online.

Handbag maker Coach is #1. Multiple good years for them. But skipping to the technology companies: Apple at 6, Cognizant Technology Solutions (an outsourcing consulting firm) at 19, Amazon at 23, Autodesk at 28, Google slipped to 34, and Microsoft is at 41. In companies not run by a white man in his mid-50's who looks distinguished and politiciany, we have just 2 women, at Avon (a company that got written up as having a "makeover" and looking "pretty") with Andrea Jung, and PepsiCo with the fantastic Indra Nooyi (Indian woman). I don't drink Pepsi because of her, but I like it better because of her.

How about that Autodesk, a company alma mater of mine! (Adobe wasn't there this year, but was last year on the strength of the CS3 release.) The writeup is especially interesting if you were there at Autodesk working on this area: "Autodesk's latest software makes architects and engineers more productive-- and injects visual oomph into their designs. Its new three-dimensional software, including Revit Architecture, lets architects model a building's face and sides in the same drawing. Even midprice PCs can run the programs, and that has expanded the [company's] market."

Autodesk had Revit (a local Boston-area acquisition) for many years, so it's hardly new. Midprice PC's are pretty peppy nowadays, so that claim may be true. For all the old-boy cronyism and management nastiness I thought it had, Autodesk does have a smashing smart CEO who cares personally about product design and usability, and now employs some of the best interface designers I've ever worked with (particularly from the Alias acquisition).

[Updated to add: Autodesk and Carl Bass were in form as sponsors at TED this year, with one of the Alias products making high-profile news too: check out how Alias's innovative Sketchbook Pro (rebranded for Autodesk of course) was used for the during-conference blogging report up at "Autodesk at TED2008". The Autodesk message is that they're about "design innovation" and sustainable design. Convincing with that great research and design team from Alias, for sure!]

Top 50 history: The BW Top 50 from 2006 (Apple at #1), and from 2007 here (Google at #1).

Netflix Contest and Recommender Systems (short history)

I'm fascinated by the Netflix challenge: Netflix is offering one million dollars for an algorithm to improve recommendations based on movie ratings. Along with this go intermediate "progress" prizes of $50,000 per year the contest runs. The prize leaderboard is interesting reading, in that you can see who is entering teams, their results, and sometimes a bit about the team. Team Bellkor is a group of researchers from AT&T Labs, my first employer out of grad school. (I don't know these particular folks.) Netflix provides an interesting example of one company "funding" research at another company. The research lab folks are getting papers out of it, of course, probably the most important thing they need to do in a research lab (money comes second; although these days, proof that their work can impact a real business domain may beat everything else).

In another AT&T Labs connection, the Netflix prize FAQ cites an excellent overview paper on evaluation of recommender systems (pdf), co-authored by a colleague of mine, Loren Terveen, from the HCI department I was in at Bell Labs. Loren worked closely with Will Hill, one of the Bellcore researchers who (co-temporaneous with Pattie Maes at MIT and Paul Resnick) kicked off the work on recommender and ratings systems that you now find implemented all over the Internet. Recommender systems as a broad theme include all user ratings on products or comment postings (such as Amazon book ratings, or ratings implemented in almost all forum software now); they're intended to help others find good quality content by aggregates of ratings from other users, not from editorial oversight which is costly and therefore scales poorly to large amounts of content. There are important tweaks you can apply to your system or your filtering mechanism, such as "ratings of people like me" versus ratings of everyone, of course. (Netflix has some version of predicted "ratings for YOU", specifically, which I haven't investigated in any detail.)

I recommend glancing through Loren et al.'s paper, for a refreshingly meta perspective on a piece of technology that now defines a lot of assumptions behind what is called "web 2.0." As a more personal note, I wander among mostly non-research types these days, and the hot topics du jour (like "social networking") tend to get dropped into web system design discussions all the time, with a kind of naive "of course we need it" mentality. I can only sigh at how old I feel sometimes. Critical evaluation and careful implementation do matter, even for all the stuff that made it out of research projects into profit-making companies and community-platform toolkits.

As another personal note, I'm generally pleased by the level of researchy savvy I detect in the Netflix prize FAQ. Hey, if you're hiring at a software company, consider investing in some serious research-minded folks for competitive advantage!

Search Engine Poetry Generator

I've always liked random poetry generators (I could dig up some of my favorites, but I'll save it for another day) -- so I wrote one based on an idea I saw on someone else's blog. (I admit their idea is more interesting, but I had a simple goal to start with: practice with SQL and PHP on my hosting server.)

My generator builds random "poetry" by stringing together keywords and keyphrases that hit my site from searches in the last month. (I'm afraid it's not a real-time feed from my logs, it's canned from the last month.)

Popular searches on my site: ghosts, Canada, and disorganized organizations. It makes for peculiar poetry, not good, but kind of fun. Victoria's Secret is definitely showing up more and more, too.

One of them:

alice in wonderland porn
   lost
  i need
  stone
  tivo patents

for me, illusion
   -- erin

Give it a try, or ten...

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!

Pavel's Puzzles

Thank goodness, just when I was dreading starting my post about strategy and tactics, Pavel Curtis gave me a good excuse to avoid it: he's launched an online puzzle shop! Since I'm currently reading the slightly evil yet fascinating The 4 Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich which describes many such businesses, I'll be fascinated to watch his progress. (Updated to add: Here's his announcement post about it, on his regular blog.)

Pavel is not only a Lisp hacker with mathematical talents, ex-PARC denizen, and founder of famous online community LambdaMOO, he's a gentleman who co-hosts an annual games party on New Year's that attracts an interesting crowd. I went once attached to one of his invitees, and it was more fun than I would have expected, being your typical uncompetitive, non-gamer who freezes under public performance pressure. His and other puzzles dotted the house, I recall. That was back in the hills of Palo Alto, before the more recent Seattle move! We are all getting old and moving too often.

If you like puzzles with interesting stories, go help Pavel retire from the Evil Seattle Empire and become the new rich!

Create the Future Design Contest: My Press Release

I am very pleased to be able to make my own press release for a project I've worked on the last few months, the NASA Tech Briefs Create the Future Design Contest website. The contest this year is co-sponsored by SolidWorks, a great company and my current client. The contest is open to all inventors regardless of their software choice, however!

Grand Prize is $20,000, and there are significant other prizes in the prize list, too. Plus, a great t-shirt if you enter with a qualified entry. (The contest image was acquired--legally--from the patently absurd inventions archive.)

The Create the Future design contest has been running for at least 5 years now. They regularly receive around 1000 entries. In previous years, the folks at NASA Tech Briefs handled this contest entirely on paper, which was a lot of work for them. There was no website featuring the entries, so the entrants had no idea what their competition was, and the public didn't get to play at all.

SolidWorks (and I) wanted to make the fun more visible and reduce the work for the NTB editorial team. So we've dragged the contest into, okay, about the year 2004 -- the site is pretty basic, was done on a shoestring dime, and next year will be a lot fancier and more dynamic. But I'm still very pleased at what we've done.

We wanted to help people who enter have a better shot at winning, too -- I emailed all the past year's judges and asked them what advice they had for entrants, and we got excellent responses. Anyone considering entering should definitely read the Tips page.

I was particularly struck by how important clear communication is in creating a good entry. Some example quotes:

• One judge recommends: “Write at least 4 drafts of your presentation and have 2 or 3 people of various levels of understanding review it. This will provide for a presentation suited for the diverse backgrounds of the judges.”
• "I look for a concise description of the design and ask, ‘Have I seen this before?’ and ‘Do I think this is useful?’ If it passes those tests, it makes it to the ‘for further review’ pile. “Then, I’ll look again at the entries I initially discarded and ask if they are trying to take something similar and existing to a new level. If the answer is ‘yes’ and the idea is useful, it goes on the final’ pile.”
• “For models of good technical presentations, check out Science, Nature and other well-known technical periodicals. You’ll see a good cross-section of abstracts and structured papers. The contest emphasizes content, not structure—but in a professional setting, structure is important."

The CAD world has a tendency to think it's all about the beautiful image, but the text is enormously important in this contest.

Although the main prizes are awarded by the NASA Tech Briefs' invited judges panel, there are 10 prizes for the entries that most captured the public eye. You can help by coming to view them yourself, and posting links to the entries you particularly like. While you're looking around, try finding the guy who has a real beef with NASA (whoa), the personal cooling system, the strangely redundant (IMO) salt and pepper shaker. You may not be surprised by the entry with the current top page views -- apart from being a very cool idea, it's extremely well-written, too.

Help us advertise the contest and the best entries! And consider entering yourself. There's still plenty of time: the contest closes for entries in October. Even if you're afraid you're not up to NASA Tech Brief's judging panel, you might capture the public eye and get blogged and get famous (and get $250 too).

(After the next round of contest entry validations, when we've got more visible on the site, I'll post some links to my own favorite entries to help them out on their page views.)

Asshole-Driven Development on Berkun

Time for my weekly post on assholes in corporations, I guess; this is a few weeks behind, but I needed to space out the AH stuff, and I was busy.

Berkun posted an idle conversation starter on what he called "asshole-driven development" and the responses brought down his server. Then Lost Cog did some content analysis of the styles of development described by the comment thread. It seems to be going on and on. Some of the original categories identified:

• Asshole Driven development (ADD) - Any team where the biggest jerk makes all the big decisions is asshole driven development.
• Cognitive Dissonance development (CDD) - In any organization where there are two or more divergent beliefs on how software should be made.
• Cover Your Ass Engineering (CYAE) - The driving force behind most individual efforts is to make sure than when the shit hits the fan, they are not to blame.
• Development By Denial (DBD) - Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor.
• Get Me Promoted Methodology (GMPM) - People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go.

As some posters and Scott noted, bad development management may be subtypes of general Management Antipatterns, like "Death by Planning."

And I'd note that these techniques aren't limited to management of technical problems, but also exist in any other project context, in slightly different forms.

Berkun on Innovation Myths

Another book recommendation: Scott Berkun's new Myths of Innovation. I'm a big fan of Scott's earlier book, Art of Project Management, and his new one does not disappoint. I think it stands apart from other books by consultants and design agencies on building innovative organizations. (They're now a dime a dozen.) It's short but still condenses a huge amount of material from both business lit and historical research in a way that even someone who once wrote a dissertation can be amazed at. (Note: I was not as successful as Scott was at this trick.)

One of my favorite parts is on the myth that "good ideas are hard to find." Why, no, they're not, but execution is hard. Which segues nicely to his other book; in my experience, a lot of organizations have grand product plans and grand business goals, but execute very, very poorly. The customer only ever sees a fraction of it, and often the worst fraction.

Some of the sentiments that kill good ideas before they even get to fail by execution include: "We don't have time," "That never works," "We don't do that here," "We tried that already," "That won't make enough money." A longer list lives here on Scott's Blog. I'd add the question: "Who are you, again?" Or the related, "You're here to listen, not talk" (which I've actually heard).

The issue of time is the biggie, from what I've seen in my past few companies. The execs may be reading books about innovation (for whatever reason), but at the operational level, everyone is signed up for way too much work. They can't succeed at what they've agreed to do, but they're trying anyway. Why would anyone want to sign up for more, regardless of how cool the idea is?

I have the same feeling about brainstorming; as a concept it's all warm fuzzies, considered obviously valuable, although it's often poorly or incorrectly executed (as Scott points out). In practice, though, not everyone's ideas ARE considered equivalent, precisely because of this economy of time available to the participants; given a small, finite amount of time to think and make decisions, why pay attention to the crazy sounding new kid's idea, instead of the seasoned manager who deserves to get his say because he's proved himself, right? In a more applied, problem-solution context, the more seasoned people are assumed to "know the code" or "know the users" better and therefore their opinions are worth more. It's been said out loud. It's basic human sense, right? And the less time people have, the less they're willing to extend themselves to be open.

Successful innovation might require fewer over-ambitious projects, acceptable risk and play (meaning: someone isn't working on your critical shipping "normal" work and that's okay, and not overtime work for them), plus a commitment to try to listen to all voices differently, no matter what the problem is: new product, new feature, or old ordinary problem you have to solve on an ordinary project. I'll come down strongly in favor of that last -- I think innovation can happen on "old" projects, too, and it should, to keep them viable and interesting to developers and customers.

But good project management is always needed to help you actually plan and then ship something! It's still innovation once it's in the development phase, even if it feels like just "work" then. The team needs to be supported, rather than having their work taken for granted as "a done deal" while managers go off looking for the next big idea.

I can't find it now, but one of my favorite lines from Myths of Innovation goes something like, "Successful ideas, like happy pets, are shared among many people who care about them deeply." Pet them, sometimes.

LiveJournal in the Blogosphere

Work by Matthew Hurst on mapping the blogosphere has been blogged around recently, particularly because of his cool hyperbolic graphs of the huge data set of linkages, one shown above. I post here because I've got friends reading on LiveJournal -- I know LJ folks occasionally wonder why the press about social networking sites rarely mentions LJ, favoring MySpace and others. One reason may be that LiveJournal is a fairly close-knit and separate community site, with a lot of internal links via friends lists, and not a lot of other blogging post cross-over or linkage in. (I don't know how he handled syndication on LJ friends lists, if at all.)

LiveJournal's small network cluster is shown in the image as cluster #3. The others are (1) DailyKOS, (2) BoingBoing, (4) other political bloggers, (5) porn, and (6) sports fans. LiveJournal is further out than the porn fans, but bigger! Smaller than sports fans, though.

Design for Online Community: Past the Hype

I've posted my slides (PDF) from a recent "mini" Usability Professionals Conference talk about online community design. The talk was well-attended! Thank you if you came.

If you didn't, the gist is this:

• In Web. 1.0 we talked about community off the web as well as on it, in IRC, USENET, MUDS, BBSes, etc. (My dissertation and books are from that era.)
• There are a lot of sociology, anthropology, and linguistic studies of "community" that predate the internet. What can we learn from their definitions?
• Designing community requires special skills and ongoing commitment to the group.
• Good definitions help you understand "when you got it." This can influence your metrics.

Virtually every slide here could be a separate full talk, especially the metrics part. Let me know if you want any more references or help on the subject. This is my first in-depth look at this topic since 15 years ago, and like then, there was a lot to digest!

Design and Risk and Innovation (and CEO Pay)

Over on NussbaumOnDesign, there's an interesting thread on the role of designers in innovation. Designers thrive on risk, learn from it, and move on from it, so they're useful as models for innovation processes at companies. That's is the gist of a piece by IDEO folks summarized here on BusinessWire. Given this, design as a process reduces corporate risk during innovation, Nussbaum recaps:

Let me repeat--the design process cuts risk. When you do design (or innovation--whatever you want to call it), you use ethnography, prototyping and story-telling to develop a product/service/experience. These processes actually reduce risk. This is a fact that most CEOs simply do not get. It is far riskier to come up with a new technology in the labs, make it into a product and then throw it at consumers than it is to first start with your consumers to find out what they really need and want (the essence of design).

This admirable sentiment requires a definition of design as a process that involves good customer research, a definition not all would agree with, although I myself certainly prefer it and sell that as a service during design :-)

But for any good interaction designer, intuition counts, as well as the prototyping, empathy for the customer, focus on the desirable, and grounded research to inform that process. The risk in design is that there's never perfect and complete data, and at some point, you have to just follow that intuition and make something which might be a failure if one of a million details doesn't go right. And those final details are usually a team effort, whether the designer wants them that way or not: building a product is (usually) expensive and complicated, unless it's a garage Flash app.

There are a few provocative comments following up on this later on Nussbaum's blog, suggesting that until designers put up their own capital, they are less risk-taking than their clients or the businesses that run with their ideas. A quote from the comment by Chris Conley:

Actually one could argue that designers simply ask their clients to take risks on them and their work. Few designers put their own capital at risk. I would also argue few understand the notion of investment and return which is how risk is manifest and monetized in business. Designers mostly have a cost mindset just like most business managers. An investment mindset is something that needs to be taught and is part of a innovation toolkit. Until designers put up their own capital (and not just the proverbial sweat equity) and take real equity positions in ventures, the risk is truly being born by someone else.

But there are other real risks for designers apart from personal capital, which Conley doesn't acknowledge: loss of credibility, reputation, credit (including financial reward), missed opportunities at other companies/agencies while betting on this job or client, and others that may be more important to an individual designer. Personal risk management is about all of that, too.

Edited to Add: Actually, after drafting the above and going to bed, I've woken up fairly incensed at the idea that designers should be putting up their own money in order to experience "real" business risk. Point one: Many of them do, because what they're motivated by is seeing their ideas in the world. They quit and go to startups, they do their own thing online, etc. This is fairly clearly "their own money." (At one company, when I couldn't get usability bugs taken seriously, I considered bribing engineers to fix the bugs I had filed. I was a hair away.) Point two: CEOs and other executives certainly don't put up their own money, and they're paid outrageously in comparison, so don't talk to me about money here, Mr Conley! Hmmph. Here are some articles on the pay issue, if you want to get educated about this:

• CEOs are Overpaid
• Executive Paywatch
• A new trend in CEOs: The See-Through CEO.

Note especially that even if they "fail" they have enormous severance/retirement packages, suggesting there isn't much financial significance to their failure.

Mathematica Graphs and Other Demos

More fun stuff for people who like pictures, but don't necessarily follow all the math: Wolfram has a downloadable viewer and a bunch of fun interactive demos that let you play with sliders and manipulate pictures to generate fun stuff. There are a whole bunch of categories, including "unsolved problems" that might really pique the interest of the math folks. I personally like the graph theory demo section, because of the issues I have with making sense of social network visualizations.

Note to dowloaders: You download the app. Then you start it. It launches a splash screen but seems to do nothing else. Then you click on a demo link on the website and choose "run." That runs it in the application viewer on your machine. To put a demo through its paces, try "Autorun" from the menu under the small + in the upper right corner of the little applet!

Workaholics in Consulting and Engineering

Really more about type-A personalities, or at least very driven people: An article in Fast Company on Boston Consulting group trying to get a grip on employees who work too many hours.

"A hero at BCG is not someone whose light is on at 10 at night," says Kermit King, the firm's head of recruiting for the Americas. "The emphasis should be on productivity per hour, and I think there's a point where productivity diminishes."

That's why the firm--which doesn't bill by the hour and explicitly states that hours don't figure in promotions--launched a program called the Red Zone three years ago to spot and tame chronic overworkers.

It's not quite working yet -- perhaps because the workload makes it impossible to succeed within the green zone. They have had a slight decrease in the percentage of employees who say their load is not manageable, though, up to 63% from 67%. (At one place I was salaried, 100% in my department said it was unmanageable. The hours we worked reflected this of course, which is one reason I charge by the hour now.)

A related post appears in the increasingly interesting 37signals blog, on development type A's: Don't Be a Hero. Their gist is that if you haven't finished a task in estimated time allowed, don't push on to do it in more time:

That’s where the concept of sunk cost gives us a guide on what to do. It doesn’t matter what you’ve already spent. That time and money is gone. It only matters whether spending what’s left is worth it or not. Business school 101, but one of the hardest lessons to internalize.

Unfortunately, the switching cost is often high for creatives and execution-driven folks. In morale if not attention to task measures. But in general I think their point is very good.

Logos of Web 2.0

In case you haven't seen this -- at FontFeed, there was a nice deconstruction of the look of web 2.0 company logos. (Thanks to a graphic designer I worked with recently for the link. Same could be done on the websites with probably similar results; I feel like I've seen the 37signals look all over the place in the last couple years.) In a non-graphic designery vocabulary, I myself note a lot of blue and orange, more "soft" rounded fonts rather than angular in this selection, and greys and gradients.

Engineering Rewrites and Old Code

Closely related to my Balls o' Mud post about old code bases, the latest Silicon Valley Product Group blog posting is about the necessity of engineering "headroom" for code maintenance during product lifecycles. And about inevitable rewrites to scale, perform, and I'd say, accommodate design of new features, although the article doesn't focus on that issue per se.

I knew ebay had gone through growing pains, but the article suggests some absolute heroics in the form of two mid-growth rewrites of their code that barely touched their business performance. I know of some (plenty) UI designers who've left ebay because of their unwillingness to touch their UI (it sadly needs it), but I do applaud their engineers for their effectiveness at communicating the need to do code work to survive. From the SVPG article:

The deal with engineering goes like this. Product management takes 20% of the capacity right off the top and gives this to engineering to spend as they see fit – they might use it to rewrite, rearchitect or refactor problematic parts of the code base, or to swap out data base systems, improve system performance – whatever they believe is necessary to avoid ever having to come to the team and say “we need to stop and rewrite.” If you’re in really bad shape today, you might need to make this 30% or even more of the resources. I get nervous when I find teams that think they can get away with much less than 20%.

If you are currently in this situation, the truth is that your company may not survive this. But if you are to have a chance of pulling through, you’ll need to first do a realistic schedule and timeline for making the necessary changes that engineering identifies.

If your product is slow, hard to modify, and your code base is really old and hard to understand by your own developers, you should be worrying about your future in the business. Can the people you want to modify your product succeed in actually modifying the product without total internal collapse, at version N? Here's another pointer to that ball of mud article on software architecture growth issues.

Pretty Visual Generators

I've been looking at online generators for the last few days (a recurrent interest) and was reminded of these pretty visual ones. Worth checking out.

Jared Tarbell's beautiful I'Ching interactive display. Hard to describe, and a little mysterious in practice, as it should be.

The Walking Insect Generator, which is also beautiful, but funnier. Seriously, do click and marvel.

A scribbler art project -- this one is fun to watch, like a lot of these visual noise generators. It tends to fuzz up your drawing.

Product Idea Generator

This is addictive, like any good generator. It's especially well-done. Too bad the reload link is so tiny, but you won't miss it. Samples I got:

• It's a rubber fish that shouts 'WARNING!' at the first sign of danger! It sounds better than it looks and mimics the movements of a lizard.
• It's a blow-up doll that's inflammable! It kills weeds down to the root and talks.
• It's a video recorder that scares dogs and stays exactly where you leave it.
• It's like a normal shoelace, but it runs on six little wheels.
• It's an aquarium that keeps track of your personal calendar!
• It's a trouser press that flies like a rocket! It doesn't need batteries and may cause drowsiness.

Web Log Analysis: Site Flow Charts

I've been working a bit on web log analysis recently (see my contracting info), and while I didn't deliver this for a client, I did spend a little time seeing if it would be worthwhile to do in the future. After doing the usual freqencies of referrers and requests and such, I also looked at median page views per visitor.

I then did a small sample extraction of page views of the users matching the median page view profile, and generated arcs corresponding to what page types they went from and to. I overlaid them on a site map I threw together, done by hand in Illustrator (and here anonymized): the width in pixels of the line directly corresponds to how many arcs there are between each node (or page type). Blue lines are going into the "purchase" process, while green are just the rest of the traffic patterns. It's a little more suggestive than the simple frequency counts that don't show actual paths; because in this I can see how few people in my sample subset go from, for instance, the "not found" search results to searching again. And it's quite obvious how relatively many people in these logs were buying products while browsing rather than after searching. It's probably worth doing this a larger scale and figuring out a good algorithm to automate the drawing, but I ran out of time on this contract project. If anyone else wants to pay me to do this for their site, drop me a note. :-)

Big Ball o' Mud: Code Tangles and Organizations

A friend pointed me to this a month ago, and I'm only getting around to this now: Foote and Yoder's Big Ball of Mud, on legacy code that no one can understand or modify without risk to, well, sanity and schedule.

They illustrate their points with physical world architectural examples, a lot coming from Stewart Brand's How Buildings Learn, because design in other domains and design of software aren't so different when you look closely.  I was, of course, thinking about interface design and organizational design while I was reading it, and about the book Architecture Without Architects, which I really like in both concept and fact after meeting a few (I'm kidding--mostly).  Foote and Yoder's interest in XP (extreme programming) is in part because of the need to accommodate changes in user requirements, but they don't talk a lot about UI design and the difficulties with keeping UI code flexible and modifiable.  (I still think it's a shame that agile and XP communities don't connect and work better with UI/UX/UE folks -- apart from the active agile-usability mailing list, of course.  The goal of a good designer is to get the right decisions made right and executed well; these goals are the same for both UI designers and code designers, and should be the goals of managers and executives who support them.  But.)

Selections from the Ball of Mud article:

• One reason that software architectures are so often mediocre is that architecture frequently takes a back seat to more mundane concerns such as cost, time-to-market, and programmer skill. ... Architecture is a long-term concern. The concerns above have to be addressed if a product is not to be stillborn in the marketplace, while the benefits of good architecture are realized later in the lifecycle, as frameworks mature, and reusable black-box components emerge [Foote & Opdyke 1995].
• In other words, the software is ugly because the problem is ugly, or at least not well understood. Frequently, the organization of the system reflects the sprawl and history of the organization that built it (as per CONWAY’S LAW [Coplien 1995]) and the compromises that were made along the way. Renegotiating these relationships is often difficult once the basic boundaries among system elements are drawn. These relationships can take on the immutable character of "site" boundaries that Brand [Brand 1994] observed in real cities. Big problems can arises when the needs of the applications force unrestrained communication across these boundaries. The system becomes a tangled mess, and what little structure is there can erode further.
• Architecture and code quality may strike management as frills that have only an indirect impact on their bottom lines.

The same can be said of usability and design excellence, of course.  It's a special organization that doesn't erode the desire of people to produce quality work by saying "it's good enough to make us money right now."

A good closing quote: Alan Kay, during an invited talk at OOPSLA '86 observed that "good ideas don't always scale." That observation prompted Henry Lieberman to inquire "so what do we do, just scale the bad ones?"

Pretty often, both on the idea itself and the execution. In the short term, the prototype code works well enough, and the design is okay unless you look closer or start trying to add onto it. Same happens with UI design, without enough iteration, and tacking on new features without refactoring is like adding dirt and grass to a ball of UI mud.

I'm now using the new Office 2007 products, and I regret not seeing more refactoring of the UI, despite the famous ribbon. If you're going to start doing a UI refactor, you may as well go all the way once you've disoriented your users a little bit; for instance, why keep Word's header and footer commands under the "view" tab now, and I have to question whether "home" means anything real to anyone except on a website. Some of the changes are a great improvement, but I think a little card sorting might have helped them out a bit, too, and I find some of these choices surprising.

Social Networks of Video Editors on LiveJournal

A few months ago, I did a talk at IBM Research in Cambridge on video (or "vid") editors and their online and offline communities. I made a few social network images, which I thought would be interesting to folks here, and I know I have readers on LiveJournal.

The basic gist of the talk was that hobbiest television fan music video editors existed long before YouTube and their history and organization reflect how they use the internet now -- which is verifiable with some simple data analysis. (NB: I used to be one myself, and in the talk I used a lot of personal examples and anonymized the rest, to protect privacy of anyone who wasn't contacted about this talk. So I'll say "we" here although I'm not practicing myself these days.)

In a quick sum of my talk: We used to do music video editing with VCRs. We existed before the internet was our main way of communicating, and we used fanzines and APAs to exchange tips and tricks (but truthfully, this was borderline before my time, although the friends who taught me all did this). We had and still have conventions at which we showed off our work, to supplement the now popular online posting mechanisms of distribution. (YouTube is not a major site for fan video editors, but another current social network tool that supports video has just become very popular among my friends who use LiveJournal for their conversations.)

Knowing the history makes for interesting cruising of the video communities on LiveJournal. The anime video makers turn out to be, for the most part, a distinct group. This isn't too surprising when you read the "about" text on one of the video community pages (slightly disguised here):

Anime "vidders" are told they may not be as comfortable here, and that VCR vidders are welcome.

This image shows the network of members in the anime community (highlighted) which is somewhat separate from the group (and its affiliates) quoted above:

One of the communities that is closely related to this one is one in which an annual face-to-face convention is discussed, started and fed by some of the older VCR editors and now pretty much populated by the non-linear digital folks, of which former VCR people are now a part. The convention-discussion community members, highlighted below in orange, are closely interconnected to the community quoted from above, which is circled in red here:

The group circled in blue is a Battlestar Galactica video group, less closely related but more so than the anime group. The closely inter-connected groups in these images are the generic discussion groups, at which the craft and technique and technical discussions occur. More specific discussion groups are generally less connected.

I made these images with prefuse, and apologies for the quality of the uploads. I'm available to talk about this stuff anytime :-)

MultiTouch Display

I guess it's a Tipping Point phenomenon, but I wonder who the cool kids are, everytime this happens. The iPhone demo features a multitouch display, and Jeff Han's demo of this functionality on YouTube has been getting a lot of blognoise; but this idea has been around in the research community for a while. What makes something finally get out of R&D "interesting idea" and into "must have innovation wow" in a product seen as widely as the iPhone? It was even around at Apple, and ignored for years. What does it take to get visibility and get on a product development and business radar? Some links:

• The Jeff Han video that's been circulated a lot (ok, points for music, for high density of info and fast cutting to demo points -- is this what makes it spreadable?)
• The Tog column that discusses some of the design history that went into the iPhone (many many ideas over many years, including random access voicemail -- we discussed and prototyped this at AT&T and at Excite 10 years ago too), some of it (but not most of it) at Apple itself.
• Bill Buxton's article referenced by Tog on multitouch displays. I know some of the people he's referencing, and I feel their mystification too.

I guess this is one of the reasons I stay as plugged in as I can to what's happening in R&D--the best of that work will eventually make it into products, and I'd like to lessen that time by figuring out the tipping point for it.

Joel's Quality of Software Teams; and Design

I'm a Joel Lover like many techies folks, and his job board is really tickling me. I just cruised the engineering ads (no, I'm not looking for a development job :-) and saw the the little questionnaire at the bottom of the page that measures the quality of the team hiring. Apparently people posting ads are answering honestly, which is excellent! And even more excellently, usability testing makes his list.

What would a similar test look like for hiring user experience designers, I wonder. A bunch would be similar, I think. I'd propose something like...

• Do you develop from specs written by designers?
• Do you have a design process with low fidelity work that is reviewed and refined before final specification is produced?
• Do you do usability testing during design or only after shipment?
• Do you change your design based on the results of user testing?
• Do you measure customer satisfaction with the product, including measures of user experience such as appeal, learnability, ease of use?
• Do designers talk to customers directly on a regular basis?
• Are developers involved in the design reviews and process?
• Does QA test for specification compliance?
• Is there a dialog about business requirements and product features that includes design staff?
• Do you require a design test and portfolio review during interviewing?
• Are other designers involved in interviewing designers?
• Are deadlines for specifications realistic and staged with multiple deliverables; or do you have single dates and one large spec document?
• Is your dev process sufficiently flexible to allow for design revisions without breaking everything and everyone?
• Are designers considered crucial to your business and to your developers? Regardless of the answer, how do you know if they are or not?

Giveaway of the Day

I've been tracking Giveaway of the Day for a little while now, and I've liked some of what I've found on it. If nothing else, it's a way to find out about smaller utility programs and new tools you don't know about, and you can't beat "free" when you want to try one. The hook here is that you only get a window of 24 hours to install and activate each one, so you have to keep up with the site if you want to catch something you want. And then they hope you tell other people so they get sales by word of mouth. I like the model.

Today's Giveaway was a nice tool to clean out your Windows startup apps (I kept wondering what the heck was slowing me down on one laptop); the other day I got a simple video cutter that helps the YouTube crowd splice stuff together and chop out scenes. More and more of these things are being described as simple and easy to use. Yay!

Demotivation and Burnout

Picture from Creating Passionate Users

Today's post is brought to you by a five day vacation, during which I've been catching up on some reading and not working long hours! I've found a couple interesting pieces recently on the subject of why people burn out, which suggests it's not the overtime in itself.

The first article was on Blogher, It's Not Just You. A recent Wharton School study looked at reasons for worker burnout. (It's unfortunately not yet available free online.)

"One of the biggest complaints employees have is they are not sufficiently recognized by their organizations for the work that they do. Respect is a component of recognition. When employees don't feel that the organization respects and values them, they tend to experience higher levels of burnout." Or, as Ramarajan puts it, "it is often not the job that burns you out, but the organization."

It turns out there was another good piece in the NY Magazine, Can't Get No Satisfaction, which meanders through social worker burnout, teacher burnout, medical burnout, and into high tech and NY Wall Street burnout. This one notes previous good research:

In 1981, Maslach, now vice-provost at the University of California, Berkeley, famously co-developed a detailed survey, known as the Maslach Burnout Inventory, to measure the syndrome. Her theory is that any one of the following six problems can fry us to a crisp: working too much; working in an unjust environment; working with little social support; working with little agency or control; working in the service of values we loathe; working for insufficient reward (whether the currency is money, prestige, or positive feedback). “I once talked to a pediatric dentist,” she says, “and he said, ‘A good day is when there are no screamers.’

Googling for Maslach, I hit an online quiz that rates your current level of burnout risk. The questions are about how you feel and about your work environment, as predicted by Maslach's findings. (E.g., "Do you feel that you are achieving less than you should?"; "Do you feel under an unpleasant level of pressure to succeed?"; "Do you find that you do not have time to plan as much as you would like to?" etc.) See how you score!

Finally, there's a related by different piece I just read when catching up on Creating Passionate Users, on Knocking the Exhuberance Out of Employees. When you burn people out, you've got robots and zombies working for you. Zombies and robots don't argue, don't have ideas, and don't threaten you or the status quo. They're a lot easier to manage, too. Hopefully no one who works for me is reading this, though, because I like arguing with them and am in no way an advocate of less exhuberance. Let that go as read!

Lastly, an article on Job Burnout in an online manufacturing magazine says (citing Maslach) burnout is about a mismatch "between what people are and what they have to do. It represents an erosion in values, dignity, spirit, and will-—an erosion of the human soul." America, with increasingly long hours and questionable corporate values, is a leader in burnout. We measure customer satisfaction, but worker satisfaction isn't a serious corporate issue, and the 40 hour work week is long dead.

Postscript: I can't believe I forgot the classic article on burnout, the electrocuted dogs experiment by Seligman: Learned Helplessness. This one has a positive spin to it, in that it suggests some therapeutic ways out of the syndrome. Happy New Year!

Innovation 1000: Companies Profiting from R&D

An excellent study of companies spending money on R&D over the last five years, and their payoff (or not): Smart Spenders: The Global Innovation 1000.

Some takeaways from this study:

Patents don't equal profit. Although a common measurement for innovation, it's a distractor: portfolio doesn't equal profit.

"Money simply cannot buy effective innovation."

There are no significant statistical relationships between R&D spending and the primary measures of financial or corporate success: sales and earnings growth, gross and operating profitability, market capitalization growth, and total shareholder returns. Gross profits as a percentage of sales is the single performance variable with a statistical relationship to R&D spending.... Researchers who study innovation estimate that 70 to 80 percent of the final unit cost of a product (the cost reflected in gross margin) is driven by R&D-based design decisions — for example, product specifications, the number and complexity of features in a device, the choice of standardized or customized parts, or the selection of manufacturing processes. This correlation of R&D spending and gross margin shows that in many companies, the R&D silo has succeeded in its narrow goal: creating a lower-cost offering that thus yields a wider margin, or a more differentiated offering for which a higher price can be charged.

R&D money is being offshored-- or innovation is now occurring in the "rest of the world" rather than Europe, North America, and Japan.

The "integrated value chain" of innovation shows that companies that leverage their "ideation" into commercial products more efficiently are seeing payoff. This makes sense, but seems to be hard to do.

Many high-leverage companies apply distinctive approaches to innovation at all four stages. For example, from the ideation stage through project selection and product development, high-leverage innovators tend to prize end-user input. The Stryker Corporation, a $4.9 billion medical technology company headquartered in Kalamazoo, Mich., works closely in R&D with the surgeons and other medical professionals who use its products. The Black & Decker Corporation’s innovation strategy is also heavily determined by end-users. “We’ve spent a lot of time focusing on where they work, where they play, where they buy, and where they learn,” says CFO Michael Mangan. “Understanding and developing those relationships really increases the efficiency of our new product introductions.”

There are two great stories of how two very different companies seize opportunities. SanDisk operates by watching the market for parts and capitalizing on opportunities offered by lower costs.

In the flash memory industry, prices fall 40 to 50 percent per year. Thus, at SanDisk, a small team of senior executives meets twice per week to monitor prices and market trends. Their awareness, fed back into the company’s innovation process, allows SanDisk to act quickly on new opportunities. In 2004, for example, the company realized that falling costs had created an opportunity for it to enter the market for MP3 audio players with a flash memory–based device. Management contacted an original equipment maker, defined design specifications, and delivered the new product to retailers’ shelves within six months. The SanDisk player is now number two in the market, after Apple. “We don’t have big planning and product committees,” says SanDisk Chief Financial Officer Judy Bruner. “Most decisions, even those involving huge capital commitments, are made pretty quickly by a small number of pretty visionary people.”

Symantec leverages shared code and a strong core engineering team that allows them to be nimble when responding to changes. “We have a large portfolio of products and business units,” says Ann Marie Beasley, vice president of strategy. “One of the key contributors to our R&D bang for the buck is that there’s a lot of common engineering and design, as well as actual code reuse.”

Not profiled in this article, I recently read an update on Philips Design in Fast Company: Design Intervention. Philips has been recruiting for at least 6 years for its R&D Lab, and I keep wondering what's up with them. This piece pointed out a couple positives from their output, which I recall seeing in stores, including the the Ambilight HD LCD display.

A 1995 Philips Design project called "Vision of the Future" was conceptually very similar to the Simplicity extravaganza in Manhattan--a flood of flash-forward products and ideas. Indeed, the concepts unveiled back then read today like a laundry list of the technologies that are changing our lives, including personal digital assistants and voice-recognition systems. Three years later, though, Philips went back to see how many of those concepts had actually gone into production and discovered that while a laudable 60% were already for sale, only 3% of them were made by Philips. "Their design and technical specs were usually good," says Enrique Dans, a professor at Instituto de Empresa Business School, "but they were disconnected from the market."

They're learning from history and adjusting, it seems.

"Philips's total sales from products introduced in the last year were 49% of total revenues in 2005, up from just 25% in 2003. In medical systems alone, an industry with long product cycles, some 70% of revenues came from products less than two years old--up 20 percentage points from the previous year. And despite disappointing LCD results in 2006's second quarter, from a less-than-expected World Cup boost, growth in Philips's medical systems and consumer electronics came in better than expected, at 9% and 10%, respectively."

I'm always impressed by companies that learn from history. And by good analysis in business. Edited to add: There's a nice piece here about a guy studying incentives for failures, a critical part of the innovation process. A lot of companies pay lip service to the value of risk-taking and failure in the corporate learning process, but few of them have incentive plans that reward risk-taking with failure rather than rewarding only the success stories. Employees aren't dumb when it comes to rewards vs. lip service and know what really counts to their managers.

Twenty About Design

I seem to update this one once a year. I wrote it when I was frustrated about the invisibility of design as a process and a skill at one company, and I've updated it to moderate it and expand and then contract it over the last 18 months. The latest update focuses more on hiring (a perpetual issue), teamwork, and recognizes management as both a problem and a solution in corporate culture.

Twenty Things About Design

Google Patents Sketches

If you like sketches of product designs, and things people patent (often very odd), I recommend Google Patents search. For the product designer, these sketches are often educational as effective communication tools.

Warning: Most software companies don't want you doing any patent searches on anything you work on, because it can get you in legal trouble if you have prior knowledge of existing patents when you produce new designs. So avoid searching on patents related to your current software design work!

Dennis Frailey: A Day in the Life

Last week I was lucky enough to be in a 3-day training course on project management. I was not entirely sure this course was a good idea for timing and content reasons, despite having a great interest in the topic myself-- but the instructor proved me wrong.

Rather than the usual consulting company instructor (these people often piss me off), we got a thoughtful, wise practitioner, who impressed all of us (a tough crowd) with his depth of experience in the software industry and his thorough research understanding of the problems we were facing.

Dennis Frailey's ACM "a day in the life" bio story is here. The university classes he teaches are described here. He has made career changes based on revised understandings of the "real" problems he encounters in daily work. I share his impressions about research and practice, although I've had far less experience than he has at either:

Although I loved teaching (and still do it on a part time basis), I quickly learned that survival in academia is based on "research", not education. And the numbers game rewards you for cranking out large numbers of papers rather than small numbers of really good papers. I did some innovative research in the areas of real time operating systems and computer architecture, but I found most of the really interesting work in these fields was being done in industry... And when I was granted tenure, I learned that the research that counted the most was what I had done for industry and could not have done in academia. Moreover, there is a certain sense of satisfaction one gets from building a real product that one cannot get by writing research papers. This led me to consider and ultimately to accept a permanent move to industry, which I did in 1977.

Once in industry, at the corporate engineering center of Texas Instruments (now part of Raytheon), I discovered something else. Most of the real problems are not to be found in the research labs but in the areas where real products are being planned and developed. Thus I migrated from doing computer architecture research to actually building computer and software systems that had to work. This gave me a deeper appreciation of the intellectual challenges and rewards associated with "getting dirt under your fingernails" so to speak. It also gave me a totally different understanding of what software "engineering" is... Once I had to make reliable systems that peoples' lives depend on, I began to appreciate the need for "engineering discipline" and for greater emphasis on understanding the processes we use to develop software. This led me to move into new parts of the company where I learned about different kinds of issues. Many years later, my varied background has qualified me for a senior technical position where I am expected to understand the entire scope of a problem, from the technical details to the management concerns.

I bailed from research for some similar reasons, during the dot com boom. I've also had the intuition for years that the hardest problems in building software are not the technical problems or even the design problems, but the management problems. Which may be one reason that UI design and usability methods haven't had the impact they should have had on the industry -- not because of lack of the value they add, but because lack of organizational historical data (of most kinds, but especially quality and process-related), management incomprehension and lack of good design and planning during the dev process, and resulting interdisciplinary confusion and contention when pressure hits. Not to mention that even without the design process differences that UI and usability introduce, complex software development management seems to be entirely lacking at many companies. Chaos, confusion, and conflict are the norms I've experienced in most schedule-driven releases. Few people can make the complicated, emotionally-laden tradeoffs required in a mature, big-picture style, because there just aren't enough managers with this kind of skill and vision.

You can tell a lot about someone from who they admire and why. Dennis's response to this question:

One man I admire is Eugene Helms, who was my first boss at Texas Instruments. He would often sit through a meeting, say very little except asking a few questions, and in the end would sum up the most important points - i.e., he listened, thought about what he was hearing, and put it all together. He also trusted those who worked for him to know more about their specialties than he did. As a result, he could see the big picture better than just about anyone else. He was kind and supportive, and he would stand up for what was right.

I admire Dennis, and I hope that says good things about me.

VPs as Indicators of Problems

Scott Berkun has a nice snarky post about VPs of Innovation; if you've got one, you're probably in trouble on that front, and it's not likely they're going to help.

Which reminds me of a company in my neck of the woods (not mine): they're created a "VP of Retention." I heard this from a friend recently, as we've interviewed a bunch of folks bailing ship from that place. Ok, kudos to their executive staff for noticing they have a problem; but sad and sorry it is that they had to "solve" it at that level, didn't notice before, and haven't done enough analysis internally to understand why they have a management disaster on their hands.

Management is the least recognized role and the most important, in these situations, in my experience.

A collection of professional essays...

The more involved in management I am, the less I feel I am doing things that I can point to and say "I did that." (Also, the less I work for companies that make consumer or well-known products, but that's a different issue and a weird trend I noticed a few years ago...) But I got the good news today that an essay of mine will appear in a book accepted by MIT Press for 2007 publication along with many others by names that I know from my field: luminaries, old friends, and former research colleagues. Most of the other authors are probably wondering who I am in this list; I feel honored to be there and to have been invited to submit something to it. Here's the info on the current Table of Contents: HCI Remixed: Essays on Works that have Influenced the HCI Community. (This book must be 500 pages long!)

We're all writing about previous work that influenced us, in a personal essay vein. It could become a nice secondary textbook in a reading course in interface design or human-computer interaction research. I was fascinated by the list of source papers and immediately downloaded a bunch that I didn't know myself. As soon as I flipped through them, I wanted to know what the other folks said about them. I can see the appeal of this collection immediately. Great idea, Tom and David.

Data and Infovis and "Art"

I've been thinking about data a lot, since the Infovis 2006 symposium. At this conference was a strange mix of scientists, mathematicians, and a few artists, or those with an artistic bent.

My friends Martin Wattenberg and Fernanda Viegas from IBM Reseach Cambridge secured funding, invited submissions, reviewed, set up the equipment for, and then sat guard over (missing talks in which they were cited) an art show of infovis applications. They were specifically featuring artistic displays of real data (I'm paraphrasing what I think they said were their selection criteria. One was Golan Levin's The Dumpster, which I blogged about a while ago.)

To introduce this art show, they gave an excellent talk that I'd summarize as "What's Going On Out There in the Real World That You Might Not Know About." A bunch of us saw a lot of people in the audience noting down the existence of Ben Fry's Processing Toolkit that makes programming datavis apps accessible to artists and ordinary people who aren't postdocs in mathematics. Sadly, it reminded me of 5 or even 10 years ago when the CHI and CSCW research communities realized web startups had already made community apps that worked and they weren't made by researchers in labs. Where's the actual innovation happening? More often than not, it's students or other clever people with time on their hands and a willingness to play around.

But back to data: When I was doing my dissertation, data was a sticky subject. Collecting data on "human subjects" was overseen by strict board reviews and ethical examination, and I had to go through this as an early internet researcher with a Human Subjects Board who didn't know what to do with this kind of data.

The community I "studied" reacted strongly to some of the data that I collected, post-processed, analysed, and reported, regardless of the reviews I went through. My data said some things that they didn't want made visible, or suggested things they didn't like simply reducible to graphs and charts. (The book is available here, the last chapter discusses this problem in some detail.) Anyone who looks at or exposes recorded human behavior is going to hit this: for example, people who don't think they talk much and discover they talk all the time often don't like knowing this, however measurable it is and however potential this exposure might be for them. Which brings up the questi0n of why and when should you turn something into data? And analyse it?

So, thinking now about how the research and infovis worlds have evolved since then, and the new inevitability of data mining on behavior from the traces we leave behind us, I see these data source dimensions:

1. Data sets that exist and are known to exist-- census data, weather data, stock market data.
2. Data that "happens" but isn't necessarily assumed captured or turned into a set that's easily analysable: email, chat, mobile phone records, my retrievals from ATMs, where I walk and what I eat.
3. Data that we set out to measure, because we're looking for something: experimental data, NSA tapping us, etc.
4. Data we have (from any of the above means) and we converted to another form of data: e.g., turning activity logs into summaries of time on tasks, turning gene sequences into musical notes, turning video of your cats into a single overlayed image, turning text into images, etc.

The really creative apps for infovis often seem to lie in item 4), because transformation of data into other modalities is a trick of visualisation that might give us insights we didn't have before. Some of them are just elegant visualisations of data we wouldn't have thought of visualising (like Ben Fry's zipcode applet that Martin called an infovis "haiku"). The "insight" part is still tricky to handle; human perception differs, and reasoning skills differ, and that makes drawing conclusions from visualisations tricky too. (Untutored people generally make more of statistical tests than they should, too.)

Martin and Fernanda stayed safely away from defining "art" but I still thought about the artistic component of data mining. The value of data mining and the ability to form and then test hypotheses from different views of data is a skill, perhaps even an art in itself. An event occurs: I capture it, I capture multiple instances of it, and I look for patterns in different views of it, and then I learn from it or measure it some more or in another way to progress towards some truth.

Or, for the more artistic data visualiser: she captures it and events like it, she presents it in a novel and beautiful way, hopefully with some elegant interactivity, and other people learn something. The might learn something ineffable or impossible to reduce to words. But that doesn't make it less important. Scientific creativity still springs from the indescribable ideas you have about the world before proof and publishing.

E3: Effective, Efficient, Elegant

Hi, my name is Lynn and I work all the time. Too much to post much these days.

But I had a nice break when I went to Infovis 2006, the symposium on information visualization. There was a bit too much math this year, starting from the keynote, which was Eades talking about graph layout algorithms. I still managed to get something thought-provoking from it. His criteria for algorithm evaluation was "effective, efficient, and elegant."

These are good principles for software design as well as algorithm design: a good piece of software should be effective at supporting the tasks it's designed for, be efficient in use and for use, and ideally is elegantly designed. Elegance, of course, implies more than "usability." Usability is a word that's got kind of an old school ugly lab study connotation these days; it's a word that doesn't say enough to capture current thinking about the value of delightful design, rather than just adequate design, in creating a differentiating user experience.

What's "elegant" in a proof or theorem, I asked of a friend who was a mathematician in his previous life. "Simple," was the first thing he said. But not just that -- it can be taught to a second year student, was one of Eades criteria (suggesting "learnability"). Yet also somehow "surprising." An elegant proof is a result with a twist you didn't see coming, but should have, adds an insight that makes it aesthetically pleasing.

At risk of triteness, I did look up elegance on dictionary.com after striking out in a Google search: "gracefully concise and simple; admirably succinct. Combining simplicity, power, and a certain ineffable grace of design." It adds:

The French aviator, adventurer, and author Antoine de Saint-Exup'ery, probably best known for his classic children's book "The Little Prince", was also an aircraft designer. He gave us perhaps the best definition of engineering elegance when he said "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."

E3 makes a good compound principle for evaluating design of all things, including software. I'd really like more elegance in my design.

The Powerset Blogstorm

Can anyone beat Google? Well, the natural language processing community is having a go at it. I got back from 2 weeks of vacation to discover that an old friend and mentor from grad school days is now at startup Powerset, co-founded by Barney Pell, whom I knew as a grad student in Cambridge years before. There've been a rash of articles in the blogosphere about their announcements, as Barney summarises:

Barney Pell's Weblog: The Powerset Blogstorm: 1 week later.

Yet more evidence that startups are back and interesting again! And this time they want UX people earlier rather than later, which is a nice change for the industry.

Why Crunch Mode Doesn't Work

I have long been fascinated (and disgusted) by the lack of government, union, or HR care for the abuse of workers in the software industry. During the dot com era, I actually heard it touted as an intentional strategy by some Silicon Valley managers to hire young programmers right out of school who would work long hours for little pay and were considered "disposable." Mostly, they were disposed of, by burn out.

This attitude was reflected a little more indirectly in the cuts in benefits and pensions everywhere including major companies like AT&T, layoffs in which senior people were cut on the principle that they were easy to replace; among other people mismanagement decisions that seemed to me to be incalculably stupid. Incalculable, unfortunately, because the decisions and decisionmakers at these companies were protected by layers of indirection (about the reasoning, minimally) and because there is profound difficulty in measuring the damage to the company, products, and customers, both long and short term. Stupid, because the people in the trenches doing the work understood the impact every day, in terms of workload, quality of work, culture, their attachment to the company, belief in the industry and in what they were doing...

More than one person I knew who was young and abused in the dot com era decided they were "getting out," went to open a record store (or flower shop) and never looked at a computer again. In an era of declining enrollment in computer science programs, we as an industry can't really afford that.

Here's a guy in the game industry--one of the most famously abusive software sectors--trying to make the case with a fairly well-researched article on the subject: IGDA - Articles - Why Crunch Mode Doesn't Work: 6 Lessons. Tagline: There's a bottom-line reason most industries [except the software industry] gave up crunch mode over 75 years ago: It's the single most expensive way there is to get the work done. Of course, in the software industry, quality hasn't mattered that much, till recently. Will things change? Will software management change? Will the calculation become easier to make to argue against the stupid?

And here's an article, only tangentially related, but I think still related, on why America is lagging in R&D. The State of Research Isn't All That Grand. R&D is being outsourced, because it's cheaper that way; and R&D is "hard to measure" because it's a long-term investment. Most American companies aren't actually that good at long-term anything, in a profits-now-or-your-bonus-is-impacted business world.

Why hasn't Built to Last had more impact?

Simple Names and the Stock Market

Not a result that will please some businessmen, but it seems that there is statistical evidence that companies with simpler names and/or companies with simple stock ticker symbols perform better on the market. Human processing may be the reason. Note, however, that it's not a sole predictor -- TiVO would have done better long term if it were, sigh.

In fact, across the entire NYSE and AMEX markets, Alter and Oppenheimer calculated $1000 invested in shares with pronounceable ticker codes would have netted $85.35 more profit after one day compared with an equal amount invested in companies with an unpronounceable ticker code.

Citation: BPS Research Digest: Why you should invest in shares with simple names.

Despair.com and Demotivation

I'm a big fan of despair.com. But handing out their posters could potentially get managers fired at the wrong companies-- maybe for the best! They've got other good products, including a funny book ("The Art of Demotivation"). I can think of a few people who need the pessimist's mug.

If you're having a bad day, I recommend their video podcasts. They will make you feel your life could be a lot worse. However, take care with the one on signs of a demotivated workforce. This one is on ZD Net, and the transcript lives here. It sounds a lot like the previous post I put up on "how to discourage innovation." An excerpt:

The fourth sign of a demotivated worker is acute defensiveness. As a result of their feeling defensive, they do extra work as a means of ingratiating themselves to executives. Now any time you can get an employee to do extra work, particularly for something as irrelevant as ingratiation, that's a good thing.

The fifth sign is employees feel acute self-doubt. As a result of their self-doubt, they will work very hard as a means of salvaging their identities.

The sixth sign of a demotivated workforce is the employees tend to feel a lack of emotional resilience. Now this is very important, because employees don't want to feel badly about themselves, and so consequently they will work extra hard to avoid humiliation. Though they tend to avoid seeking recognition, they will work very, very hard to avoid humiliation.

And then the seventh sign of a demotivated workforce is intense risk aversion. And this is very, very important, because employees are so unwilling to take any risks on their own, they will tend to be satisfied with simply being an extension of executive ambition. As a result of that, they will essentially do whatever you're asking for, and really that's what we're looking for.

Top ten tips for preventing innovation -Tyner Blain

Apropos the bad mood I have about innovation rhetoric: Top ten tips for preventing innovation by Tyner Blain. Gotten off Scott Berkun.

This funny but painful list covers:

• Hire employees looking for safety in their roles. Find people who primarily want security and a nine-to-five role, stay away from those troublemakers who want to “change the world.”
• Hire incompetent employees.
• Keep salaries below the 75th percentile. Innovators know their value - and when they aren’t applying for jobs with intrinsic utility to them, they are commanding higher salaries. If we keep our salaries low, there’s much less risk of one of these innovators sneaking into our organization. As a bonus, we’ll save a fortune!
• Treat employees like garbage. Yell at them. Whenever possible, call them at midnight to yell at them some more. They work for us. If they get uppity, make them work on the weekends. Make them dig holes and fill them back up again. Threaten them - especially when they need the job. If you can’t yell, at least be condescending in public forums. Remember we are smarter than they are. Punks.
• Reward conservative and marginal successes. The old rule of thumb for office politics was “It takes ten good projects to recover from one bad project.” Stick to it! If we punish people for mistakes when they ’swing for the fences’, and reward them for marginal and safe projects, they will quickly get the idea. This is the most subtle of all the tips - but don’t worry - people will figure out the reward system and shy away from those risky projects. This technique has the added benefit of propogating itself up and down the management hierarchy.
• Micromanage. We’ve been promoted because we understand their jobs so well that we could do them in our sleep. Whatever those pesky little people think, it’s wrong.
• Only create customer-requested features. Let our customers tell us what to do. ... Oh - and don’t second guess the customer. If they say they want the menu items in alphabetical order, well, that’s what they want. The customer is always right. If Henry Ford had listened, think of how fast horses would be today. Even better, appoint a user-representative, then we don’t have to talk to the customers at all.
• Build a kingdom. When we have information, that means we have power. With that power, we can grow our organization. The more people we have, the more important we are. We need to make sure that those other teams don’t get our information. They might apply it in ways that we didn’t intend. While we’re at it - make sure our people don’t find out what we know. Not only will it protect us from them, but it will keep them from accidentally discovering a more important problem, or an alternate way to apply what they already know to a new problem domain.

It's an excellent list.

Business Innovation & Design on BusinessWeek

There's a new portal site with articles on Business Innovation and Design at BusinessWeek Online.

I'm trying not to be in a bad mood about the rhetoric around innovation right now. One of my favorite industry commentators, Scott Berkun, is writing his next book on innovation, and innovation has somehow gotten nicely linked with the concept of design, "user experience," and good customer research. There's an article on ethnography's role in market research on the new portal site (The Science of Desire). Google claims in its recent job ads that one of their core philosophies is "Focus on the user, and all else will follow." eBay claims in its last job ad for a UI designer that the position involves "contributing to a culture of innovation and teamwork."

It all sounds like Mom and apple pie, but the truth is it's oversugared store bought corporate pie, not the kind you want to get from your own oven. The truth is that innovation on the job isn't what most managers can handle or want to see because it's disruptive, and management is hard enough without people being creative right and left while you have schedules to meet. (Er, but not me. Did I say I'm hiring? And to be fair, this report by Donna Bear does point out the difficulties inherent for management execution of the innovation goal.) But, clearly, innovation and good design don't necessarily run together at all times.

Google is an excellent case in point. It's foolish to conflate the new, different, and envelope-pushing with stuff my parents will understand, if they make a good yardstick. Flickr doesn't yet pass the parent test for me. Yes, I know that Yahoo -- with a better history and culture of usability than Google -- owns them now. But that fact also gives me hope that one day Flickr will really work for my photoblogging needs. Google's eternal early-launch betas with iffy design and functional incompleteness aren't yet professional caliber user experience, no matter what they claim in their job ads. And I think the stock market forgives them and even celebrates it, which goes a ways to explain my bad mood. Gmail is incomprehensible to my massage therapist who doesn't understand the difference between what's on her hard drive and what's in her email. It's undoubtedly different -- hence "innovative" -- but is it too different for ordinary people to use? Perhaps.

My massage therapist does not care about Google Earth, incidentally.

eBay. Many of their UI designers (and other customer-focused staff) are now bailing for new gigs; what does this say about their culture of "innovation" for designers?

Finally, what does it mean as a company to say you are focused on customers and design, but to employ no researchers with social science background or designers who are non-technical? Where is the diversity that leads to true creativity? I've seen this at a number of companies, of course.

Remember when the major R&D labs shut down or radically downsized in the late 1990's? I don't see enormous evidence of a change of heart, apart from perhaps the new Yahoo Labs. I have friends at other research labs that are feeling underappreciated, underpaid, actually bored, and are looking around now; some of those labs are profiled on the innovation portal.

It's not very convincing, is it, even if you want to believe. Ethnographies of companies that claim to be doing ethnography, or more mundanely, claim to be promoting "innovation" and/or claim to be focused on design and customers, could be damning. Business hype is easy, execution is a different thing.

Daily Hassles

I've been tracking my time, in part because we were asked to (for budgeting better on the next release cycle) and in part because I just love the data-centered view of the world. Buried in the details of everyday life, we don't see the big picture, and this kind of time tracking exercise helps. (God forbid I do it for my non-work life, that would provide a level of big picture insight I don't feel prepared for right now.)

A while ago there was a small kerfuffle on the 37signals blog about the uselessness of meetings -- the gist of the post from the ballsy, tiny small startup was "meetings are a waste of time, just get down to doing the work." This caused the usual response from the less big-mouthed, possibly more mature crowd of readers with experience at larger companies or on more software teams: "Not all meetings are a waste of time, and maybe you guys are a special case in some ways." I was one of the readers who was irritable, because I genuinely believe that without meeting-time, we can't produce coordinated design work on complex products and we can waste a huge amount of time in email (delaying critical work) and acting on poor or poorly understood information. Project risk increases without meetings as a forum to be sure everyone understands what's going on and what's next.

That said, I do believe there are inefficient meetings, and teams that revisit decisions made in meetings undermine meeting usefulness; and meetings that go badly have the ability to damage relationships and project work as much as they could have improved things and made projects more likely to be successful. To add to the list of my many opinions on this topic, meetings are a place -- sometimes the only place, which is worrying in itself -- for necessary social chitchat interactions (on the meeting margins) as much as for making project progess, and folks who don't care about that aspect of face-time are more likely to have meetings that go bad and cause project damage.

But I went off and did some research on the topic of meetings and stress and found this article: Meetings and More Meetings: The Relationship Between Meeting Load and the Daily Well-Being of Employees (pdf, Luong and Rogelberg).

Defined in the stress research literature as “annoying episodes in which daily tasks become more difficult or demanding than anticipated,” hassles have been found to predict stress symptoms better than most other predictor variables (Zohar, 1999, p. 265). Varying from equipment malfunction to inappropriate behavior of coworkers (Zohar, 1999), such obstacles predict an array of stress-related effects, including burnout (Zohar, 1997), anxiety, depression, and other negative emotions (Koch, Tung, Gmelch, & Swent, 1982; Motowidlo, Packard, & Manning, 1986).

More or less, one of the article's findings is that meetings annoy people because they aren't seem as a goal in themselves, they're a necessary evil that's often, in poor cultures, really evil in practice. They are seen as hassles, instead of work in themselves.

Digression: I remember a friend, on moving from engineering management in which he still wrote code to higher level strategic management, having the realization that meetings weren't getting in the way of work, but instead, "Meetings ARE my job now!" I also remember a developer at Adobe realizing that the number of meetings my UI colleague and I had to have with his project team to move that design forward were the tip of the iceberg in our lives; you effectively multiplied those meetings times the number of projects we were assigned to, to reach the total of some ridiculous number of meetings we were responsible for calling, preparing for, and documenting afterwards in order to produce specs, which was our perceived "real" job. We were always borderline psycho, of course, in a constant state of frenzied stress, prone to freaking out if a pen ran out mid-use or the video conference system needed rebooting and we lost 10 minutes of meeting time.

But back to the above quote. Say meetings are a necessary evil, and viewed in a better light, a significant part of work in themselves rather than a blockage to doing "real work." Then, maybe the other hassles in our workday that are genuinely just hassles rather than misunderstood work might be "fixable." Like the bad pens and video systems.

In one of my favorite books, Management of the Absurd, Farson cites Maslow on the hierarchy of grumbles in organizations. The gist is that people always complain -- it's a human fact -- but the category of complaints is significant. Grumbles about equipment, the "hassles" of the above quote, are the most worrying, because they mean that low-level needs aren't even being taken care of. Hassles that interfere with the "real" work add significant stress, and are invisible to many managers. These could be the equivalent of the food and safety level of office needs. (Admittedly, the threat of arbitrary job loss is something that's a bit more "safety" related and counts as more than a "hassle." So my parallel may not be entirely fair here...)

Farson says that a better company will have people complaining about higher order issues like the source of credit for work, whether there is truth and justice in the office, about the opportunity for creativity and self-expression on the job.

Everyone is working at capacity these days, it seems. But folks who are most stressed may be stressed because of too many daily little hassles. I'd put on the hassle list the inability to schedule a meeting room, or frequently-used intranet software that fails 50% of the time because of a server issue that hasn't been taken care of. People who are already working at capacity are especially prone to not coping well with the little hassles -- but they are actually a lot more fixable than the higher order issues people face at higher order companies. So I guess there's some good news if you go looking deeper at the sources of workplace stress.

(Here's another citation from Zohar's work on work stressors: "When things go wrong: The effect of daily work hassles on effort, exertion and negative mood" (pdf).)

Jobs on BayCHI

This weekend, Don Ahrens announced that he wouldn't be posting the BayCHI job list anymore. This important job listing is on hiatus till another owner can be found and trained.

It's easy to say Don did the user experience profession a great service with this list, but it's very hard to imagine where some of us would be without it. The BayCHI chapter of the Special Interest Group of Human Computer Interaction (SigCHI) is a major force for professional good, offering great talks by industry stars and important networking opportunities. (I just looked at their page and discovered that a friend from the UK whom I haven't seen in 10 years is speaking this month, and I'm missing it!) The Bay Area is the spiritual home for user experience professionals, rivaled only by some odd corners of Scandinavia. That job list, to which many non-locals subscribe, is one of the best ways to track industry opportunities in interaction design and usability. Watching that list gives one important insights into what's going on at major software companies. Jobs outside the Bay Area are regularly posted there, because of its large readership and the recruiting pool that exists in the Bay Area. I myself have been reading it since grad school.

In honor of Don's tenure (how long HAS it been? I can't remember when he didn't run it!) I've made a few retrospective graphs of the job list contents from 2003 to 2006.

Unsurprisingly, the growth of the stock market matches the growth in the raw number of job postings appearing on the baychi list. We're averaging around 70 to 90 jobs every weekend right now, incidentally. This picture shows the raw counts of job posts overlaid on the percentage growth of the NASDAQ.

If we look at the actual companies posting jobs, it gets more interesting. By raw counts, you see some of the big tech names you'd expect to see.

Check out the major players in user experience on the left edge.

Now, these are dumb data points -- we know nothing about actual filling of positions, or how many times a job was reposted or how many positions each posting represented. One major caveat there: the Google NY jobs have been open for almost a year, I think, without disappearing, so this is inflating some of their stats. The Trend Micro positions in East Asia were likewise open forever.

Regardless of the potentially misleading nature of these numbers, the stats do get more interesting when you compare the size of the company with the number of UX jobs posted on the baychi list. For the public companies that I could track down, I resorted by the higher ratios, and this shifts the list tremendously. Microsoft, for instance, falls way back down, as does Oracle.

As a former TiVo employee, I am not surprised to see them leading the pack (even when I know that their numbers are probably inflated by difficulty of hiring, and recent departures of key folks -- but then, everyone has this problem, right?). More interestingly, Shutterfly comes in second now. Shutterfly is where my former UX Director from TiVo, Kyrie Robinson, landed post-TiVo departure. Ah, suddenly not so surprising to see Shutterfly second to TiVo. (She has just left Shutterfly to take a VP role elsewhere with the words "User Experience" in the title, a rather rare position name.)

Now, what jobs are being posted? Simple word frequency on the titles shows us an interesting pattern...

Senior interface designers top the most wanted (or bottom, in this graph). Usability and user research positions trail rather in comparison. This is actually a nice trend for the industry, since Don Norman noted a few years ago that "design is where the action is." As a hiring manager seeking senior UI designers, their popularity is bad news for me; it's very, very hard to hire them. There aren't enough, and they're clearly in high demand.

From the founder of Motek

A couple of months ago I posted about Motek, a woman-owned company offering sufficient vacation days to let employees come back to work enthusiastic, practicing enlightened management policies that secure quality of life on the job, not just despite the job, like most companies.

I received a number of interesting comments on that post, one of them from the founder. The authors of Peopleware would pretty much agree with Ann Price, I think. I snip here, since summer is a good time for a reminder about big life lessons.

I'm honored by your blog. Motek’s a small company making a difference in an ominous world that left millions behind. While Microsoft creates more software for the desktop we give computers to the desk-less. We automate places still using paper & pencil to track inventory. In case you're wondering that's 85% of the nation's warehouses.

Along the way we try to improve the quality of people’s lives by shunning sweatshop environments that expect people to work nights and weekends. Our product enables companies to get more done than they did before so they can eliminate overtime. This delivers cost savings for our customers and quality of life for their employees.

...I started taking 1 month vacations when I was 22 year old GE software consultant. No, GE's vacation policy didn't accommodate me. As an employee who'd only been there 1 year I was given 1 week off. So I told my manager I needed to take 4 weeks off for personal reasons but never provided details. I didn't care if he thought I had breast cancer or a death in the family as long as he understood it was non-negotiable. Sure it was gutsy, but the lesson was invaluable. I learned I could do it. I learned I could live by my own rules and have done so ever since.

Anyone waiting for their employer to enable them to live is missing the point. Try to understand. You don't look the same on the beach in your 40's. You don't feel like climbing the steps at Machu Pichu at 35. As I tell all Motek employees: the time to go is now. Once people realize their employer isn’t the obstacle money comes up. People inevitably say they can’t afford to take a month off. When I was 22 I didn’t have any money either. And back then (20 years ago) there were no frequent flier miles on credit cards. I found a book called Air Courier Bargains. Yes I actually flew as an air courier to Asia. Even though I can afford to fly anywhere I want these days I still put every expense I can on my credit cards to accumulate miles. You can pay your electric bill and mortgage on a credit card today. I always have enough miles to travel and get away. I believe strongly in recharging your batteries and although I spend 3 weeks a year on vacation with my husband I always start or end my trips by spending at least 1 week all alone.

Yes, I’m passionate about this topic. I truly believe all my other business ideas have come from my ability to step away from work and think about how I want to work. Success is 1% inspiration and 99% perspiration. Without the inspiration you may be working hard but not necessarily smart.

Design Success Factors

About six months ago I was interviewed as a followup to a survey I had answered about factors that influence successful adoption of design and usability practices in the corporate world. The survey ended with a writein box asking for the most important factor, and I was unable to write just one. The phone interviewer wanted me to pick a single response from my two, and I still can't; in fact, I'd add a third.

Executive Support, or more generically, management support up the ladder to the top. There are subcategories on this one, of course, because support manifests in different ways as needed and where needed. The most important is in recognizing the need for design as a value of the company, and investing in it. This means funding the right teams and instigating the right processes to allow it to happen. "Processes" are a bit vague as a concept, but essentially entails setting up a context in which "design is being done by the designers," i.e., they are enabled to do it, and other people who want to do it or aren't skilled at it are disabled from doing it. Of course, this cashes out in the daily nitty gritty of development meetings in which everyone may have an opinion about design (they will), where there must be a culture and a recognition of the fact that someone in the room has a better track record at being right in their judgments. Even if they make it look trivial and easy. In fact, especially if it looks trivial and easy.

Hiring well is the second factor, most important when you are trying to make the case for good design in a culture-change way (a pretty common experience for most of us, although getting less common, thankfully). I used to think this was a matter of just finding good designers, but that's only a small part of it. You also have to hire people who can work with good designers, which is not usually a factor considered by hiring managers in the rest of the organization. The more design "thinking" pervades the culture (from management messaging) the likelier it will subtly influence hiring in the non-designer roles, I believe. (Trivially, for instance, it's less likely that a product manager or engineer will be hired on the grounds that they are also "good at making icons" if there is someone on staff understood to handle that job already.) There are a lot of other personality and skill factors that influence doing successful design work, though. During the hands-on, day-to-day interactions in which design discussions happen and decisions are made to do one thing or another, the person on the ground has to be able to deliver when the context is good in which to produce and other people are listening.

(Hiring good designers is shockingly hard. Most UI designers can only list a handful of others they think are good. The "why" of that is another topic.)

The third item I'd add, which may seem obvious, is Development of good designs must be possible. This could conceivably fall under the management of processes, but I think it's worth calling out as a first class item. It does you no good to have designers who are good in a company that theoretically wants good design to happen, if there is no way to execute technically. The code itself and the timetables for work must allow design to be implemented; not just features, but designed features. I think Don Norman has a riff on this somewhere, and I know people who live in UI standards "police" roles wrestle with it all the time -- the toolkits used should enforce easy compliance with standards, not make it hard to honor them, etc.

And that's my third, for this six months of reflecting on the professional topic I care most about.

Peopleware

Kevin Kelly's excellent Cool Tools email reminded me of the classic Peopleware, by Tom DeMarco and Tim Lister. I think my copy is at the office (a foolish place for it), so I have to quote from Kevin today.

Hard-won wisdom fills this small book: How to create a team, place, or company that is productive. First published 20 years ago, and updated once since then, copies of it have quietly served as a guru for many start ups and successful projects in Silicon Valley. Neither academic nor faddish, two veteran consultant authors offer real intelligence. This book has totally informed how I do projects. I learned about the myth of overtime, the need for closure and ceremonies, how teams jell, and why everyone should and can have a window. I first read it decades ago and re-read it every time I embark on anything involving more than one person and several years of my life. Unlike a lot of management lore, it is aimed at the project level (where I want to be) rather than the large organization. The message in the book touts productivity, without ever mentioning the dreary idea of time management. It's more about optimizing people, and thus the title, Peopleware.

I've posted before about teamwork and invisible work, and Peopleware is all over this stuff. Here's an anecdote Kelly cites from the book:

I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me to request that I assess some of the people in the course (his project staff). He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project -- she's not a great developer or tester or much of anything." With a little investigation, I turned up this intriguing fact: During her twelve years at the company, the woman in question had never worked on a project that had been anything other than a huge success. It wasn't obvious what she was adding, but projects always succeeded when she was around. After watching her in class for a week and talking to some of her co-workers, I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there. She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out. He just didn't recognize the role of catalyst as essential to a project.

Which reminds me of the need for root cause analysis of successes. At one of my previous companies, we had a big focus on root cause analysis of problems in order to avoid making them again. In itself this was laudable, but there wasn't quite the same focus on root cause analysis of success. Unless you want it to be accidental, lack of root cause analysis of success might prevent repeat performance of success by not recreating the same conditions that led to it in the first place. Not understanding the role of team members and not understanding how to diagnose team success, except in terms of org charts and job titles, can contribute to this management misstep.

I've concluded over the past few years (and it's the subject of an article I'm supposed to be writing), that project level management requires an anthropological mindset. If you aren't interested in the news from the field, and in forming conclusions from raw data from people doing the actual work, you are more likely to form erroneous or overly "easy" conclusions; you have to instead rely on standard management book guidance and act on previously filtered information that's highly likely to be biased or dangerously incomplete. Sure, every modern anthropologist admits her own biases play a role in terms of what she sees and hears. But wouldn't you, as a manager with sufficient time, rather be filtering the raw data rather than taking in someone else's biased filter? A few design and project train wrecks can be avoided by talking to the right people at the right point, when there's time to be an influence for the good.

Joel on Being in Control

Excellent post by Joel Spolsky on the latest release of his bug tracking software, with a lot of design observations: FogBugz 4½ and Subjective Well-Being - Joel on Software. Complete with management advice, tying back to the theme that management is design too.

...the most important thing that I learned in Psych 110, the idea that when people are successful at controlling their environment they become happier, and when they can't control their environment, they get grumpy.

How do you achieve delivering a feeling of control to a user in an application? Well, good feedback and speedy response are critical elements, otherwise the user doesn't emotionally connect her action to the resulting behavior of the software. Oh, and predictable outcome from user action, of course.

Also, drat him, he got one of my hobby horse design ideas that I never understood why we didn't do at Adobe (I know that's ungrammatical)... A toggle to reveal to you the keyboard shortcuts for each app buttons so all you have to do is look and then type it. No annoying mouseover in order to find out and then force one to remember it. So simple, so obvious, so NOT DONE ANYWHERE (that I've needed it, anyway).

Brett also snuck in a feature he's been itching for: lots and lots and lots of keyboard shortcuts. There's only one keyboard shortcut you have to memorize, though: Ctrl+; switches FogBugz into keyboard mode and little letters light up reminding you what the shortcuts are for various commands around the screen. It's really pretty cool to be able to work through a bunch of cases, assigning, editing, and reprioritizing, without ever reaching for the mouse.

Management, Design, Evidence

Another one on Kawasaki's blog impressed me today -- I'm just in the mood for thinking about management, as someone trying to hire now. Kawasaki posted Ten Questions with Bill Sutton, author of Hard Fact, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management.

My boss and I spend a certain amount of time discussing how to measure what we do and determine success, a particularly difficult problem for a design organization. We aren't, after all, able to conduct experiments like having two teams in isolation working on the same problem, one with design process and deliverables, the other with none. Sutton advises that if you can't do a controlled experiment, at least make sure your supposed cause precedes your supposed effect :-)

Sutton also comments on a few "evidence-based" writers on management and innovation:

I also love Larry Prusak, the knowledge management guy. He is smart, well-read, humble, opinionated, and evidence-based. And much better read in academics than any academic I know. ...

I also like Malcolm Gladwell and Steve Levitt and their models of evidence-based management. Although, I think that Blink is much weaker than The Tipping Point because Gladwell misses that the instant judgments he praises are developed through years of experience. You have to do a lot and think a lot about something before you can do the blink thing.

Finally, a prediction, I think the next big guru, at least if ideas and ability to present them counts, is Chip Heath of the Stanford Graduate School of Business. He has a book coming out with his brother called What Sticks about the kinds of ideas that people remember and what persists. It not only is based on sound research, it is also hugely practical (I’ve seen executives get so excited by his stuff that they immediately grab him for gigs).

Design management is a special kind of management, and requires special kinds of innovation grounded in both evidence and insight. I've been reading and enjoying Managing as Design, another Stanford Business product. It's a great collection of fairly academic and thoughtful pieces on organizations and management especially around design, with a fair amount of thought on architecture in it.

Edited to add: I forgot I meant to talk about evidence in management and the role of conversation and email in decision-making. Scott Berkun reminded me in his post on The Things You Never Hear. There's all sorts of decision-making in organizations that's based on slim or biased reporting from the "ground" and managers often never hear -- or don't want to hear -- the things that would make them more effective. Worse, in a social networking sense, there's diagonal or peer-level information that would be useful, that the relationships or physical proximity or office politics don't support hearing. Gossip can be important in an office, but it does need to be evenly spread to be of a useful evidential nature. There's another whole post in this somewhere, though...

The Top Ten Lies of Engineers

Another good one from Steve at tingilinde, this made me laugh in my coffee: Guy Kawasaki: The Top Ten Lies of Engineers. I already posted Scott Berkun's Things VP's Never Say, and this makes a great complement. Things lots of engineers say... whether intentionally lies or not. A sample:

“Our beta sites loved the software.”In twenty five years of working in technology, I've never heard a company report that its beta sites didn't like its software. There are three reasons for this: first, many beta sites are so honored to get pre-release software that they don't want say anything negative. Second, most beta sites haven't used the software very much. Third, most beta sites don't want to seem cruel by criticizing a company's new product. Doing so is as socially unacceptable as telling someone that his baby is ugly.

“I'll comment the code, so that the next person can understand what I did.” This is a lie of good intentions. Really, the engineer did intend to comment the code but as the schedule slipped, priorities changed. The question put to management became: “Do you want me to comment the code or finish it sooner?” Guess what the answer was. Luckily, the lack of comments usually doesn't matter because the code is so crappy that a total rewrite is necessary in a year.

NY Times' market graph toy

I'm only calling it a toy because it's fun. All infovis should be fun, frankly. This is another one off Information Aesthetics: the Sector Snapshot. You can pan around, change the dial for time window (weekly on up to quarterly or yearly), and hover over both the bubbles and the text (and sort the text). You can get a detail view of an individual performer in the lower right by clicking on a player. The animation is really nice and you can even change the graph units by direct manipulation. Sweet!

Berkun blog » Vista and Victimization and More

I've been catching up on some of my favorite reading after being away and then swamped at work -- today it's Scott Berkun.

In The Vista saga: an opinion, Scott gives his take on the delays of Vista at MS and what's being handled well or poorly, from his viewpoint as a former Windows PM. A couple points: "A slip is infinitely better than a panned product." and "Microsoft’s PR and public management of the Vista project has been reactive and weak." Here's a sample:

Centralized authority and MSFT culture. The most comical misperception about Microsoft is the management style - everyone think’s it’s a rigid hierarchy, when it’s mostly a consensus driven place. Everyone gets an opinion and senior managers are often more skilled at consensus management than leading teams. If there’s any one thing I’d point to for large failing projects is lack of successful central authority - With a project in trouble I’d move to centralize power in a smaller number of people and free them to run with the ball. The rub is that the culture doesn’t support this well - people still want a consensus mentality (something born of small team and start-up culture), they want to own their slice, even when it’s contributing to driving projects into the ground (or at least mediocrity). It’s in the fiber of the company and it’s hard to change.

Sinofsky is an inspired move. The MSFT culture, historically, is heavily polarized between Windows and Office. In my day Windows were the smart-ass cowboys who liked risks and breaking rules - not surprisingly Windows had a history of confused early projects that came together only on the home stretch. Office (again, in my day) were stereotypically smart, reliable, consistent A students, who won through plans more than passion. Sinofsky (formerly the Senior VP of Office, now VP of Windows) is the first major attempt I know of to bridge those philosophical and management differences: there’s something to be learned in both directions.

In another recent post, Berkun discusses a fascinating and cynical piece on Victimization Metrics for taking on projects.

Basically the idea is this (a now corrected paraphrase of his post): A = Number of problems you see
B = Number of Problems you don’t have the power to solve
B / A = Victimization ratio.

So if you work in an environment where you can point out 10 problems, but are only capable/empowered to solve 4 of them (so 6 you are powerless on), your victimization ratio is 6 / 10 = 60%.

Not being cynical by nature, Scott adds a couple factors, and inverts the ratio to call it the "empowerment ratio" instead. Nice reading and timely given my current project load. :-)

Finally, his next book is on innovation; he has asked for and gotten a number of recommendations that make interesting reading. (In another post, he summarizes the Amazon sales figures of his project management book over a year as correlated with essay posting and other publicity events --slashdot had the largest influence on Amazon sales figures. Nice.)

Ten things VPs never say

Scott Berkun posts about Ten things VPs never say, including: "Team A is more important than Team B," "the CEO and I disagree" (Leaders fear showing dissention, despite signs for those paying attention), "My morale is low," "I’m ending project X and here’s why," "No, I don’t want to be on the cover of Time." (To want to be a VP requires an ego. No person in the history of the corporation has been forced, at gunpoint, into executive status.)

All this entertainment aside, I've known a few nice VPs, especially at Mathworks (hi Roy if you're reading). (And I bet my new CEO would have said some of them as a VP, which is why I like him.)

[Updated to add: A VP reader of Berkun's blog took offense politely and Scott apologized for the stereotyping. One of the interesting things this VP cited was Joel's article The Development Abstraction Layer, about the infrastructure of management that enables delivering code to the customer, and the complexity of making it work well. It certainly made me think about the Design Abstraction Layer, and if/how that works -- but by Joel's analysis it's just a layer in the development management problem, which may in fact be correct thinking. Go read and see what you think.]

plusminus design: flashbag

This is one of those brilliant and simple ideas, that also happens to be funny. A USB device that "fills up" visibly until it's ready to explode, at which point the drive is full: plusminus design: flashbag. (Off Information Aesthetics, where else?)

I Am Hiring

Are you or do you know a senior interaction designer? I am looking for a couple such folks. I want smart people, with a good understanding of data analysis and problem solving skills, with some humility about their design work and willingness to change it based on input. Depth of design experience, ideally on desktop software, is required for these positions, as is attention to detail and willingness to drive issues through implementation.

The job is described here: Autodesk Jobs. (It doesn't seem to display well in Firefox, although the gist is clear.) Please pass it on.

Google Finance.

This is an new vis tool for showing stock performance correlated with news events: Google Finance (I pre-loaded my own company's data here). You can adjust the window you're seeing by size and location, and see the related stories associated with peaks and dips. It's kind of fun, although I wish they'd laid the page out a little nicer.

Motek, A Very Strange Software Company

I just read this article in the in-flight magazine on my way home from a short trip to Scotland: American Way Magazine: The Best Company to Work for in the World-Period.

As someone who needs at least a 3 day intro to a vacation to even start to relax, the European-style 5 weeks of vacation initially caught my eye and kept me reading. The rest of the story brought tears to my eyes (and I read a fair amount of business overview articles, for your average UI designer). A woman-owned company, with acknowledged lower salaries and internally published salary levels, in return for real quality of life outside the office? But that's not all.

Employees also know when an employee isn’t able to keep up with the workload. The result? Price offers a financial reward to employees who ask for help in order to stay on schedule. “The goal is to get the work done, not establish a star system,” she says.

Of course, it’s one thing to conjure up a cutting-edge culture and quite another to thrive amid relentless daily pressures. But Price hasn’t overlooked this aspect, either. While other companies talk about collaboration, Motek lives it. The company keeps a single to-do list... so that everyone is on the same page about priorities and the state of various projects. Anyone can enter an item, including customers and vendors. The list can include everything from ordering ink cartridges to customizing a specific function for a customer. Motek divvies up the tasks at meetings — and teams don’t pay any attention to who entered particular items.

The way Price sees it, the company’s success is a direct result of the money it invests in employees and of its commitment to developing a business structure that fosters knowledge-sharing and mutual goal-­setting. What’s more, “It’s amazing what a rejuvenated person brings back to the office, not just in terms of great new ideas but also in terms of enthusiasm and desire,” she explains. “The software industry’s idea that employees are entirely replaceable is absurd.” In fact, she believes it is precisely because of long hours and poor working conditions that today’s software is so buggy and behind schedule.

Apart from mourning that they are located in Beverly Hills (although I really do love my current job), it's now my goal to find other studies supporting her assertions. Let me know if you know of any...

Here's Motek's News page with links to many other articles about them.

Projects: Succeeded, "Challenged," Failed

The Standish Group have done numerous studies of software project success and failure rates over the last 10 years. They've observed some trends in project management suggesting things are marginally improving out there.

In 1995, their report identifies these key factors and associated weights contributing to project success:

SUCCESS CRITERIA	POINTS
1. User Involvement	19
2. Executive Management Support	16
3. Clear Statement of Requirements	15
4. Proper Planning	11
5. Realistic Expectations	10
6. Smaller Project Milestones	9
7. Competent Staff	8
8. Ownership	6
9. Clear Vision & Objectives	3
10. Hard-Working, Focused Staff	3
TOTAL	100

As you can see in the graphic below, in 1994 the the success rate for projects was only 16%, while "challenged" projects (over time and cost) accounted for 53%, and failed (canceled before completion) accounted for 31% of all projects. In 1998, 26% were successful. Then in 2004, we reached a 29% success rate. Project costs are higher and the success rates are lower for larger companies.

The 1995 piece has a scorecard to apply to your project to help you assess your potential for success. They're good questions (but a little intimidating even in 2006).

The 1999 report is quite sobering; they suggest that project size, team size, and project duration are the major factors correlated with success. They identify project management and standard infrastructure as crucial factors for team success. (Their comments on project management are well worth looking at, too, including the role of mentoring project managers.) I am quite sure that Scott Berkun would agree with them.

In 2001's report, they state that executive sponsorship replaced user involvement as the number one critical factor, because the IT world had caught on to the user involvement philosophy. Staunch business and management support now trump requirements analysis and user review of product design.

Finally, here is a telling quote about written communication on projects, from their original article:

Achieving the answers to solving project failure often lies in developing written communication such as problem statements, project plans, and detail specifications. However, one of the problems with any written communication is the participant's (reader's) level of understanding. As technologists, we think, write, and talk in a manner that is not readily grasped by many people outside our industry. Aside from sounding intimidating, you run the danger of the reader actually thinking they understand what you are saying, while your meaning may in fact be entirely different. To paraphrase the words of the English poet, Samuel Taylor Coleridge "Until you understand a reader's ignorance, presume yourself ignorant of his understanding". In other words, write the document devoid of all technical terms and pseudo technical terms. This includes words used by our industry, but rarely used outside our industry. Words like paradigm, metric, abstraction, and orthogonal, should not be used in any document if you want the normal reader to understand. Remember it is your job make the reader understand the plan. It is not your job to show how smart you are or to demonstrate that you can use big words.

Sadly, "phenomenological" is probably not a good word to put in a spec either.

Office Networks in Business Week

I've been catching up on some social network blogs, and have pointers to 2 short pieces I enjoyed in Business Week Online: IBM: Untangling Office Connections and The Office Chart That Really Counts.

In the former article, Kate Ehrlich at IBM Research notes that you want weak ties to fuel innovation, but strong ties to execute on it.

I think of the process of innovation as having three different phases: One is the generation of the ideas, and that's where you really need to have, not everybody in a group, but a few people who are connected to people who are outside. That's where you get these real "Wow, I never thought that something from that domain could be applied to this domain." So when you're talking about innovation, you've got to have somebody who can bring in the ideas from the outside.

In the second phase, you need to connect those people with others in the organization who are translators, who can say, "I can see that that idea might work in the company or group that you're in, but this is what we need in order to make it work for our product or our service or our process."

Then there's a third phase. You've translated it. You've got it set up. Then it's the delivery, and the delivery now is internally within the group. Now you want very strong ties between people. In network parlance, with innovation, you want weak ties, where people are more connected to those outside the group. [In the delivery phase,] you need strong ties in order to get the innovation executed.

In my more cynical moments, I question whether most businesses really want their employees innovating -- if they're not a research lab, that is. Most employees have too much ordinary work to do to take time to innovate and innovation from the ground up is hard to manage and control. But then I remember that finding a new way to do your work is innovation, too.

The latter piece has some excellent observations about the potential dangers of showing off who is connected to whom by social network diagrams. The same concerns apply to many visualizations of statistics in office life, of course.

For all of the benefits, charting informal networks can be disruptive. "Leaders feel pretty threatened by this," says Katzenbach principal Zia Khan, speaking of people who hold high perches on the organization chart but are more isolated on the informal map... It's O.K. for some people, such as those who spend a lot of time with customers or have expertise in niche areas, to show up on the periphery of the web. Maps can also highlight which employees might be too connected and therefore a potential bottleneck.

Confidentiality is also a touchy issue. A map that reveals who is well-connected and who is not can be destructive if it is shared too widely. "I know who I named, but when I look at the map, I might see [that person] didn't name me back," says Tracy Cox, director of enterprise integration at aerospace and defense contractor Raytheon Co. Now, says Cox, who does network analyses for the company's seven businesses, that hypothetical employee "knows that he is not valuable to his boss. And not only does he know it, but 50 of his closest friends know it, too."

This came up for me during my research days; and needless to say, it was an issue even if they didn't know who was A or B in the chart -- the map itself was frightening because everyone suspected they might be the X on the fringe.

Is Your Boss a Psychopath?

At the risk of my boss reading this, here's an oldie but a goodie: Is Your Boss a Psychopath?

Corporate psychopaths score high on Factor 1, the "selfish, callous, and remorseless use of others" category. It includes eight traits: glibness and superficial charm; grandiose sense of self-worth; pathological lying; conning and manipulativeness; lack of remorse or guilt; shallow affect (i.e., a coldness covered up by dramatic emotional displays that are actually playacting); callousness and lack of empathy; and the failure to accept responsibility for one's own actions. Sound like anyone you know? (Corporate psychopaths score only low to moderate on Factor 2, which pinpoints "chronically unstable, antisocial, and socially deviant lifestyle," the hallmarks of people who wind up in jail for rougher crimes than creative accounting.)

A good point is made in that some psychopaths are created, not born that way, and American individualistic corporate culture is a petri dish for this type of behavior. They get ahead in part because of their traits.

Of course, cynics might say that it can be an advantage to lack a conscience. That's probably why major investors installed Dunlap as the CEO of Sunbeam: He had no qualms about decimating the workforce to impress Wall Street. One reason outside executives get brought into troubled companies is that they lack the emotional stake in either the enterprise or its people. It's easier for them to act callously and remorselessly, which is exactly what their backers want.

The good news is that a productive narcissist makes a great balance for an executive psychopath. Or a productive obsessive. It's all just one big mental hospital in a large corporation. (See the related NY Times short on presidents with mental illness symptoms.)

Joel on Interviewing, Me on Performance.

Joel Spolsky's latest post is on interviewing interns for Fog Creek. I love how seriously he takes this, but with the same caveats he quotes as getting from other people. Bravo that last year's interns wrote their fastest growing business product almost by themselves. That's a good use of interns! (And in an industry full of big software companies that just acquire existing products and can't build them from scratch anymore, it's refreshing.)

Joel's main goal in hiring is to get "Smart people, who get things done." (See his Guerrilla Guide to Interviewing if you haven't read it.) This makes much sense to me. Operationalizing it during interviews will mean different things to different teams and disciplines, I think. His techniques for screening developers aren't exactly the ones I'd use on UI designers, but they're not too far off. (I like giving design problems, asking for design evaluation of existing products or mockups, examples of work process and deliverables, and willingness and ability to do the boring and hard stuff in order to push work through to completion. Checking ability and interest in learning is part of this last item.)

I was talking to a friend recently about how academic journal and conference reviews are "how professionals enact their discipline," by setting up the boundaries they want on what counts as quality work and what is worth letting in to extend or challenge their field. (It takes a brave reviewer, even in a cross-disciplinary field like HCI, to recognize something from a very different perspective as a valuable contribution to the discipline.) The same could be said for the hiring process, although far less abstractly -- and it's a little more tactical. Your target processes are always going to be moving-- hopefully improving-- but you have to hire for short term success as well as investing in the future.

Hiring is hard in part because most folks aren't good at articulating what needs to get done, and how to evaluate people for those abilities. So often the emphasis ends up on wishy-washy and dangerous "cultural fit" terms, because the objective measures are missing. Performance reviews, which are obviously (or maybe not!) related to the hiring problem, are prone to the same failures; a lack of understanding of what needs to be done in an organization can lead to subjective personality measures instead of objective measures of what got done and how and what we need to do next year. (I sometimes wonder: what if, instead of the traditional performance review methods HR depts foist on us, we were to do the interview process all over again -- with a focus on what got done in the last year, instead of previous company work? No, I don't mean we fire people who get thumbs down; but we evaluate concrete work as if we hadn't spent the year with them disagreeing or drinking after hours and learning about their cheating ways or charity contributions.)

It makes sense to me that in organizations with a poor understanding of what their business is, with an incomplete understanding of how to achieve and how to measure success, you'll also find questionable (and confused) hiring and equally poor performance review processes. But in companies like Joel's that know how to measure success, hiring, retaining, and evaluation of employees is downright rational.

TopCoder's Programming Contest

The WSJ has an article on the recent Topcoder programming contest. And Fast Company did an article on the 2004 winner.

I've blogged pointers to the MATLAB programming contest before. An interesting difference (if I read this right) is that a major focus on the TopCode contest seems to be challenging other people's solutions and invalidating them with scenarios they haven't thought of, while an important aspect of the MATLAB contest is the highly likely possibility of winning by improving on other people's solutions. The two contests are Darwinian, but in different ways.

Waterfall 2006

The best laugh I've had in, well, at least a week (the pornographic car design conversation at my corporate beer bash was pretty good): Waterfall 2006 - International Conference on Sequential Development.

Highlights of this conference agenda:

• User Interaction: It Was Hard to Build, It Should Be Hard to Use by Jeff Patton
• Pair Managing: Two Managers per Programmer by Jim Highsmith
• Very Large Projects: How to Go So Slow No One Knows You'll Never Deliver by Jutta Eckstein
• The Joy of Silence: Cube Farm Designs That Cut Out Conversation by Alistair Cockburn
• Making Outsourcing Work: One Team Member per Continent by Babu Bhatt

The conference will also feature a number of workshops.

Unlike typical conferences where workshops involve participants talking with each other, all Waterfall 2006 workshops will be conducted by document. Come to a workshop, open up your favorite word processor and state your opinion on something. Email it to other workshop participants. (We'll set up mailing list aliases for this--after all, we want to keep this process efficient!) Then just sit back and wait for someone to reply with their own document. Don't miss this opportunity to participate in vigorous written discussion with your peers.

Fred Brooks and Late Projects

Scott Berkun, rapidly becoming one of my favorite reads in the internet for his sagacity about software projects, points to an interview with the legendary Fred Brooks in Fortune magazine.Fred is of course famous for The Mythical Man Month, in which he argues Brooks's Law: "Adding people to a late software project makes it later."

The article itself has some stellar bits of quotage in it, including these:

Brooks' law depends heavily on the amount of information that has to be communicated. So the argument is that if you add people to a project that you already know is late, which means you're at least in the middle of the project, you have to repartition the work.... Sometimes that can be done by subdividing the existing units, but sometimes you have to move boundaries. That's a lot of work. The next thing is, you have to train the new people.

...Peter Fagg, a really wise System/360 engineering manager, gave very sound advice: "Take no small slips." That is, if you're going to take a slip, get everybody onboard, get organized, and take a six-month slip, even though you may at the moment feel as if you're only four months late.

...The other was when I was a new IBM employee and heard Vin Learson, a VP at the time, later CEO. He said, "The problem is not to make the right decision; it's to make the decision right." ...I came to understand that he was talking from an executive-level point of view. ... Either way can be made to work, but it's very important to pick one and then go whole hog. A counter-example is IBM's PL/I language. They adopted it, they backed it, and then there was a spell when they decided maybe it wasn't going to be the language. And then they decided maybe it was going to be. As a consequence, most customers didn't stick with it. The wishy-washiness killed it, I think. Whatever you're doing, you'd better go do it.

Visibly wishy-washy corporate "positions" can be fatal or at least very damaging to a business. But it's unfortunately pretty common to hear one's customers say, "We're not sure what you're telling us to do" or "What are you recommending here, you have us confused." Brooks has some comments on open source that are interesting too.

Scott notes that there are caveats or objections to the original Brooks Law linking project lateness and adding manpower (item summary here, he says more about each): It depends who the manpower is. Some teams can absorb more change than others. There are worse things than being later. (Producing better quality work might justify being later, if you've identified a role or expertise that's required.)It depends on why the project was late to begin with. Adding people can be combined with other management action (...such as cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc.).

Smart stuff.

Shadowland in Beta

A day late and an OS short... Adobe's first new (internal, from scratch) product in yonks is finally out in early beta: Lightroom. Only for Mac, alas. No, it's not a response to Aperture, as everyone thinks on first hearing about it; it's been in development forever, even when I was there.

This is a lengthy story of the dev. history, a bit too starry-eyed, People-magazine-style for me: Photoshop News » The Shadowland/Lightroom Development Story. Pretty much my take on this whole thing is "Don't try this at home," and better yet, "If we try this at the office, can't we all do better?" Is it that hard to innovate, incubate, and manage the release of a new product?

Maybe one of the lessons here is "Make sure you've got a good UI designer on staff during the whole process." But I'm definitely biased on that reading.

"Popping In On PopCap" Games.

I got this nice article off Amy Jo Kim's blog. Gamasutra on PopCap: "James Gwertzman On Casual Growth" describes the process of game development of "casual games" like Bejeweled, which is one of my favorite Palm Pilot games.

"Our path of development is extremely prototype-heavy," said Gwertzman. "We'll make half a dozen prototypes, and pick just one of those to be a hit casual game. And once we develop that one, it's a very iterative process. It's a sandbox model. We try different things out, and find out what's fun. Only when we find out that the core mechanic is fun do we worry about the art, content, and all the other little details."

"We really obsess over the core game mechanics. In a game like Bejeweled, hardcore developers look at that and might think it's kind of...it's very easy to kind of dismiss it, but we literally spent weeks on just the right way for the gems to fall when you make a match. In a game like that, it's little details like that. How does it feel? Getting those little details right is what we prioritize. So when we're designing a new game, we'll spend months and months prototyping core mechanics."

As Amy Jo noted, they're iterative; and interesting to me is that they still work hard after identifying the good gameplay principles. The design details really matter! As Gwertzman says, "We compete in a try-before-you-buy market, and we believe competing successfully there is a fundamentally different kind of design." And fun is an incredibly demanding business to be in-- no one has to use your application for their paycheck, after all.

Their game engine is available for free, I was interested to see.

The Office 12 Blog

If you're wanting to catch up on the hullabaloo about the Office 12 redesign, Jensen Harris has just reorganized his links and provided good access to summary articles on his blog. See An Office User Interface Blog.

Also, I've been finding the Excel redesign posts interesting over here; I especially like the highlight-and-get-instant-math, and the little color bars indicating relative value differences at a glance in the spreadsheet. Lots of good stuff going on.

DTV's TiVo vs. Replacement DVR

Weaknees has a side by side proper comparison of the sadly no-longer-offered DirecTV-branded TiVo vs. the newer DVR they are now promoting, the R15.

The TiVo still comes out ahead, on many points. But read and decide for yourself.

Fashion Meets Processing

A beautiful collaboration between fashion photographer Clayton Cubitt and and Processing generative artist Tom Carden: Metropop's denim issue.

Getting it Right (or Wrong, at Blink)

An interesting post-failure analysis of why social bookmarking site Blink failed while del.ico.us has succeeded. Ari blames product design, although in the comments some people blame the development decisions, the growth of the company, the loss of focus, the ad and registration burdens... in short, all the dot com era fools are to blame.

The worst decisions seem to have been using folders, leading to an insupportable number of performance and downstream design problems impacting user experience; and then the decision to make folders of links private by default instead of public. I think tagging is prone to issues similar to folder creation, but the immediate visibility of content on del.ico.us, instead of just the containers, makes the design work better. There's a real immediate payoff without a lot of digging when you look around on del.ico.us.

My links are public, if you want to browse them. See sidebar.

Microsoft hires user interface guru

This just in from steve: Microsoft hires user interface guru Bill Buxton, formerly of Alias Wavefront and long HCI history. He's being hired by MS Research, of course, and will work on ubiquitous computing ("ubicomp"), as so many people do these days.

This is an entertaining paragraph close: Buxton in the past has been critical of software companies' failure to integrate appropriate design processes into products. However, he said that Microsoft is hiring more designers, which is encouraging. "My sense is that Microsoft is in transition from an engineering-led company to as much a design-led company," he said. "There are more designers at Microsoft on any single team as there were, not too long ago, in the entire company. It's a wonderful change."

I followed up his criticism, and found this right-on abstract for a talk he gave at Graphics Interface 2005 on exactly this topic:

...We are now seeing articles appearing that are warning about the danger of a schism in user-centred design (UCD) between the ethnography and usability camps. (See for example the spring issue of Interactions.) The apparent voice of reason points out that both have distinct roles: ethnography can feed design, while usability can evaluate it. All very nice as far as it goes. But what is missing is any detailed consideration of who actually does the design. There is something missing.

In this talk I want to speak to both the role and nature of design in the overall process. Along the way, I will argue a few points, including the claim that usability and ethnography are distinct from design. Relevant to design? Yes. Design? Decidedly not. I will also speak to the whole nature of iterative design, and argue why iterative and incremental software engineering practices such as extreme programming and agile software techniques are not the same as design. Again, relevant? Yes. Design? Absolutely not.

As I will show, the software industry has an abysmal record at creating new products. I will argue that the absence of anything vaguely resembling a design process is a key reason. My talk is directed at altering this situation.

I can't wait to see what he thinks about working at Microsoft after a couple of years! Now if only more companies understood the distinction between usability and design and how to operationally overcome the issue in a way that led to product success.

FAQ on Usability Testing in Progress

I am writing an FAQ on usability testing for my new team. I want to do a real one, not a marketing-style intro level one that establishes that testing your software is like eating Mom's apple pie. (Wait, that's a weird metaphor.) What I am after is the common objections, the issues people really have about topics like potentially poor recruiting, validity of testing with small numbers, the value of qualitative data at all, the variability and difficulty of analysis of the results, the biases that may go into defining tasks for the test, etc.

If anyone reading has any concerns, however un-PC(!), about doing usability testing on software (or has heard anyone else express doubts about the value), I will try to put them in. Whether I have a great answer or not (some concerns are entirely valid). If I get anything from you, I'll post the results here as a web essay too.

Go on, be tough.

Good Experience Games online

A nice list of online, well-designed Good Experience Games pointed to by steve on tingilinde. I am deliberately not going there till I am on my holiday break, and even then I have a long list of stuff to do.... eeee. Tempting examples include a great-looking online Set puzzle (surely I can make one stab at this without losing the day), Samorost 2 (gorgeous!), a Scott Kim game or two, a bird feeding game called Pyoro (I think I will have to go see this, despite their warning it's "hypnotic"...)

Like I said, "Eeeeeee, I have stuff to do right now! Get them away!!"

Tabs Gone to Hell

Everyone knows by now that multiple rows of tabs aren't such a good idea -- or do they? Here's an egregious example from my new Thinkpad. This has more than a few tab-related problems: there's some kind of duplication between resources and allocation (2 tabs for each overlapping concept); many of them seem to be empty anyway; there are so many that's it's actually hard to go through them all, even with the counting option, because there's so much shifting around as you click on them (making it hard to tell what you've seen already).

This UI is a small part of a worse UI issue: the Thinkpadders duplicated a bunch of OS-level stuff, often by overriding it completely, in their own custom UI. This is particularly awful in the area of networking. There's no way to scan for Wireless networks from the Microsoft dialog-- you have to figure out it's been overriden and is controlled from somewhere "new" and how to work that instead.

Why do companies so often make the mistake of trying to "brand" the hardware experience with their own custom (often poor) software experience where it's not needed? (Ok, it's still a sore spot from my TiVo era.)

justcurio.us // strangers helping strangers

This is cool -- you have to answer a question from a stranger, which could be about anything at all, before posting your own. I posted my own question, the first thing that occurred to me after a hard week of conference partying, and now I can track the answers here.

TiVo Conference call follow up

Notes from the latest TiVo quarterly conference call.

Some discussion of the Comcast deal, of the impact of advertising spots, HD issues...

MATLAB Programming Contest

The MATLAB programming contest just gets bigger and better. Here are Matt Simoneau's charts and graphs of the evolution of the submissions and scores over time. What could be cooler than this contest??

Reasons ease of use doesn't happen

Martha Stewart has her 10 Rules for running a business, and Scott Berkun has 14 reasons Why Ease of Use Doesn't Happen on Engineering Projects. I wanted to cheer out loud as I reread this. Maybe it's just because I've lived through so many of them and some so recently.

Take 2, "ease of use is not an actionable goal." If there's no criteria for success, it's easy to stop paying attention to this, even if you thought it was an objective rather than lip service to "doing the right thing." "When stressed, most humans prefer to focus on things that are tangible and well defined, rather than vague and poorly defined. So even if ease of use is an explicit goal of a project, if it is not broken down into discrete and measurable pieces, or tasks and work items for someone to do, it will remain an abstract idea that no one feels pressure to fulfill."

Item 3, "decision makers don't see the tradeoffs," is probably one of the most important but most difficult to manage. Because it requires management to be bought in and innovative in software processes. "To get an easy to use product, a different kind of thinking and planning is required.... Team leaders have to recognize how ease of use effects other engineering decisions, and must modify their decision making process to account for it." This is echoed in #7, "Technical focus dominates the view of the project," wherein team leaders get obsessed by brilliant architecture and leave the UI to last or second place. Hey, your customers don't care how brilliantly it's architected, even if it saves you time later. "Wise engineers understand when they don't have the right sensibilities for certain kinds of decisions, and know to yield them to someone more appropriate. An arrogant engineer will tend to assume that what they do not understand must be trivial, or worse, doesn’t exist at all, and will proceed to apply their hammer to things that are definitely not nails."

"Confusion over who the customer is" vs. client vs. user is a good reminder issue. Often the person buying it isn't the person using it, and more often, the person building it isn't really representative of all users, even if they think they are or have some domain expertise.

#8, "Diffusion of design authority (Too many cooks)," is reminiscent of the post I made recently about free software usability issues; "When authority over the design of a project is distributed across too many individuals, the likelihood of a high quality final design decreases. The worst approach is design by committee, where lots of people who don’t have shared goals or shared high level ideas, get in a room and torture each other with compromises until mediocre results that no one likes, but everyone can just barely manage to live with, are achieved." Good design requires good design leadership, unified vision ownership, not widgets built separately thrown together into a patchwork at the end of the day. Good design isn't just the sum of all the features you are adding to the latest release. "In either case, being an effective designer, or design authority, means the ability to: generate good ideas (creative), convince others of an idea (conviction and communication), and integrate the best ideas and feedback that others around them have (mature egos). Good design leaders are therefore quite rare." Of course, you have to know you need them and how to identify them, in order to hire them.

This is closely related to point #12, "The wrong people are involved," the case in which the wrong people own the design decisions. Even on teams with UI designers, I've watched this play out in team dynamic. And it's worse when there's no recognized UI design authority or the wrong person has it for the problem at hand. "The craft of designing interfaces is a unique skill. It requires an individual to have at least four personal attributes: compassion for other people, abstract problem solving skills, the ability to communicate or detail web/software design ideas, and experience crafting designs and watching people use them. Giving design authority to programmers or project managers without these traits is unlikely to work out well."

"Feature design vs. task design," #9, is the reminder that just because you have the bullet on the box doesn't mean anyone can achieve a work goal with it. Did your customer do something real with it? (This could be one of your actionable criteria for #2 above.)

#11, "General incompetence," is another good reminder -- teams might suck, and leaders might suck, despite all best intentions and well-produced documents. Check your team chemistry and ability to Get Things Done Well as a Group.

Well, they're all excellent points, and I think it's worthwhile using them as a diagnosis form for your organization if you think poor usability is a problem you suffer from. The Root Causes may be deeper and more diverse than you thought, but Scott has suggestions for almost all of the issues he lists. If you don't know if you suffer from poor usability, you're even one step behind the need to diagnose why you've got it -- and trust me, you're probably very sick.

Review of the DirecTV TiVo "replacement"

As you probably know, DTV ended their deal with TiVo and their offer of a TiVo unit for their subscribers, and have now developed their own ripoff. I say "ripoff" because it sure looks like a close copy in the review and screenshots this guy has up here: A Review of the R15.

Admittedly, there are a couple of things in here that I consider improvements, things we got wrong that haven't yet (AFAIK) been fixed in the TiVo UI. And they do offer the often-requested disk usage measure :-) But they have outright copied much of the UI including a lot of the TiVo UI wordings, while losing the friendly look&feel and sound effects. I imagine there are grounds for lawsuit, especially if it's true that they copied the fast-forward autorewind correction, for which I am quite sure TiVo has a patent.

Why Free Software usability tends to suck

Matt Thomas, a Mozilla contributor, has some interesting observations about design on free software projects. If you're a fan of evolutionary design by accretion and multitudes, you might want to check out his concerns in Why Free Software usability tends to suck. (It was picked up by a number of people including Joel back in the day.)

One of his points will be controversial to some people, I think: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

I don't think this is necessarily true in a non-opensource environment; and, to be more concrete, in a software environment where people aren't argumentative prima donnas, communicate regularly, and reach consensus before implementation of the crucial features. But when there's frequent handoff of work, a tendency towards grandstanding or power plays in the design phase, or poor communication, it will be true.

Updated to add: He has a sequel article based on comments he got on the original, at Why Free Software usability tends to suck even more. His points continue to be good, including the inspiring last comment, which I think is also is true in any organization: As with previous critiques of Free Software, each of these weaknesses will become less of an issue proportionally to the number of contributors who read about them, and learn to recognize and combat them.

In software companies, this is known as "risk management." Doing that well in a design process requires recognizing the failure modes, worrying about them, and making yourself immune to them.

Scott Berkun on Train Wrecks

A week or so ago, I went with a couple colleagues to hear Scott Berkun talk on software project train wrecks. It was entertaining, albeit rather painful, for people who have been victims or occasionally contributors to such disasters.

Like any UI guy worth his paycheck, Scott notes that the crux of the software design matter is often team management and project management. I find it not the least surprising that he and Joel Spolsky, also noted for his UI and design observations, are both so sensible on the topic of project management. Scott's new book, The Art of Project Management, is getting raves on Amazon, and I'm cheering as I read it. (I'm not sure you'll recognize the insights for what they're worth if you haven't lived through the kinds of process issues he describes, but I find him right on.)

Scott's slides are here. His diagnostics for train wreck projects are these:

• We know we won’t meet goals
• No one is happy / Everyone is frustrated
• Things keep changing, but there is little progress
• We don’t know if we’ll be able to solve them
• We don’t agree on the existence of problems
• We don’t know whose job it is to solve them

Sound familiar? For some people, this might describe entire companies! He has more specific criteria for design disasters, which may be even more familiar, since design is so hard to do well (depending as it does on more factors than simple project management):

• Disconnect between the “design” and what’s being built
• No one knows what the “design” is
• No one knows what the goals are
• There are competing designs being built simultaneously, and unintentionally, by different people
• The design has no possibility of satisfying goals: Customer / Technology / Business;
• Note: People with different goals will define disasters differently.

And finally, he hit my favorite subject, good teamwork. Good teams:

• Avoid many problems and rat holes
• Are good at recognizing/communicating issues
• Are good at using each other to help solve its problems
• Teach each other how to find and resolve problems
• Make mistakes, but are encouraged to learn (not hide)
• NOTE: One team’s train wreck is another team’s good day.

I was surprised not to find my favorite study of effective teamwork (Teamwork: What Must Go Right, What Can Go Wrong) in his bibliography.

Update: Here's another good review of Scott's book.

Networked Governance: Network & Teams

Harvard University has a Program on Networked Governance, on whose site I found some nice links on networks and teams. I thoroughly enjoyed the literature review in their first article link, Building Effective Intra-Organizational Networks: The Role of Teams (pdf). The starting observation is that there hasn't been a lot of research cross-over between people studying social network analysis (SNA) and effective teamwork in organizations.

As a tourist in both fields, I found the literature review and the points of contrast and comparison very interesting. It's a good intro to both fields.

• Bavelas and his colleagues at MIT conducted experimental analyses of how communication patterns among teammates influenced team effectiveness ... When the information was simple, centralized communication was optimal. When the information was complex, centralized communication was dysfunctional.[Me: For decentralized communication to work, the network must be highly functional.]
• The paradigmatic focus of team research is on the task performance of a small group with a clear and well-defined boundary (Alderfer, 1977) “Clear and well-defined” means that team members and outsiders know who is on and who is off the team (Hackman, 1990). This is a critical element of the very definition of a team. [Me: This is also the in-group/out-group issue I found in the community studies literature in my dissertation research. Individuals who are shared across multiple teams may have a harder time identifying with any one team, and this may impact productivity or team relationships.]
• For teams with little autonomy or with overloaded team members, communication initiated by the external environment negatively affected team performance. [I guess this includes management wrenches thrown in the game very late...]
• Do team members know each other before the team exists? Jehn & Shah (1997) found differences in intra-team communication when they compared teams composed of friends to teams composed of acquaintances. [Not surprising. Check who has lunch with each other!]
• We know that a team’s success or failure can influence subsequent feelings of cohesiveness among teammates (Turner, Hogg, & Smith, 1984). One possibility is that misery (lack of success) breeds company (connectedness). Another possibility is that successful collaborations result in increased communication. Lack of success may lead to a vicious cycle of failure, leading to disconnectedness, leading to more failure, and so on. [As a manager I would think hard about retaining the same team members in a context where their first product was seen as having been a failure... or where they thought it was.]
• While knowledge networks describe who knows what, each individual in the organization also has his/her own perception of who knows what, or a “cognitive knowledge network” (Contractor, Zink, & Chan, 1998). Cognitive knowledge networks are a combination of knowing who knows who, and who knows what – i.e. who knows who knows what. Cognitive knowledge networks vary in their accuracy and completeness (Contractor et al.), where higher levels of accuracy can be expected to result in greater access to the knowledge in the network. [An environment where people don't know what other people know, or who knows what is a risky environment for the success of a teams and individuals.]
• Another mechanism social systems have that regulates individual tendencies toward noncooperative behavior is the possibility of continued relationships, because the fruits of future collaboration are at stake (Axelrod, 1981). ... We would expect teams made up of relationships with a greater expected duration will suffer from less free riding. When one free-riding team member can “crash” the entire team, and free riding is thus a dangerous risk, a desirable network will feature high levels of embeddedness, strong ties within the team, and expectations for future interaction. [Free riding, of course, is slacking off, in a work context. So, if the team hasn't felt it has been a failure, the existence of the group over time encourages individual performance and communication.]
• When a manager assigns people to teams, he/she is molding the social capital of the organization. .. There are two overarching points here: (1) when assigning people to teams, managers should consider the impact of a team on the organization’s long term social capital; and (2) managers should consider viewing social capital the same way they view other types of capital: it may need to be amortized over time. Under certain conditions, it may even be worth sacrificing some short-run team performance for the sake of fostering long-run organizational performance.

I really enjoyed this article, but then I'm a great tourist.

isometricblocks, by ben fry

isometricblocks is a genome comparison visualization applet by Ben Fry, who is currently working local to me at the Broad Institute following his MIT PhD. He does wonderful, artistic visualizations. His Processingtoolkit for infovis apps, which I've blogged about before, just won an award at Ars Electronica.

Ben's dissertation is available online, which made me very excited just now when I found it: Computational Information Design.

Data Visualization: Best in Show

DMReview had a contest for best infovis application, and Jock Mackinlay's submission won. The scenario and data were not prescribed. The winning solution was a display of video game advertising strategies.

Jock is an alumnus of Xerox PARC, along with many of the world's best infovis HCI folks. He's now the UI Director at Tableau Software, a company I keep coming across. Jeff Heer, also formerly at PARC and main author of prefuse (which I've played with for network diagrams), was also at Tableau for a while. But I hit Tableau on the web-- knowing nothing of their distinguished staff-- when I was looking 6 months ago for companies doing interesting infovis and data mining applications. I thought their UI and featureset looked very nice.

Too bad they aren't posting more jobs for UI designers! (Although, they are located right down the road from my old Adobe digs in Seattle, and I know I can't take that climate.)

The DMreview article is especially good because it also shows some losers and why they lost, despite their slick design (like, immersive 3d virtual worlds for 2d graphics). I just wish it were longer.

"Psst--wanna see Photoshop 15?"

John Nack was the product manager on Photoshop who worried the most about the encrusted menus and overload of expert features in Photoshop, as it went into it's millionth release cycle. It's a software industry problem, as he points out in more angst in this blog article.

From a design and usability perspective, it's a nightmare problem with few solutions, and the problem just gets worse. You can't remove features, you can't do major surgery (see the angry comments referenced in John's post), you can't NOT add features because that's what keeps you selling! And you want to add things that help your customers, that they've asked for.

You reduce the product usability with every new item you add after a certain point: it becomes increasingly hard for your customer to sort out what the task flow for any particular problem is (especially tasks involving multiple commands/palettes/menus), and it's harder for them to discover the new and interesting or even refind the old and true in all that built up cruft. John says: "And the sheer volume of options can be overwhelming. At one point I counted 494 top-level menu items in Photoshop CS. In CS2 we've added roughly 60 more, and that's not counting the new Adobe Bridge application. So, back to the hypothetical Photoshop 15: at our present course and speed, we'd add at least 350 more menu commands. We'll need to raise the minimum screen spec just to hold the menus!"

Splitting out a new app, like breaking it apart into different consumer market products (like Photoshop Elements vs. Photoshop for Gurus) are one way to go. I think that's not bad, actually -- your customers then have 2 things to buy, and the usability of each is a little better. Assuming there's a good place to cut them apart. Allowing customized menus is another (John's fix for CS2 release--he's not sure anyone cared); patching your workflow problem by adding "wizardy" walkthroughs aimed at common tasks is yet another way to go. You still need access points for the wizardy walkthroughs, which is yet more functionality on menus/palettes/toolbars...

This is a truly hard UI problem, which every mature software product faces eventually. I'm just pointing at the pain, I don't have deep solutions; it's at heart a business problem that in turn points to harder economics problems about why people buy things that aren't good for them.

Funfurde's latest: Phone Modes, Bad Tables, DNA art

Funfurde's wacky furniture/design pointers continue to amuse me.

Right now they've got a cool-looking plastic phone with a bunch of big plastic "pages" you turn to switch modes on the phone -- the "phonebook." And a peeing table, which you have to see to understand ("Bad Table"):

The Straight Line Design folks who do the bad table mainly do wonderful children's furniture. It's really worth a visit, especially to see the melting cabinets!

Also, funfurde points at DNA art for your wall -- your own DNA, sequenced and visualized. I wonder if you can ask for indicators showing off your tendency towards alcoholism and your wonky knee on it?

pixelfest

Another one that made me think, sometimes surprising things. The principle of the experiment is "can a bunch of random people, by changing one pixel at a time on a canvas, create something?" Pixels can be overwritten. Is it art, garbage, or just an online experience?

You decide by watching the animation, from the blank canvas to the current piece: http://haub.net/pixelfest/. Watch that first, then go read and try it: Add your pixel here. (Don't go there before watching the animation, though.) Here's some text and discussion.

Here's some of my thought process as I watched it:

• Blank canvases are more conducive to text than pixel art. Watch the words appear and get hijacked. Someone should create a "change one letter at a time" game now, if it hasn't been done already. Would Scrabble just evolve? I think it would.
• Is that a tree? Is this one person under many anonymous entries, or multiple people?
• Can good design really happen without a guiding principle or vision? Don't we need organized vision here, if we want a "good" (coherent? attractive? interesting?) end result? There's a reason websites need information architects and wikis are so disorganized and become hard to travel as they evolve....
• Can people who aren't communicating make something anyone really likes at the end of the day? They need a spec and some discussion. If none of them are good at thinking in pixels and planning out the layout and process, it will still be bad "art" although it might look more organized.
• A pixel is too small a unit of design and communication. What if they had vector art, objects on the page.
• What are those black things that keep appearing? Is there an attempt at meaning here, or just chaos (modern art)?
• Why did the text stop appearing? Is it easier to imagine it on a blank canvas, and the filled colors make people lean towards visual art instead?
• Wow, is this thing ugly at the end of the day. But I'm glad the sun came back.

Physical Models of Virtual Spaces

Tom Vollaro has an interesting item on his website: A visualization of the virtual contents of a MUD, which is a virtual chatspace with a user-expandable geography. He did a site map of the rooms of BayMOO, and then built a model showing what it looks like. I like the concept of turning compass directions in a text engine into a plastic model you can walk around. His site is here.

Pavel's Second Life

Pavel recommends checking out Second Life.

They have a few features that make them sound destined for financial and usage success: a simple programming model, rights to intellectual property remain with the user creators, an internal economy that does real business for users, and a rate structure based on pay for creation rights.

The illuminated continent

On the Official Google Blog: The illuminated continent. Data layers on Google Earth showing links to National Geographic stories and images, even a webcam. It's all hyperlinks in the end, but the experience seems different!

Silicon Valley Network Analysis

"Saxenian (1994) presented a systematic argument that network structure in Silicon Valley was quite different from that in the Route 128 corridor of the Boston metropolitan area, for a variety of historical, economic, and cultural reasons, and that this difference translated into what she called, in her book’s title, a distinct “regional advantage” for the Valley." One of the reasons for the difference is the dense social network linkages in Silicon Valley, the high mobility of employees, and the sharing of knowledge at sidewalk cafes -- impossible in a cold, secretive Defense-funded climate like Boston's.

On the SiVNAP--Papers's site, the last article summarizes the network effect on the founding of the semiconductor industry, the growth of Venture capital firms, and the relationships between Stanford and local industry.

I miss the Bay Area! Although it was somewhat disconcerting how small the world felt, every time you went for an interview ("what do you think of so-and-so--?").

Ghostweather: The HP Scanner Dialog

I found a UI so bad last week that I've been jumping up and down trying to find time to post about it. Finally, here it is:

The HP Scanner "Copy" Dialog, a new low.

TiVo's investor call

I've been afraid to read the news since the end of the DirecTV deal, but the news in yesterday's call with TiVo is actually not bad at all. For the first quarter, they made a profit! And the Comcast deal is coming along.

Yesterday's investor call | PVRblog.

danah boyd: the biases of links

danah boyd has a bunch of observations about blogrolls and linking in an essay here: Many-to-Many: the biases of links.

The dark-- or at least gray-- side of blogging includes the fact that most of the Technorati Top 100 blogs are group blogs or professional blogs, usually aimed at marketing in some way. I suppose it makes good business sense to hop on the buzz-mot-du-jour bandwagon, just like Hagel and Armstrong did with Net Gain: Expanding Markets through Virtual Community. Who people link to in their sidebar, their "blogrolls" (which are often labeled "who we read"), is overwhelmingly gendered, in her sample. And the top dogs all get linked to, but don't link anyone.

It's not a solid quantitative research study, but it's interesting to read.