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.

CHI 09 Panel: Moving UX Into Strategic Importance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

Task Failure in a Digital Frame Design

I shouldn't look a gift digital frame in the interface, but it contributed to a badly spent Labor Day, so I will: the Philips 7FF2M4. In February I posted a link to David Pogue's review of other digital frame designs that mostly got it all wrong; consider this a detailed sequel from yours truly.

This frame is not wifi or bluetooth enabled - so no home networking to connect to etc. Good, because I don't leave my PC with my photos on all the time. And I wanted to take this to the office. My gift-giver kindly included a 2GB card with it, too. My naive, starting assumptions for how this works, without having looked into digital frames much previously:

1. I will be able to put photos on the card, or use one from a camera as is
2. I will put it in the slot on the frame
3. It will play a slideshow of all the pictures on the card.

The end. I expected to stick in the card and have it cycle through them, maybe with a nice dissolve between them. That's the task that I'd assume as designer, and design to support. But the difficulty for consumer electronics design seems to be keeping the product focused on the core task, and not getting lost in the options possible to throw in there. (I think most of these companies don't have UI designers on staff, honestly. Apple taught us about the importance of industrial design, but the UI part didn't come across so clearly to the world.)

Physically it's a nice frame, with a solid plugin foot that's heavy enough to hurt someone. I think it's a 7x5" display, although that's a bit vague on the box. It claims to do auto-rotation, to landscape or horizontal, which is nice - I remember that my smarter cameras know to rotate pics, but not all do, so my cards from my cameras might not work well "as is." Okay, I'm not averse to dragging pics onto the card from a computer.

Which I do, and then stick it in the frame. It does not play anything automatically except its own menu - and when I find the slideshow button (I do like the physical controls on the back) I try to play it. But it plays some generic Philips ads, not my pictures. What?

It turns out that you have to navigate through a menu to reach your card, and then into the directory on the card itself, and then it gets really complicated - you get the option of making "albums" there and other things. It's hard to get it to play a damned slide show! (Or find your pics, if you aren't familiar with your directory structure on your camera card.)

Eventually I managed to get an album and get a slideshow to play (you can see my abortive attempts called "1" and "Empty" and "Excerpted" above; my path involved debugging my card's directory issues with their provided software for creating "albums" on my card or frame, which I don't get much benefit from, I just want to play the contents of the directory!). The slideshow has some oddities; it has bad transitions, and a weird too-many-pictures-at-once display mode. It turns out this is a "collage" option on by default, which squeezes in 6 pictures into the 5x7" frame size, way too many for them to look good. You'll also notice it regularly uses two of the same one, an odd programming choice (is it meant to look good that way?):

I find the settings to choose another collage and it sure has a lot of them. Sheesh. The only one I really would consider using in a small frame size is 2-up, a split screen of 2 images, and that setting is NOT offered.

But then, there are lots and lots of settings...

But the kicker is this: None of my choices stick. When I power down and restart it next morning, it's back to playing the Philips internal frame memory, and using a collage of 5 pictures. What the heck? With all those menus to go through, it requires some real work to get it into a state without too much setup time. I managed to erase the Philips frame pictures so when I hit slideshow it finds mine, but have not figured out how to get it to remember the collage style I prefer.

I realize the market is crowded with digital frames, but I suspect we are not really ready for complex feature wars yet. Ease of use out of the box seems like the most important aspect here. The task of playing photos (with simple defaults - dissolve and no collage mode, remember last directory played from) is not rocket science. Okay, there may be some clever design required for cases with multiple directories of photos embedded in a frame, but some code that FINDS THE PHOTOS instead of requiring the user to navigate through strange DCAM directories would seem doable. A very simple startup option in the case of multiple directories would seem doable too - which one do you want to play now? Let's assume for jollies that it's probably the card contents that should be the default, not the internal frame's limited memory.

There are multiple photo directories. What do you want to see?
• Play all my CARD photos (280 photos, Jan 2008)
• Play CARD DIR1 (245 photos, 15 Jan 2008)
• Play CARD DIR2 (35 photos, 16 Jan 2008)
• Play FRAME photos (4 photos, 7 Jun 2007)

It wouldn't surface multiple card directories if they were just the automatic camera directories, only if they were made by a user in a non-camera manner. So the simplest case is just look for images and play them - card first. They can keep their buttons for getting to more interesting settings if they want, but any of that is advanced gravy. Plus, remember the damned last power-on choice! How often do I want to be fiddling with this thing? (Not ever.)

One Philips frame review at CNET says the next model is an improvement for ease of use.

Our biggest complaint about the 7FF was that the unit wasn't a little more intuitive to navigate right out of the box. Although it didn't take us that long to figure things out, the unit's internal GUI (graphical user interface) could have been a little more user-friendly. Philips seems to have gone out of its way to fix that problem in this next-generation model with a totally redesigned interface.

I sure hope so. I admit I doubt they get as close as my suggestion above... but I'd be pleasantly surprised if so.

Staffing for User Experience: What Can Go Wrong

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

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

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

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

Wordle on Ghostweather

Playing with Jonathan Feinberg's artistic tag cloud generator Wordle, I plugged myself in (of course) and got this one (this is the "ghostly" color scheme):

Randomness is a powerful toy in design - it helps you discover things you wouldn't have seen with a purely organized eye. It's inspirational. It's fun.

Some Fun Entries in the Create the Future Design Contest

Now that the Create the Future Design Contest is open and collecting entries, it's time to point out some of the reasons I love this contest. Before I do, I should say that although I help with the site design and administration, I have nothing whatever to do with judging, which is done by a panel of engineering and research experts recruited by NASA Tech Briefs. And my opinions won't mean anything to them!

One thing that makes this contest fun are the wacky ideas - the napkin sketches, the weird diagrams, the mad scientist schemes. Some of them just sound funny at first, but are actually quite earnest. Take, for example, the "Thumbtack Remover." Or the "Personal Transport Pod" (I especially like the solar panels). (Be sure to check out the scheme for the "Personal Safety Belt" by the same inventor, which slightly resembles a super hero's costume.) And then there's the eSpider, a recyclables pre-sorter with a hand that looks like a spider.

Some of the entries have terrific images, rendered with high-end tools like Rhino and SolidWorks. Here's a student entry using Rhino to illustrate a convertible boat. Another student entry uses Rhino to diagram a medical self-diagnosis unit, called Sintomatico. And there's a student design for a vertical bike rack, using SolidWorks, which makes any design look very professional. Here's a part of a SolidWorks entry for an electromagnetic rail motor:

Some have surprising descriptions - this one for a breast exam device features a quote from a famous columnist that I didn't expect, but supports the case! This one is for handling hair-oil storage, which makes me flash back on Clooney's hair treatments in "O Brother." In another odd hair-related device, you've got to check out the Bowman, which I find hilarious. He submitted pdfs, so be sure to open them up! Some also have funny names, like the A.T.E.A.M, for the "ANTI-TERRORIST ECM-AUDIO MECHANISM."

A few words about the site and contest: While we are showing page view counts, there is no prize for page views this year. It was too much trouble to police last year. I will probably review and reset them any case, to keep them more or less believable. Please check out the entries with fewer page views right now, they are very deserving of eyeballs. There will be some form of public rating mechanism in October for another popular vote prize - development resources willing. Finally, if you like the home page, the flash banner of the Wright Brothers' plane with jet engines was done by an intern at SolidWorks, game design student from WPI Alex Schwartz. Awesome addition to the site.

If you have a blog and you post about the contest, I'll put your post link up on the site's press page.

Designing the Stop Sign (the Agency Experience)

Having just given a workshop on setting yourself up as a consultant with some warnings about client types, this video is especially apropos. What if a corporation asked you to design a stop sign?

In the Freelanceswitch.com list of client types, I think they missed the Appreciative Hands-On Committee of Passive Aggressive Cheerleaders client. Who test your design on their 6 year olds!

Thanks for the timely pointer to Steve at Tingilinde...

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.

CHI 2008 Conf: Usability Considered Harmful

The premier human-computer interaction conference, aka CHI 2008 (pronounced "kai" not "chee") was in Florence, Italy this year. After missing last year's in Silicon Valley, I went despite the ruinous exchange rate. (Other local colleagues went to Italy for the conference, but blew it off to go skiing instead!) One of the more interesting and crowd-drawing sessions was the paper by Saul Greenberg and Bill Buxton, "Usability Evaluation Considered Harmful... Some of the Time." Following it was commentary by Bonnie John, Tom Rodden, Dan Olsen and the ever-sharp CHI attending audience. Here's Saul and Bill listening to the commentary:

An initial note: CHI as a conference has a huge percentage of academic and research attendees. How to make it "relevant" to the "practitioner" audience is a regular concern of the conference committee. Why research isn't necessarily relevant is one of the reasons for their paper, I think. (And for things I've spoken and written about in the past, too.)

The main argument was...

...We too often perceive … an unquestioning adoption of the doctrine of usability evaluation by interface researchers and practitioners. Usability evaluation is not a universal panacea. It does not guarantee user-centered design. It will not always validate a research interface. It does not always lead to a scientific outcome.

Their supporting arguments were these:

• CHI reviewers require evaluation, and usually quantitative (lab study) testing results, as a part of a submitted paper (reflected in the submissions guidelines)
• Quantitative usability studies are often the wrong type of study for certain kinds of design: such as inventions in prototype stage; other types of user study may be more correct for these.
• In an argument familiar from Buxton's book Sketching User Experiences, a focus on usability evaluation too early in a development cycle produces poorer final results than will experimenting with more design concepts (or "sketches")
• Early-stage technical innovations that are disruptive or paradigm changing may produce poor or ambiguous user testing results, which may prematurely kill them off as research topics -- when long-term these ideas might find audiences and produce large-scale social or practice change after adoption.

Greenberg and Buxton argue that CHI has too great a focus on scientific results (and poor ones at that), rather than on supporting good design and invention.

“Science has one methodology, art and design have another. Are we surprised that art and design are remarkable for their creativity and innovation? While we pride our rigorous stance, we also bemoan the lack of design and innovation. Could there be a correlation between methodology and results?”

Comments ran the gamut from polite disagreement about the counts of types of papers accepted at the conference, to observations that publication-treadmills don't allow time for disruptive risky innovation that can be studied longitudinally, especially for students in grad school. Saul asked the CHI audience to review papers differently -- after all, the audience there constitutes what gets in, and what's considered good work. What constitutes good work worthy of acceptance is in the hands of the reviewers in the room! Finally, it was noted that different, "riskier" work of a design or featuring ethnographic evaluation instead of user testing is regularly accepted at other conferences in the same ACM family: DIS, DUX, CSCW, even Ubicomp and UIST.

Most difficult, for me, is the idea that the CHI reviewing audience has the credibility and experience to review riskier design work that doesn't come along with (the right kind of) user study. With mostly academics and researchers on the reviewer list, I question whether this audience has the depth of practical design experience and credentials required to recognize and talk about "good design" with credibility. What do I require for credibility: having done a lot of real-world design, and having evaluated a lot of products from a customer-centric perspective. When I say "real world" I don't mean academic design - where it's notoriously easy to go wild and crazy. In the context of a business or large organization, the kinds of compromises that designers face are what separate the real good from the mediocre.

I would like to repeat that human computer interaction is not fully represented at CHI. The conference is just one forum. While it's true that CHI publication counts more than most others to researchers in this field, it doesn't necessarily represent the full range of activities and professional expertise in the broader field of interaction design.

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.

Punitive Luxury at the Marriott Marquis

I just got back from an overnight work trip to NYC, where I was booked into the Marriott Marquis at Times Square. I disliked this experience, in oh so many ways.

How about this example of a nasty use of technology? Here's a $7 bottle of Fiji water that's on a weight-sensitive stand, the kind you see in heist movies where Tom Cruise is rapelling in to help himself to something way more fun than water.

The note on this bottle says, "Your account will be charged when this bottle is off the stand for more than 30 seconds." There was dust on the stand, because even the maids are afraid to disturb this gem. [Updated to add: a friend tells me her father stayed in another Marriott in a large American city and ran into the same thing. As he was going into his room, a cleaning woman in the hall warned him, "Don't move the water, don't move the water!!"]

Note that this was a room I was paying $400 for a night. I don't know what I got for it, to be honest. The sink wouldn't drain. And they also wanted me to pay $4.99 for their "tv-on-demand" DVR episodes of "Medium." (My first response, oh so naive, was "Wow, this hotel has DVRs in their rooms, awesome! I guess it's about time since we've all got them at home!" Then I saw the price for everything on it. Give me a break. Where's that warm fuzzy -- oh yeah, this isn't a brand experience, it's a technology scam.)

I didn't bother to try the Internet. They had more neat technology where their elevator collection resided. So many floors and so many attractions in this hotel, that they had a special scheduling routine in place: you enter your floor number, and it tells you which elevator to go wait beside. Despite this clever system of crowd management, their elevators were so busy that staff were escorting the more upset customers (incl. me) to the freight elevators for more realistic timing on their people-mover service. When I got home, I came up with a few "nice" and possibly more interesting uses for their weight sensitive technology, instead of threatening their fleeced guests.

I know a lot of architects who love good hotel design -- but let me say, it's not just about architecture, it's about all the amenities and experience, including how they use their in-room technology. I'm still outraged!

Open Source vs. Organizational Code

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

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

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

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

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

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

2007 Usability Salary Study

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

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

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

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

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

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

Brain Cloud

Kyle Gabler's home page charms me as much as his simple but fun and well-executed word association game: Human Brain Cloud. You play by typing in words you associate with other words, and he grows the network of associations on the fly. The graphs are pretty to watch, easy to explore, with great motion effects; and his page of stats on players is suprisingly extensive.

Also, I adore his cartoon art. :-)

Other viral, simple online games: the Free Rice game, Just Curious (answer a question before you can ask one), the ESP game (labelling images).

Consumer Design is Easy?

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

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

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

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

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

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

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

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

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

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

A Look Inside SolidWorks

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

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

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

2007 in Review

One year ago this week, I quit my job and (after a bit of interviewing and thought) decided to consult for a while. It's been a good year! Some of the things I'm pleased with:

• Five excellent clients, and a couple of potentials I had to turn down because I was booked. Two web consumer startups, and one long-term established software company, whom I am still working with.
• Several opportunities to work on data mining: web log analysis, survey cluster analyses, and quantitative personas. Very interesting work! (I also took 2 classes from statistics.com to hone my skills.)
• A couple of web projects for which I provided the interaction design and project management actually launched in the same year, including the extremely successul NASA Tech Briefs Create the Future Design Contest site. (Winners will be announced this week!)
• Two publications by yours truly on the politics and skills of UI design: An article in interactions on the difficulties in practicing design today, and an essay in a new book, HCI Remixed: Reflections on Works that Have Influenced the HCI Community (MIT Press 2008). This book is hot off the press and a fascinating read.
• Incorporation for my consulting business, Ghostweather Research and Design, LLC. Followed by a crash course in accounting for small businesses. Who knew that credits were negative and debits were positive? And that Quickbooks is still a bit hard to use?
• I gave a handful of local talks at software companies, local design or usability meetings, etc, on design practices or online communities. Some of them are here on my essays page.
• Some technical fun: Opportunity to use Flash (so far just on small personal projects), Illustrator, PHP, mySQL, Excel with a database backend.

I did not do as much conference travel as I wanted to, but plan to go to CHI in Florence this spring, to help make up for missing it last year. I hope to see you there!

Southwest Gets Design

I just booked a flight on Southwest, and had a wonderful experience. Skipping past the booking part, I got a nice email receipt, which was easy to read. It's nice to get something that's easy to read. I especially liked their large friendly confirmation codes that are actually visible, colorful, short, and at the top!

On the receipt was also a very visible (above the fold) link: "Where Will I Sit?" I clicked on it, and got a popup window with a very cute hand-drawn progess bar, so cute that I had no problem waiting through it just to watch it drawing itself. And then this even cuter notebook appeared:

I actually read the whole thing, because it continued to be so cute and even funny, with hand-drawn pictures throughout: There was a sweet little animation of people getting on a plane, and a diploma for people who finish the notebook (I filled in my name, yes). At the end, I looked at the page source, hoping to find something suggesting who created it, and discovered that they had even tailored the error message for people with the wrong browser support:

I was thrilled, but also a bit sad. Apart from TiVo, I have never worked for a company that cared this much about the details; was willing to take such creative risks with how they differentiate themselves; who understand that even the error messages tell people something about them and need consideration. That's design and branding done right, together!

ETA: If you would like to play with the notebook, it lives at Southwest's BoardingSchool.

Designing Your Home Page

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

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

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

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

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

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

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

Fast Company: ebay, and Business in Siberia

I caught up on the latest print version of Fast Company on a flight, and I have to admit I'm loving it via print. I read almost ever word, while on the site I just browse occasionally. And now I can point to fun stuff, since the mag is all online.

First, some slightly irksome "news": ebay is trying to revamp itself in the face of flattening numbers. Like a lot of business press, this makes a hero-to-be out of a new exec hire, Matt Carey, CTO. He learns in paragraph one during a focus group that the site is hard to use. He determines to "make the buying process efficient and fun again."

Having heard the industry gossip for years about the company -- mostly from designers who've left in droves -- the people who knew it was hard to use and knew it needed usability and design work weren't listened to when it might have prevented flattening numbers in the first place. Too risky to change what was seen as successful! Till the big picture numbers start to look scary, and the competition spreads, I guess. That's when it might already be too late. A reminder that design and usability are strategic competencies not handled well by most executive boards at most companies.

On to more fun: Nightmare in Boomtown, a story you could not make up. With all the twisted personalities at work, it would make a good movie. It's the saga of a fallen rabbi gone to Kazakhstan to do business, and getting eaten alive by the corrupt system and an angry gangster rival who wanted a $5 million dollar discount he didn't get. It probably cost a few hundred thousand, but the ex-rabbi gets locked up in a Siberian jail for a year and virtually abandonned by any officials who should care.

In October 2006, after 11 months in Siberia, Seidenfeld was loaded aboard a prison train to be extradited from Russia to Kazakhstan. For 32 days, he was stuffed into a 3½-foot-by-7-foot cell in a boxcar with one toilet for 60 convicts. His fiancée, Natiya, doggedly followed the train on its 3,000-mile journey, intercepting it as it stopped at detention centers. Word of the presence of a wealthy Western businessman had traveled fast among the prisoners, and Seidenfeld learned early on the importance of isolating himself as much as possible. Natiya secured lawyers wherever the train stopped, bribed officials, and did whatever she could to make sure Seidenfeld traveled in his own cell. He kept his head down while shuffling to and from different prison stops to avoid the batons of the more-sadistic guards. "If I had been kept with the rest of the population, I might not be around today," he says.

Really a fascinating read....

Randy Pausch and Collaboration

I thought I had blogged about Randy Pausch's opening plenary talk at CHI in 2005, but apparently I didn't, and now I can't find his handout on teamwork. I know it's floating somewhere. But there are a couple of sites with notes: Usability News and the CHI 2005 conference website (the Conference on Human Computer Interaction, spelled CHI so it's pronouncable, hah).

I thought of his talk last week when I was giving a talk about design, stressing the difficulty and value in cross-disciplinary collaboration to an engineering company. (I've also been lurking on the Alice site wondering when the next version would come out, so this was timely!)

In his plenary, Randy had a bunch of great points about how hard teamwork between artists and developers is, particularly in our technocentric culture. Some of the points from the CHI summary:

• Neither side can be in service of the other
• A goal "above" either discipline really helps
• Different disciplines have different values, moral and otherwise

It's a form of prejudice to assume that people who aren't technical aren't valuable during the design process. Despite being quite technical myself by design standards, I run into this pretty frequently at the places I work. Randy himself is an arrogant geek SOB (as he'd admit) but he has some ability to recognize and verbalize these issues, which means there's hope for others too -- if they're as smart as he is and capable of self-reflection. His students will probably do some great good in the world, after they get tired of the game industry.

Speaking of hope, Randy's dying of pancreatic cancer at 46; and his last lecture was televised here. He's surprisingly young and healthy, but he doesn't expect to live beyond a few months more. That's the world we've got, but it's still fun and funny, if you listen to Randy talk about being a kid and growing up to do the things he always wanted to do.

Recommended, especially the part on mentors. (Thanks for the link, Xiaoyu.)

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!

Infovis at Yahoo

Apparently infovis is the new design black -- except design always had black, so that's not quite right. In any case, the new Yahoo Design Innovation Team site features more infovis displays than actual design work. By this I mean it features projects that display nice visuals of data, usually over time, in the form of movies. There is a lot of rhetoric in the intros about "unexpected patterns," but I must admit to finding a lot of them a little opaque. Only one of the projects is interactive, a cute but not very compelling "design a plant" flash application.

There seems to be an explosion of information visualization artwork suddenly, I suppose because the tools to create it are ripe and available. (Data is available as well, especially if you work inside a Yahoo or Google, but that's not even necessary.) But, curmudgeonly, I'm irritable at it, because so few of them feel polished into usefulness or offer useful interactivity. Infovis needs usability (and evaluation), too, like other design artifacts.

Other observations on infovis displays of recent months: time series data is the current black of infovis -- showing changes over time, usually in animation format. Perhaps it was last season's black, because it's everywhere in the current crop of visualizations, including those on Yahoo's design site (traffic issues in LA, trips -- similar to the beautiful one in processing of airline flight patterns). This makes tremendous sense -- as humans we live in 4 dimensions and it's nice to get information about that 4th one. However, just because it's visible, doesn't make the story it's telling useful. Sometimes you want to take an insight from the time progression you watched and flatten it back into 2 or 3 dimensions to get the story summarized in a form that's useful without it disappearing in time. I don't see this option to convert easily from "playback" to flat summary of a time window in most time series animations, and would often like it. (Bar charts that move over time aren't what I'm talking about, because those are still moving!) Notice that this request asks for not just visualization, but actual interactive tools to play with the data and explore it!

The other thing many folks are exploring, and I think less successfully, is text data. Unstructured text offers a few obvious and old hooks: context around specific words and word or phrase frequencies. Beyond that, things get hard fast, because you have to think about parsers or other complex data mining models. Text vis is the ultra-violet of infovis. There are a couple projects on Yahoo's page that inspect word use at the basic level: the pronoun context display, and the answer cloud frequency display (why are piercings and hysterectomies showing up so often? Is this an artifact of the time window she looked at or something about the user populations issues?).

Regardless of the curmudgeony post, it's nice to know where Joy Mountford is these days.

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.)

Zen Error Dialog and Flash Victim

I especially like the title bar on this guy: And a friend sent a link to a great animation of a flash victim getting destroyed by the app. Lots of in-jokes for designers who use Flash, and hilarious anyway. You definitely want sound on for it.

User Experience 2007 Survey Report

The Usability and User Experience Report 2007 from e-consultancy costs money, but the sample data are interesting enough to post about. There were 756 respondents to the survey that fed this report. (Hopefully it represents more than just the UK, where the consultancy that did the survey is based.)

Some highlights:

• On average, organisations are investing 11.5% of their overall website design and build budgets in usability, and 13.2% of their design budgets. [If you're spending none, or you don't even know what you're spending, this may be an Issue for you.]
• A quarter of agency / consultancy correspondents say their clients are typically indifferent whereas only 9% say their clients are extremely committed. [I admit I find this surprising -- if you've been hired as a consultant, doesn't that suggest they care? Or is the evaluation of caring based on more complex factors, such as "are you listening to my advice," "is there anyone else in your organization advocating for this," "is it likely anything will change after I leave."]
• Top benefits/ROI for commitment to user experience and usability included as number one and two, improved perception of brand, and increased conversion rates. [Since brand is now being defined as what a customer thinks of you and what and how you do it, rather than your logo and graphic design [see, e.g., the Brand Gap], this makes a lot of sense to see here.]
• Two thirds of the respondents say their agencies plan to increase their spending on usability in the next year.
• The activities that are being "done" in organizations are, in order of frequency, user testing, expert evaluation, information architecture; and lagging behind, "full user-centered design" [a rigorous process that incorporates testing and design during the definition and development cycle].
• The largest barriers are time pressure to get things done and lack of resources. [We still have a ways to go to educate businesses about the risk factors in not being more rigorous about the processes for good design up front, it seems.]
• Project management is either not done, or being done "ad hoc." [Coincidentally, I've just written an article for interactions, a professional journal for designers, on the ways in which designers get lured away from doing design and into project management, in order to be sure that things get done. Timely!]

The full report costs $179.

Stephen King on Writing -- And Design

I like this no-nonsense essay by Stephen King, Everything You Need to Know About Writing Successfully - in Ten Minutes. I think it applies to doing good design as well.

Here's my remapping to design:

• "Be talented" should go without saying. Design is an art, too, even if it's data-driven. There is still creativity involved in knowing how to ask the right questions and take insight from the data.
• "Be neat" may be my own weakest point -- I'm a sketchy ideas person, and struggle for the pixel perfect after the big insights. But I keep trying and see it as a self-improvement challenge.
• "Be self-critical." If you haven't thrown away a bunch of ideas, and can't show that you have, you're probably not talented. The same goes for photography or any other art that takes practice to do well. Idea generation is easy, choosing the right ones for the right reasons is the skill part.
• "Remove every extraneous feaure." That's my redoing of King's "extraneous word." It's about clean design -- it's harder to get to the core than it is to throw in everything you thought of. It's also braver, faced with the "featuritis-sells" mentality that even some (most?) customers have in saturated markets.
• "Never look at a reference while doing the first design." Hmmm... In the spirit of letting creativity run free, I like this. But I need to think some more about its applicability here.
• "Know the market." Know the users, know the competition, know the business. Don't work in a creative, monk-like vacuum. Your work won't be very smart and your clients/company will stare at you funny when you present it.
• "Design to improve someone's life." King had "write to entertain," and I lean towards keeping it at the same sentiment even for a professional product -- but instead I think this is about more, like elegance, and beauty, and that "wow" moment that people get from using something that works well and does exactly what they didn't know they wanted it to do!
• "Don't design if you've stopped having fun." If you've turned into one of those hurt, tired people who feels like no one gets it and you're wasted there, you can't be Jonathan Ive at Apple. (I don't know if he's tired, but he did stick it out and it eventually paid off.)
• "Take usability input and use the design or start fresh." King's point is about how to weigh feedback: if you hear different things from everyone, you can probably ignore it safely; otherwise, take it seriously even if you don't like it.
• "If it's bad, kill it." Too few companies can do this; designers themselves need to be able to do it with authority to their own ideas. You're a hack if you don't know how to filter your own ideas. Remember, ideas are cheap! You are paid to be creative, right?

Successful people are generally also practical, and King really brought that home to me. In fewer words than I would have done, to be sure! His introduction story makes a few other good points: Even people who are talented need critique and input from more experienced people to get better at what they do. They need to be receptive to that. And not everything they design will be for a domain they know something about. It's part of the talent of a good designer to get into the heads of potential users, to do the research to understand them as input to the design process.

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!

Funny Networks

I really appreciate a sense of humor in a network diagram. Here are two unusual ones found on visualcomplexity's feed, introduced with such sober and boring description that I was saddened for the VC readers who are probably missing the fun here.

The Story Map is a social network diagram of a wedding party, with the arcs annotated by relationship facts that link the nodes. It's beautiful and inspirational. Why are social network pics not funnier in general; relationships are, right? (Well, some. I guess professional ones aren't very. At least the publishable diagram versions.)

Next is a bigger investment, but worth it if you love detail (of the really obsessive type). An art project by Media A of massive size (10 meters), it's a representation of a fictitious designer's life spanning a century into the future. The Networked Designer's Critical Path is a PDF (3 MB) that takes time to download, but I guarantee it's very amusing and science fictional. Here's an excerpt (English in light gray):

Notice the chronic over-networking issue in the center there. Heh. My printer dialog says it would be 171 pages if I tiled to print this sucker at 100%. I'm tempted anyway.

Digg Labs Infovis

I've been enjoying the latest infovis apps from Digg Labs, co-created by Stamen Design (I want to be them when I grow up) and funded by Intel.

These cool applications let you watch digg news stories being posted and re-dugg in real-time. They're all good at different things, and compelling for different reasons.

My favorite in terms of "hypnotic to watch" is the swarm. It's eye-candy for the ADD set.

It does have some issues as a tool, however -- if I were them, I'd have prioritized the display of the text identifying the article over the other graphics, rather than letting it mix in with the background (see above). Also, I don't entirely understand the beautiful mysterious arcs that sometimes appear, but I'm not sure I care, either.

While watching a bunch of these, the role of time gets problematic for me. I'd like to be able to replay, or step backwards (like if I missed a cool event in the swarm). And watching the big arc display for "newly submitted" in the category of science is really boring, or was on Saturday night. (See if you can even figure out how to do that that!) Finally, I would far rather go right to the article itself than click through the digg page first. That's a minor quibble, though.

There's a definite long-tail problem on digg, isn't there -- lots of the same stuff gets dugg, and it's hard to find high-quality new stuff that matches your interests.

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.

Wow: Lotus Blossom

This is fast (no load time waits and a genuinely frenetic pace), simple (text and music -- turn it on because you need it), and even better, genuinely funny: Lotus Blossom.

Go watch! Where you can do it with the sound on. (Don't watch if you might have issues with strobe effects in place.)

12 Breeds of Client

Freelance Switch, a site for freelancers of all types, has a nice post about different types of client personalities and how to handle them. It's applicable whether you're a genuine freelancer or working in a consultative role inside a large organization -- I recognized a lot of it from traditional dealings with consumers of interface design and usability, including previous managers. Some of my favorites, in the "recognizable but not so nice" category:

• The Hands-On Client: The hands-on client is a frustrated artist, as soon as they walk in the door they will be telling you about their skill as an artist, illustrator, photographer or writer. The hands-on client already has a very specific idea about what they want and usually has very little interest in your thoughts on the matter.... If you feel you have an ethical responsibility to point out the flaws in your hands-on client’s directions, you are headed for conflict. Hands-on client’s secretly believe that they could do their job much better than you and that there is little or no specialist knowledge you could possibly impart. One oddity about working with a hands-on client sometimes occurs when you give in your creative ambitions and agree to do it their way. All of a sudden your hands-on client may accuse you of making them do all the work or not doing your job.
• The I’ll-Know-It -When-I-See-It Client: The I’ll-Know-It-When-I-See-It client shares much in common with the uninterested client except in a more frustrating way. Their indecisiveness and inability to articulate what they are after makes them one of the few clients that it is generally best to steer clear of.
• The Always-Urgent Client: All their emails are ‘highest priority’ and their couriers are always red-hot. They work on weekends and late into the night and think that everyone else does too. Additionally the always-urgent client often seems to think they are your only client and that their job should therefore be your highest priority as well as theirs.
• The Decision-By-Committee Client: Usually inhabiting the world of large corporate clients, the decision-by-committee client can still be found in smaller operations where they share their decision making with a spouse, neighbour or dog. The decision-by-committee client is one who lacks a single point of authority and for which every decision must be approved by many people.

I'm breaking in a new tag for this one, a consulting tag.

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.

Adorable Monsters

Two cute monster-related items for early April:

Daily Monster, an online growth of cool monster art. It's Stefan Bucher's site (thanks Steve): And while I was poking around on Jared Tarbell's site for a friend, I found his combinatoric monster art, which made me grin wide. I want to be Jared when I grow up.

Web Infovis: Crispyshop.com review

Found on Information Aesthetics, a regular read for me...

Crispyshop.com is a fascinating blend of data and shopping results that, sadly, doesn't quite work for me on grounds of overall design usability. I love to play with it, but I can't figure out how to use it to pick the GPS device I'm looking for. It has some very basic issues, which in this era of "user experience" shouldn't be happening! (Hey, I know, hire me to consult for you, guys!)

The main display is this very fluid graph showing price on the Y axis, and the dots represent products. The green dots are a great idea, but don't work in practice: you see one suggesting it's a better "deal" (by some number of unknown factors) and you head for it, and it disappears. The UI is simply too fluid. Also, you should never get an error for a simple search like the one I just got:

Whatever you do, you've gotta return results from any search done. Not an error and not a "not found" page. Finally, once I did find a product I wanted to look at, I did the usual thing -- clicked off to a merchant site to look at the details there to make sure it's what I was expecting. And an annoying popup error kept grabbing me back to the crispy page: "A script on this page is causing Mozilla to run slowly. Abort it?"

One last bash: the passion here is in the beautifully fluid graph details, clearly. To the left of it is a disappointingly "normal" set of filters that most people just don't use when searching, because they pose various cognitive problems when you're just browsing around and trying to educate yourself about a product space. These ones are particularly poor, in that the pulldown menus don't show the number of results associated with each choice (for instance, if I filter by "10% off and More" will any show up, or will I be wasting a click?). The way Kayak.com handles this is inspirational, of course, in that you get lots of information to help you manage your filters, including some little graphs showing ranges. Wine.molecular.com's demo app is a nice one too, but only works in IE for me. They show a small barchart, but only when you mouseover the slider:

Search is hard to design well: it's all about successful data reduction, for the end-user. People don't scroll through pages of results. But I'm always disappointed by cool ideas partly executed. Is the Crispyshop site intended to support a common task, or just showcase the author's brilliance in one domain (and I admit, he's pretty brilliant at that)? Is it meant to be done, or is it another beta like the endless Google beta empire?

This sadly reminds me of the conversation I had with a spokesperson for Tableausoftware at last year's Infovis conference: There was no usability testing done for that product during design, and it shows in use. I needed an in-person tutorial to get anywhere with it after having downloaded the demo version already. The functionality is excellent, but for a new user making a purchase decision, that's unfortunate in today's software world. Old software products, I will cut them some slack -- but a new product? Even just a professional once-over by someone like me can help catch a lot with the basics.

Organizing for Product Design and Production

I had an interesting chat yesterday with a manager in a large international company that is restructuring to support better innovative product creation. He asked my opinion on a number of topics, relevant to their effort:

• Matrix organization of cross-disciplinary teams: marketing, engineering, and operations, for instance. I suggested that at the innovation phase before product development, the team might look different and have different skills, such as design!
• Does long-distance collaboration really work during product design? I said it can, and that although video gets a bad rap, we used it effectively at Adobe in the same time zone. I am less sanguine about major timezone differences, and still a firm believer in regular face-to-face, especially at the start and during times of tension, for defusing it over a drink or meal. For designers, there's more artifact production to communicate ideas long-distance; and the whiteboard collaboration hasn't really been adequately replaced by any conference tools I've seen, but I'd love to be wrong if someone has a suggestion.
• Quality of product: Get it out or get it right? I said this depends on ability to absorb risk in a brand, and first to market vs. competitor situation. A first-to-market product can get a few things wrong, and still have the advantage. Not if they got the major things wrong, though, and destroyed their own business and can't absorb the hit. Soft launches and long betas are another tried and true method. Google seems to live on eternal betas -- but of course they did get search pretty much right, first, as far as state of that art goes now.
• Outsource concept design or do it inhouse: I said this depends on how much product innovation is meant to be a core competency. I think it should live in-house if it's meant to be core, because it's a risk to outsource all good idea creation. Also expensive.

It wasn't a specific question, but I pushed for the value of ethnograhic research for identifying new product areas and gaps in markets; and the value of design of both the industrial variety (closer and closer to home for software now) and the usability/interaction variety. The need to reward and remember failures is important here to encourage iteration and re-application of old ideas in new ways.

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.

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.

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?

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.

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.

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.

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.

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.

architecture and hygiene

A friend at work pointed out this amusing site, found after he googled "architecture, hygene" late at night (Google fixed his spelling): architecture and hygiene.

The main gist is prefab houses, but Kalkin's houses are mixed in with a bunch of other entertaining content, like this easter-egg map of how an architect conceives of the universe. (I'm surprised it doesn't have phenomenology in it, but instead it gets the more relevant "anomie.")

But the order form really made my night.

Davos Quotes on Creativity

Fast Company Now blogged about events at the World Economic Forum at Davos, especially the themes on creativity and innovation. The pieces are all quite short, but a couple are relevant to my last post on the NSF workshop on creativity tools.

In the "Innovation and Design Strategy" session, the panel members were asked to describe what they saw as the key to creativity.

Last to be voted off the island was Ideo's Tim Brown, who suggested that creativity is spurred by approaching problems with a beginner's mindset, and by exploring ideas through the use of rapid prototyping.

And the winner is: Google's Marissa Mayer, who argued for "a healthy disrespect for the impossible" combined with the virtues of constraints. In other words, aim high, but focus. Mayer described how an artist friend once told her that it was much easier to paint on a canvas that already had something on it--a mark or a line of some sort--than to begin with an entirely blank canvas. The existing mark is a constraint, something the artist has to think about and work around. And product developers at Ikea begin with a different sort of constraint, she said. They start with a price they have to meet--say $49--and then think about what they can make for that price.

I remember once being asked to just go off and design a solution for a big hairy problem -- with no realistic inputs at all to ground it or steer my direction. What's the ideal solution, Lynn?? I could have done something, but that waste of my time would have been more than I could have tolerated after the fact. The real development world is a world of constraints, and given a million other things I was also responsible for, I would have been in a bad mood indeed when my creative exercise was shot down as unrealistic. To this day, I am careful to always include minimal acceptable versions of every design idea I come up with -- because everything gets cut down eventually.

And the blank canvas is a bitch to start from, as she said. Translating that into software tool terms, I think it's more fun to start from something not quite right (a template for a document design, a building component?) and then modify it to get what you want.

Here's another one from their coverage, just because it's pithy and reasonable and I was on the page:

A Columbia University economist, Xavier Sala-i-Martin, spoke at a session on global competitiveness in Davos this morning. He offered what I think is the most succinct statement of the stages economies move through on their way to becoming innovation-based. First, he said, you concentrate on making something cheaper than anybody else. And when you can no longer make something cheaper than anybody else, you concentrate on making something better than anybody else. And when you can no longer make something better than anybody else, you concentrate on making something different than anybody else. That's the innovation economy.

Creativity Support Tools

Ben Shneiderman has posted the individual papers and extensive summary of the NSF-sponsored Workshop on Creativity Support Tools that took place in June 2005.

I haven't read all of them yet, but my initial impression is some disappointment that the workshop participants were academics and no one purely from the creative tool "user" persuasion was there. It looks a bit industry internal, and not just software industry internal, but research-world internal. Many of the literature citations support this, although I did find a book or two I didn't know about (e.g., Polya's How to Solve It). It wasn't surprising to see quotes from Csikszentmihalyi's Creativity but it was not clear to me that the cultural recognition of creative work as valuable should be relevant to the design of software to support the act of creating.

This said, there are interesting points, especially if you work on software design for creatives, as I have in the last 3 jobs (if you include scientists, which Mihaly Csik. does). The Design Principles article includes these items:

• Support Exploration: First, it must be very easy to try things out, and then backtrack when unsuccessful. This means that the tools must be trustworthy so that users are comfortable trying things. For example, a very good Undo capability is required in the tools.... A second requirement is that the tools be “self-revealing” so that it is clear to users what can be done. If the flexibility is not apparent, it will not be used....Another way to support exploration is to make it very fast to “sketch” out different alternatives at the early stages of design.
• Have Low Threshold, High Ceiling, and Wide Walls:Effective tool designs should make it easy for novices to get started (low threshold) but also possible for experts to work on increasingly sophisticated projects (high ceiling) [Myers 2000]. The low threshold means that the interface should not be intimidating, and should give users immediate confidence that they can succeed. The high ceiling means that the tools are powerful and can create sophisticated, complete solutions. Too often tools that enable creative thinking may be quite hard to learn (they don’t have a low threshold). Instead, they focus on providing numerous powerful features so that experts can assemble results quickly. Now, we add a third goal: wide walls. That is, creativity support tools should support and suggest a wide range of explorations.
• Support Many Paths and Many Styles. People work in different ways, right brain vs. left brain, "hard" vs. "soft" approaches.
• Support Collaboration among multiple users. In all of our projects, in schools, and in the “real world,” most creative work is done in teams.
• Support Open Interchange: The creative process will not usually be supported by a single tool, but rather will require that the user orchestrate a variety of tools each of which supports part of the task. Creativity support tools should seamlessly interoperate with other tools. This includes the ability to easily import and export data from conventional tools such as spreadsheets, word processors and data analysis tools, and also with other creativity support tools. This requires that the data formats in the files be open and well-defined.
• Make It As Simple As Possible - and Maybe Even Simpler: A plea to reduce featuritis, which will appeal to my boss, for sure.
• Choose Black Boxes Carefully:In designing creativity support tools, one of the most important decisions is the choice of the “primitive elements” that users will manipulate. This choice determines, to a large extent, what ideas users can explore with the tool – and what ideas remain hidden from view.

While the principles look good to me, the examples surrounding them are a little thin, as far as my needs go. But I found it interesting reading nevertheless and recommend browsing the site.

More Adobe: After Effects Tour

Whilst avoiding blogging about irritation-provoking topics (e.g. the science article claiming men like women who laugh at their jokes but don't care if women are funny-- thanks, steve!), I happened on some good news: A video demo showing off some new features in the new release of Adobe After Effects.

Quite possibly the healthiest team at Adobe when I was there, AE had good UI design, good team process, famously good project management, good tools for tracking workflow internally and customer issues (actually integrating the two, good grief!), and a user-centered modified agile development philosophy that actually worked. Someone on their team should be writing articles about their processes, hint hint.

The new product shows some nice UI improvements in palette and window management, as well as 2 tools of great usefulness to me and many people I know: precision time fx, and smart blur fx. The graph UI controls make the chart geek in me salivate, too.

Note the increasing number of product integration features. I keep hearing about AE and Flash, so it's continuing even with Macromedia in the corporate mix now.

Printing with Photoshop

When I was working on UI design for color management at Adobe (for CS2), one of the things that made our cut for "must fixes" was the print options in Photoshop. They looked like this, if you recall:

The goal of this original design was to provide enormous flexibility in how printing is accomplished with respect to color handling. Color "management" is a hard science topic that is not for everyone, and barely understood even by most creative professionals in the print industry. The average Jane trying to print her photos in Photoshop (or even the average consumer pro photographer) was tripped up by this dialog all the time. What does it mean, "same as source?" When should I choose something different? What combinations are good and which are bad, and for what??

The short story of color handling is that there are conversions going on all over the place -- an image viewed on the screen looks one way, because it has been interpreted by your OS and screen settings to be seen as you see it. It may not be seen the same on anyone else's screen. A common complaint from the common user of Photoshop is "I printed and it looked different." It will always look different, because you are now converting to what your printer can print, not what your screen can display.

"Profiles" are descriptions of how the colors in a file should be handled in conversion, more or less. One of the strengths of Photoshop is that it lets you simulate ("proof") how something will look on another device. You can even use your printer to simulate another printer. But you have to pick all the right combinations of profiles, and have good ones so you get accurate previews.

Photoshop has an excellent conversion engine. Some printers do too, and some consumer printers do, but you can't be sure. Every device will differ a little, and consumer profiles are batch produced. I grew up in my understanding of color handling at Adobe concluding that I'd never use my printer's color management because these consumer devices just won't be reliably good; I'd rather trust Adobe's world class color scientists, with whom I was then working!

Now, here's the shipping (CS2) version of the design I helped to produce to clarify your choices in Photoshop, showing the two crucial options for home printers:

We couldn't do much about the consumer printer drivers and in particular couldn't override their own color handling, so we relied on rollover help that I think ended up a little vague about what you need to do next. In my Canon printer dialog, the necessary place for enabling or disabling color management in the printer is buried in this "ICM" language:

But now that I have the new Photoshop CS2 UI to experiment with, I've discovered (to my chagrin) that a color management problem I hadn't been able to diagnose is Photoshop's conversion's fault. At least, I get the best results from enabling color in my printer, instead. The preview my printer driver gives me before it prints is quite accurate, it turns out:

There's obviously a lot more to say about color management in printing (entire books have been written on it), but my reason for posting is to say: I hope we made the world of the Photoshop user a little simpler, at least as far as debugging their printing issues goes. I haven't heard any customer feedback on this myself, but it sure has helped me! (And I was privileged to have been able to work on this with the color management team at Adobe, including Lars Borg, Chris Cox, Russell Williams, and Matt Philips.)

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.

Usability Research References

Human Factors International (a well-known consulting firm) does end-of-year summaries of important usability research findings in bite-size bullet pieces. The items are useful for designers and researchers working on any UI topic, but there's a definite focus on web design (for obvious reasons). The review is titled Yeah but can you give me a reference?

The 2005 list includes:

• What users think/ say they will do in focus groups and what they actually do in usability tests often differs. (Eysenbach and Kohler, 2002) [This is a truism often repeated, but now there's a reference you can cite!]
• Tolerable wait time is about 2 seconds. Users will wait somewhat longer if there is feedback that something is happening. (Nah, 2004)
• Use of whitespace between paragraphs and in the left and right margins increased comprehension by almost 20%. (Lin, 2004)

They did the same in 2004 and 2003. Interesting cites from those years include:

• Less than half of users take advantage of breadcrumbs (even when most report having noticed them). (Lida, Hull and Pilcher, 2002)
• Under click-stream analysis, breadcrumbs are not more efficient than other approaches to navigation. (Lida, Hull and Pilcher, 2002)
• Color similarity has a stronger perceptual influence than common region, proximity, or grouping. (Beck and Palmer, 2002)
• Photographs do not increase the trustworthiness of already credible sites. They do, however, improve the credibility of sites that are not generally perceived as trustworthy. (Riegelsberger , Sasse & McCarthy, 2003)
• Heuristic review tends to uncover usability issues related to presentation (skills- and rules-based user performance). (Fu, Salvendy and Turley, 2002)
• Usability testing tends to uncover issues related to domain-specific knowledge and interaction (knowledge-based user performance). (Fu, Salvendy and Turley, 2002)

On the final subject, another issue of the HFI newsletter features an article on Pitting Usability Testing Against Expert Evaluation. This is an excellent piece, summarizing well the things that expert evaluation can do for you and what to realistically expect from usability testing -- including where they overlap.

form doesn't follow function-- in architecture.

In biology, the fact that form and function are closely related is proved over and over, especially with respect to protein shape and behavior. As a newbie to architecture, I wasn't surprised to hear that architects also believe in the mantra that form follows function. Building shape should reflect and reinforce what it's for, more or less.

Except, experimentally it doesn't seem to be true most of the time. This is an entertaining article reporting an experiment testing whether people can recognize the type of building from the exterior design. In short, they can't. I'll leave you to read the details of their experiment (and what it suggests about the sad state of American architecture) and just report the ending:

Other studies have shown that people already "read" buildings to judge the status of people who live or work inside, and to determine if the buildings are in a safe neighborhood, among other things, Nasar said.

"Buildings convey meaning, whether they are meant to or not," Nasar said. "So it makes sense that buildings be designed to indicate their use. But our results suggest it doesn't often happen."

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.

Ching's Visual Dictionary of Architecture

This is a wonderful book. I mean, wonderful like Tufte and Bringhurst and Christopher Alexander and Scott McCloud... a book you open and can't put down because you get drawn into the beauty and details.

Even architects think it's a thing of amazement, and will tell stories about the original edition with Francis Ching's handwritten annotations, before later editions switched to the cursive font.

I spent about half an hour incapable of picking examples to display, but here are a few that I liked in that time. The discussion of rooms and room arrangements is enchanting. I've cut off the little people ascending to the adject level, alas.

Here's another example showing stress diagrams for trusses. (Trusses have been a big deal in my office recently. I had to look them up.)

There are sections on the tiniest details of joints to the widest of concepts, drawing, and what it's used for and how. Architects love it. Buy this book for someone for the holidays and then get it for yourself!

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.)

The Beauty of Simplicity

Fast Company has a nice article on the tension between simple design and sufficient design. (That's characterization of the problem, not the author's). The Beauty of Simplicity gets into some useful case studies after the lead-in on Google's home page.

Some highlights: Less isn't more, just enough is more. What constitutes "just enough" is harder than it looks. ... "It's easier," says Charles Golvin, principal analyst with Forrester Research, "to market technology than ease of use." "Every new feature makes things more complicated , even if you never use them." But.... "The market for simplicity is complex," says Dan Ariely, a business-school professor who is spending a year off from MIT figuring out how to quantify the value of simplicity at Princeton's Institute for Advanced Study. "If I offer you a VCR with only one button, it's not all that exciting, even if when you use it, it's likely to be easier."

There's the Philips corporate retooling story:

How do you make your products simpler? You start by simplifying your company. ...Philips deployed researchers in seven countries, asking nearly 2,000 consumers to identify the biggest societal issue that the company should address. The response was loud and urgent. "Almost immediately, we hit on the notion of complexity and its relationship to human beings," says Andrea Ragnetti, Philips's chief marketing officer. Rather than merely retooling products, Philips would also transform itself into a simpler, more market-driven organization. That initiative has been felt from the highest rungs of the organization to the lowest. Instead of 500 different businesses, Philips is now in 70; instead of 30 divisions, there are 5... While many of the new products have yet to hit the market, early results of the business reorganization, particularly in North America, have been dramatic. Sales growth for the first half of 2005 was up 35%, and the company was named Supplier of the Year by Best Buy and Sam's Club.

Then there's the Intuit story, which rings loudly to me.

... So Hicks's team first tried a knockoff of Intuit's QuickBooks Basic, with a bunch of features turned off. Then they confidently took the product out for a test-drive with 100 potential customers. And it bombed. It was still too hard to use, still riddled with accounting jargon, still too expensive. They realized they had to start from scratch. "We had to free ourselves and say, 'Okay, from an engineering point of view, we're going to use this code base, but we need to design it from a customer's point of view,' " says Lisa Holzhauser, who was in charge of the product's user interface. ...They pared back 125 setup screens to three, and 20 major tasks to six essentials. They spent days worrying about the packaging, knowing that to this audience, something labeled "Simple Accounting" was an oxymoron.

Above all, they subjected their work to the demanding standards of Intuit's usability lab, run by Kaaren Hanson. To get a product by her, users must be able, 90% of the time, to accomplish the tasks deemed most critical. It's a draconian standard. But "if our goal was to make it 'as easy as we can,' " Hanson says, "we wouldn't be as successful as if we had set a concrete number."

The Simple Start team thought they had nailed the user-interface problem after their third iteration of the product got rave reviews for its look and feel. But task completion results from the lab were dismal. The launch was delayed for months while the team reengineered the tools until they measured up. [Lynn's bold, not theirs.]

The additional time was worth it. Simple Start--a product with 15 years of sophisticated QuickBooks code lurking behind an interface even a Luddite could love--sold 100,000 units in its first year on the market. Even better, reviews from target customers indicate that Intuit hit the mark. Ken Maples, owner of a tiny flight-instruction school in Cupertino, California, summed it up: "It's easy to use. It's got everything I need and nothing more."

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.

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.

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?

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.

Color Words and Color Products

Two things made me think of each other today:

Martin Wattenberg has a fascinating look at the colors that lie behind the lexicon in his Color Code: A Color Portrait of the English Language. It's really fun to browse and mouse around, like most of Martin's work.

And this guy over on Flickr has Safeway aisles as color bars, abstractions of the colors of products in an American supermarket. They're surprisingly pretty.

Complexification

Complexification's Gallery is an awesome, hypnotic site. This is Jared Tarbell's art created by algorithms, and it can be drawn in real-time in front of you. As an unusual bonus, you can see the applet source code for the non-Flash ones. The software tool used to create the applets is Processing, an open-source visual and audio art programming language (which I will download after I finish playing with Tarbell's animations).

Update to add: There's some entertaining explanation of the simulations behind the art, especially the robot offspring one: Offspring is a visualization of the pair bonding process of a theoretical robot colony. Each robot is assembled, ages through youth, comes into a reproductive stage, and eventually dies of fatigue. If a robot is lucky enough to find a mate during it's reproductive stage, baby robots may be assembled.

Rob's Amazing Poem Generator

I love semi-random text generation, and especially like it when you can seed it with a good starting sample. Here's an example: Rob's Amazing Poem Generator.

I fed it a few URLs including my own, but the results I like best come from my favorite website for oddities, The Anomalist. I think they're probably better than average because the theme is more uniform.

THE standard gravitational model.
East Kingston Woman Reports a big
Foot. Is overloaded with Big
Bang theory of exploding stars in front of the hydrophone. The
Books and about
three four feet long and
Orkney was
actually
fairly common during hurricanes. And: vibrated.

The March of Pies: Gallery of Data Visualization

The Gallery of Data Visualization offers examples of good and bad statistical displays. The Have Something to Say category is especially amusing:

Blind Lemon Jefferson, the great blues musician, was once asked why there were so few white bluesmen. He replied, 'Knowin' all the words in the dictionary ain't goonna help if you got nuttin' to say.'

This image, from the graphic design book Diagraphics II, attempts to show the relative market shares of Sotheby's vs. Christies over time. The graphic designer has cleverly used a variety of tricks to show.... What? Well, it does make clear that time is increasing over time. But there surely isn't much else going on.

Wordlock

This has shown up a number of places (I got it off MetaEfficient), but it's such a "why oh why wasn't this invented earlier" thing that I have to post it: The Wordlock. A combination lock that uses letters to form words you are more likely to remember, and can be reset to another word at any time.

It also looks like it's way smaller than your average combination lock with a number spinning faceplate. It's only $5.98 from Staples and comes in colors.

Some Philosophy Behind Good UI Design

I've had a number of conversations about interface design recently in which it was suggested that excellent design doesn't really matter, and that as a designer I have some kind of extreme bias towards quality that amounted to, well, anal fluffiness. My friends seemed to be sold on the concept of usability, which is, after all, a wholesome sounding term (except in France where it doesn't exist), but the relationship of usability to good design was non-obvious to them. While avoiding a homework assignment, I dug up a few relevant pointers.

Andries van Dam's overview lecture (pdf slides) provides a thorough introduction to the process and goals of interface design (although he uses many more linguistic metaphors than I would). He notes in the early motivation section:

In many modern programs, the user interface code constitutes the bulk of program, i.e., 70-80%.

• For the most part, the user interface is the key to the success or failure of a program
• Creating a good UI is often harder than software engineering because UI design requires much more than software engineering skills
• Some people typically believe UI design is unimportant because they misunderstand the design process/methodology
• Nowadays, software companies can be very picky about choosing who designs their user interfaces because the user interface defines the product

What is being designed? Two languages and the dialogue that interlaces them: Users(s) - > computer-> user(s).

He notes that the UI code usually accounts for most of the code in a modern application, and it's often hard to write and change. (As a corollary to this point, it's my belief that a corporate culture that considers UI engineering as a second class activity, or "not hard," will not be generally capable of getting consistent good results from their product interfaces.) Designing the dialogue between the system and the user requires a non-trivial understanding of many things, including: the widgets in the set of tools available, the features and tasks to support, the mental model of the user going in, how to reveal the model of the application for learnability, what standards exist and might bias your users to expect certain behaviors from your application, what counts as basic vs. advanced functionality (10% of the features are used 90% of the time), good visual layout to support discoverability and task structure, and so on.

Application design is not a static problem -- one screen at a time -- but a dynamic one, and hence van Dam's use of the conversation metaphor. What happens to the interface when your user clicks here; and more globally, how does the application surface the product features during use over time? Does it make sense to a user, or is it only sensible to the development team who structured their code a certain way and locked in a possibly non-intuitive task flow that is now reflected in the interface? The interface, after all, is not icing after the architecture work, but a fundamental part of the entire problem you're solving with your application design.

Seth Nickell at Red Hat summarizes absolutely bang-on the difference I see between designing via lots of usability testing (a parody of the non-design approach to getting usability "into the cycle" a la Microsoft, until recently) and having a designer involved in the process. One of the well-known issues with usability testing is that it finds local problems, but can't itself help you understand the global causes and solutions to those problems. Seth's points are: A good designer will get you much farther than a bad design that's gone through lots of testing and Usability testing is not the best technique for figuring out the big picture and Usability tests can't, in general, be used to find out 'which interface is better.'

During testing, a user may muddle through even a poor design, and with qualitative testing it's tough to say "that's it, it's not good enough" -- there is always a tendency against change, for efficiency reasons, in any software organization.

I'll keep looking for more inspirational pointers, as this is a subject I care deeply about.

SketchUp

This SketchUp product for 3-d drawing got rave reviews on Cool Tools. The reviewers praised its excellent, intuitive design and feature set. Since I've always been tempted by the idea of designing 3-d Victorian mansions, castle ruins, and haunted houses, yet can't believe this could ever be easy, I watched the movie demos on their site.

Although I'm dubious about how fast one could get up to speed with it, it does look like they did some hard things right. The app looks like a lot of other drawing tools (e.g., Adobe products), offering a big palette of modal mouse tools; and there's a persistent "help" text on the bottom telling you what to do and what key combinations extend the function of the tool (very Adobe-esque). It's the keyboard shortcuts, of course, that would be the hardest to learn as a new user. Once you know those, you're probably focused on the art and not the mechanics, which is what you want in any creative activity.

They've got a clever function for "bookmarking" important views of the buildings for showing clients; they have a nice shadows-by-time-of-day slider bar that looks fun to play with; and they give useful feedback during drawing via tooltips that pop up to tell you what your current status is while you're manipulating the building and objects ("on face" etc.). You do still need to know something about physical objects -- to create a roof from a flat surface, you have to know how to draw the joints that will bend in the right form when you move the lines upwards. All the connections are "smart" and pieces move as units, but you've got to know what you're aiming for, too. (Just like when using Photoshop -- if you don't know what saturation is, you can't use that tool well).

Perhaps most compelling of all, there are downloadable plugins and scripts and "components" (like trees and buildings and people), reminding me of extensible game worlds like the Sims. I'd like to get them together -- my problem with the Sims is that I don't want to start with a white trash shack and build up to a good life, I want a beautiful mansion right from the start. And their building tools aren't so hot, either.

I digress -- SketchUp is, alas, $500. I may still try the free trial, good for 8 hours.

Creative or Nuts?

In the Psychiatric Times: Are Genius and Madness Related? Contemporary Answers to an Ancient Question . The answer is "yes" by a number of careful measures. Creativity is described as this set of attributes:

In general, creativity requires the cognitive ability and the dispositional willingness to "think outside the box"; to explore novel, unconventional and even odd possibilities; to be open to serendipitous events and fortuitous results; and to imagine the implausible or consider the unlikely. From this requirement arises the need for creators to have such traits as defocused attention, divergent thinking, openness to experience, independence and nonconformity.

Despite the linkage between depression, alcoholism, suicide, and creativity, there is some hope:

Second, creative individuals score high on other characteristics that would seem to dampen the effects of any psychopathological symptoms. In particular, creators display high levels of ego strength and self-sufficiency (Barron, 1963; Cattell and Butcher, 1968). Accordingly, they can exert meta-cognitive control over their symptoms, taking advantage of bizarre thoughts, rather than having the bizarre thoughts take advantage of them. Furthermore, the capacity to exploit unusual ideas is supported by general intelligence. Although intelligence is not correlated with creativity in the upper levels of the intelligence distribution, a certain minimal level of intelligence is required for exceptional creativity (Simonton, 2000). That threshold level is in the gifted range, roughly equivalent to an IQ 120. Creators do not necessarily have genius-grade IQs, but they do have sufficient information processing power to select, develop, elaborate and refine original ideas into creative contributions.

And the article ends with some suggestions on how to treat creative individuals and maintain the edge that makes them create, without them sliding over it. Fascinating reading.

Educating UI Designers

In 2004, I gave a talk at UW about user interface design which consisted of a long wish-list for the education of future generations of UI designer colleagues. Some of it was based on conversations with junior colleagues at Adobe, including things they wished they'd been told or taught before getting into the field. Other items were based on my own cross-over from research to practice, and the sad gulf I see between the two. A few were based on my growing belief that design skill is the important frontier for education, hard though that may be to conquer.

The condensed form of the "please teach them" list includes this motley assortment:

Teach them… The Language of Business & Marketing instead of HCI & UCD; Teach Them… Product Design instead of Interface Design, If You Can; Teach Them… Usability Methods; Teach them… How to Determine Appropriate Study Methods; Teach Them… To Characterize their Customers; Teach them… To Identify and Characterize Problems; Teach them… To Review and Critique Designs; Teach Them… Different Kinds of “Design”; Teach them… Design for Multiple Devices; Teach Them… To do Fast Low-Fi Design; Teach Them… To Prepare Multiple Deliverables; Teach them… To Recognize the Value of Multiple Levels of Abstraction; Teach them… To Present Their Design Work; Teach them… To Find and Interpret Previous Research; Teach them… To Relate In-House Research to Design; Teach them… Justify without Defensiveness; Teach them… Software Development Lifecycle Models; Teach Them… How to Interview; Teach them… To Drive Projects; Teach them… Most Design Happens in Committees; Teach Them… Public Speaking; Teach them… To Study Their Own Organization; Teach them… To be Solid Experts but not Shrill Evangelists; Teach them… Organizational Planning; Teach them… To Know and Evaluate Books on Design; Teach them… The Difference Between Peers and Resources.

In case it's of interest, I've put my powerpoint slides up at Teaching UI Design and HCI. ("HCI" is a common label for the academic cross-disciplinary field of human-computer interaction, which usually includes usability and user interface design, as well as research and innovative interface engineering.)

Can Usability Scale Up?

At last week's CHI conference, there was a panel "debate" on usability that I didn't think entirely effective, in that it was Jared Spool being provocative and little interesting disagreement from Eric Schaffer of Human Factors International. But I did find it challenging and thought-provoking to hear Jared complain (yet again) about this stuff, so I'm recapping here.

Jared's contention is that usability departments don't scale -- hiring more usability professionals doesn't make for more usable products. He trots out dubious statistics about big name companies (MS) employing huge numbers of usability folks and still having very poor websites; and hotshot firms like Amazon with few or no usability staff producing famously usable, standards setting sites.

His points come down to these, from my summary notes:

1. More usability staff doesn't necessarily (or often?) equal better usability. (But his numbers from various companies were faulty, and people called him on this.)
2. Good usability often means good design culture, not good testing culture. More people doesn't mean good design.
3. ROI isn't calculated and monitored by usability departments; this is dangerous in riffing climates.
4. Are we an engineering discipline or a craft? We want to claim both and don't provide the mechanism and support for either for our profession. "Engineering" means standard skillsets and repeatable results; "craft" means some people are just better than others and portfolios matter.
5. Process quality in usability is important.
6. When usability is effective, are we effective because of our methods and skills and training, or because a company that hires us is thinking about new things and considering them at the same time and could do it just as well without us: customer needs and feedback, firm marketing goals, good beta testing feedback, design process, quality.

Item 2 is his most unexamined, unsupported point and yet the one I also agree with most. He's flippant about what "good design culture" entails and how it works. Yes, evaluation and design aren't the same thing, but they also aren't simply separable either. And good design itself is a complex and difficult issue in environments where employees have diverse skill sets, engineering compromises are required to make deadlines and marketing demands the impossible -- in short, where multiple stakeholders are responsible for implementing the many parts of a large system (who often disagree on the goals or the "design" to achieve them). Design is hard to do well, even in a company with supporting usability staff and cooperative players working in development and management. The cats all need to get along.

Item 4: He's just correct about this. But since design and evaluation are often practiced by the same professional, it's not clear we need to be either an engineering discipline or a craft and frankly we often have to be both. Not everyone is going to be good at both activities, though. And as an audience member said, it's certainly true that some engineers are better than others, and it's also true that at the architectural level of engineering, it's really design that's going on.

Item 6 is disturbing. I worry about this regularly, especially faced with teams that don't really need much help, for whom I'm kind of an expensive waste of company money. Where's the value add? At least I don't think my stone is magic, when it comes to testing products. Jared told the stone soup fairy tale, in which the soldier with the stone knows full well it's the vegetables that make it good, but coerces the townspeople into cooking, and then he moves on with his stone to the next town. Jared thinks usability engineers think they're really making good soup because of their magic stones, and aren't seeing the vegetables too.

prefuse: an interactive visualization toolkit

I saw a paper about this today, and wow, did it look cool. It's an open source toolkit for data visualizations written by Jeffrey Heer, with supporting publications co-authored by Stu Card and James Landay. The CHI paper today claimed it takes small numbers of lines of code to produce well-known network-style plots in the HCI literature. The toolkit sounds like it offers an API to a bunch of UI drawing functions, basically, with a kind of ad hoc programming language on top of it. They also claim a weakness with data handling (for i/o), but coincidentally I work with company that has that down pretty well plus having a pretty cool language of its own. I can't wait to see if I can get Matlab to talk to Prefuse functions.

Check it out: prefuse: an interactive visualization toolkit

GUI Developer Position

I'm pointing this opening out to folks of the Java and UI programming persuasion. It's a great team and a great product, and absolutely cutting edge stuff. The UI challenges are only getting more fun as it evolves (no, I really mean it -- there's a big "whoa, cool!" factor with every other functionality addition). I'd do it myself if I had any serious Java under my belt.

Anyone know anyone looking, in the Boston area or even elsewhere? Job ad here: Mathworks GUI Developer

Yahoo's UED Jobs

I keep tabs on jobs in my field as a way of feeling the pulse of the industry. They tell you a lot about the corporate situation and the company vision; and sometimes, if you read between the lines, you can tell how healthy their internal design and usability efforts are. Most of the hot industry jobs right now are interaction design or information architecture; there aren't that many strictly "usability evaluation" jobs now (this has been noted on a contracting mailing list I'm on as well). Except at Yahoo. They've got 36 jobs open in their User Experience Design category, which encompasses interaction design, visual design, web programming, and user research, which they are now calling "Design Research." I like this title, in that it focuses better on the deliverables and end-goal of research in usability.

Some of the key responsibilities for this role include:

• Responsible for the user research, including planning and running usability studies, benchmark studies, competitive evaluations, participatory design sessions, ethnographic field studies, user surveys, heuristic evaluations, and similar methods.
• Provide insight and vision for the team based on researching user needs. Convert research findings into actionable items.
• Collaborate with other research organizations within Yahoo! (market researchers and data mining analysts) in order to create comprehensive coordinated research.
• Synthesize research findings from other data sources (including market research and data mining) into meaningful recommendations and actionable items.

Their new corporate design mantra is "Life Engine," which you'll have to embrace to work there. It's all about integration of experience, in the face of Google's growing presence.

The VP position is most interesting and revealing (my commentary in brackets):

...A key goal for this position is to elevate the influence of the UE group to become a strategic resource. [Whoa: They aren't now. They're biting the bullet and making it a VP-level job--unless someone quit--because everyone in the industry knows user experience can't succeed as a priority without VP-level support--? But I'm a little surprised Yahoo feels this too; it must be Google nipping at their backside.]

...Ensure successful knowledge sharing and improve visual, functional, and conceptual consistency across products and components - oversee the development of design standards, guidelines, and best practices;  [Again, I always thought they were remarkably consistent and had this already. One ad says "new creative direction," so I suppose they're just worried about continuing and pulling deviant products into line.]

...Partner with Engineering on the development of new interface conventions and code libraries to ensure consistent and efficient deployment of design; [Ah, the crucial insight into why standards are hard to enforce -- the tools need to enforce them well, not a human post-design police force. This goes back to Don Norman in, like, the Stone Age, I think. But few places get it.]

....A professional manager with strong executive presence, credibility, and a reputation for unquestioned integrity and management skills that allow for instant credibility with business partners; Demonstrated ability to build strong relationships with and influence senior executives and internal clients; Degree in graphic design, human interface design, interaction design, computer science, or information design; advanced degree in these fields and/or MBA a plus. [I like this: Computer science counts too, and an MBA is an asset. And the rest: Whoever wrote this is pretty right on.]

Other places hiring widely now: Google (of course, and in multiple regions), Adobe (because of a small diaspora, I believe), Intuit (always hiring, very hard to please), Microsoft (ditto and hard to please the hiree, too), and a few design agencies like Razorfish, which is usually the best indicator that the industry is in an up-turn. You can check out the Yahoo UED job list at Yahoo! Find a Job.

Fast Company's Creativity Issue

This is a few month's old, but still worth linking to, I think.

Fast Company's December 2004 issue is on creativity and innovative companies. There's an in-depth and somewhat inevitable article on Microsoft Research, What Money Can't Buy: the gist seems to be that they spend more time and money being defensive, and innovating (i.e., sticking new features onto) their existing products rather than figuring out new arenas to conquer. That's a company that clearly delineates between research (the "creative" folks) and ordinary folks. They're likened to the telecoms in the 1990s, and it does sound a bit like the AT&T I remember -- who never wanted to develop on any idea not guaranteed to be an instant billion dollar market.

And there's a surprising, charming piece about W.L. Gore, the company that made Goretex and apparently Glide dental floss among other stupendous and profitable items. They, in contrast, have a non-hierarchical, team-based, inclusive approach to innovation. And, I'd add, a lot of equally clever marketing folks, who manage to break them into areas that are truly new for them, not just extensions of existing brands. Even into areas already flooded with big names. The article describes this difficulty with a few anecdotes about viral marketing among other tricks. They sound like a 3M, only even better.

Finally, a study on corporate creativity that debunks some myths about what makes people and cultures innovative (and here I've rewritten her myths to make them truths):

1. Creativity [Doesn't Only] Come From Creative Types
2. Money Is [Not] a Creativity Motivator
3. Time Pressure [Doesn't] Fuel Creativity
4. Fear [Does Not] Force Breakthroughs
5. Competition [Doesn't] Beat Collaboration
6. A Streamlined Organization Is [Not Necessarily] a Creative Organization

My favorite quote: "One day's happiness often predicts the next day's creativity."

Inventables

I'm home sick, but still capable of posting, so I'm dangerous today. I just checked in on the list of folks speaking at the conference I'd most like to attend some day (TED), and the guys who created this concept are on the list. It's like a mail-order entertainment kit for creative adults with spare time. A single "issue" is only $399! (cough)

Inventables :: New Materials & Technology Resource for Innovative Design.

Now what about a cheap version for kids? They get a random kit of stuff to play with each month, and a little pullout with ideas to spark them and their parents onwards...

HICSS: Persistent Conversation CFP

Some old colleagues and friends of mine run this annual conference mini-track in Hawaii at the New Year. The overall conference used to have a "boondoggle" kind of reputation but this has (I think) gradually changed as more and more good people got on the boondoggle bandwagon. This conference mini-track run by a linguist (Susan Herring) and a system designer (Tom Erickson) is a good example. Some of the more interesting work in what used to be called "computer-mediated communication" (design and data analysis) has shown up here over the years. I was once an invited discussant, and found it a good time all around, and that was when it was on Maui; it looks like it's only been improving over the years. (I might even submit something about LiveJournal, since I seem to have data from that survey now.)

So if you want to go hear an interesting interdisciplinary crowd of computer scientists, anthropologists, linguists, data vis experts, and more: HICSS39 Persistent Conversation CFP.

deviantART: Grid Game

A little flash game pointed out by Doug Orleans: deviantART: Grid Game by ~Fam. This is a cascading response grid game, in which tiles will interact if they are in the right configuration, and their motion will set off chain reactions as they get into proper configuration with other adjacent tiles. It's interesting to me in that it feels very "biological" and is hypnotic to watch as it self-organizes.

designboom: folding chairs through the ages

Another cool designboom item, this time an illustrated history of folding chairs. They go back to Egyptian times.

folding chairs through the ages

Modern design issues that weren't all touched on: portability to functions with cars or without, weather-related usage (I have garden chairs for summer I would never use anywhere else), size and height when unfolded (floor level is better for some activities), folded size, appearance and whether you can "fix" it with a cover or cushion, drink holder attachment, cost of course...

the kitchen is the heart of the home, the competition

But the heart is a little sterile looking, in the design competition winners from designboom. I love looking at these anyway, since this type of design is so far from anything I do daily. The entries feature concept mockups in gorgeous detail, philosophical position statements, and detail illustrations of the idea at work. The weirdest winner is the 2001 monolith style kitchen in which the entire kitchen is encased in a black block. Trendy types lounge in front of the block in plastic orange chairs and sunglasses. They aren't talking to each other. (Geez, I talk to my cats, when I lack humans, in my American kitchen where the appliances sit on the counter. And we're all pretty happy about it.)

The Black Block kitchen.

But all that said, the island design winner is pretty cool in concept. I just want to know why it all has to be chrome and black, instead of wood and bright paint.

kitchen is the heart of the home - designboom

Wristwatch of the Future

A bunch of folks from HP Bristol put together a really fun brainstorm design document: The Wristwatch of the Future, a series of concept sketches and descriptions of possible arm-accessories we could build 10 minutes into the future. Some of my favorites: the Webcam wristwatch (so I can see my cats and house from anywhere), the Landmark Reminders wristwatch, based perhaps on David Allen principles that to-do items belong in places as well as lists, and the Mood wristwatch. Imagine how useful it would be if everyone wore a mood indicator: the next meeting wouldn't require advance notice that so-and-so is in a lousy mood so you'd better not pitch that new idea or tug his/her chain today.

Complexity in Design 2005

I saw this once before and thought it interesting, but now that I've read it again (weeks later, after a glass of wine), I find it heart-rending. Here's an entire conference dedicated to both the customers of my company, and the employees at my company, many of whom used to be customers and now have to support other customers in their new role as software engineers: CiD: Complexity in Design 2005. Too bad it's in Glasgow in March (what were they thinking?).

For example, mechanical engineers must develop products that go faster, require less maintenance, use less raw materials than ever before. These demands are compounded by the increasing emphasis on mathematical modelling and simulation rather than destructive testing. Similarly, software engineers are being asked to develop systems that interact with these devices and with human operators. Increasingly the demands of developing safety-critical systems are being exacerbated by the need to produce `band-aid' software that addresses known problems in the underlying mechanical and materials engineering or that addresses underlying human factors problems in the usability of an application.

For instance, re-use simplifies many aspects of complex systems design. These techniques also carry important overheads; it can be hard to ensure that an implementation satisfies the intended requirements within its new context of use. This applies to software engineering just as it does to mechanical engineering. These comments may also, arguably, be applied to the reuse of design processes and teams. Similarly, risk assessment has been used to guide the development of many previous generations of complex systems. However, the increasing integration of large scale application processes and the inter-disciplinary nature of many engineering endeavours makes it hard to sustain this approach from individual component reliability up to the `systems' level.

Software Functional Specifications: What's the Point?

Well, I've become pretty opinionated on this one recently. It's been on my mind as I think about what constitutes good design, the role of usability, and the process of team problem solving.

Cutting away to a separate essay page this time, so you don't get spammed without asking for it.

Info Visualizations

A bunch of cool tools for doing visualizations of net stuff that I ripped out of Christina Wodtke's presentation on the importance of Information Architecture:

Grokker, a visual web data-mining thing involving zooming and paying money to use it; Newsmap (based on the treemap technique, applied to Google news--I like this one!); Kartoo, a visual meta search engine (I tried "MOO" and got a lot of bovine stuff; I'm not sure I immediately get the display's info intent).

thermotiles on designboom

This is really cool, and a good example of how materials can be slightly smarter without being "smart" with circuitry and brains. These thermal tiles won 2nd in a design competition sponsored by designboom.

thermotiles : "Thermotiles two-dimensionalize heating systems into a functional and graphic representation on the wall by silk-screening thermally conductive paste onto ceramic tiles. A copper spacing cross connects the metallic prints at the corners, continuing the circuit and therefore serving as an electrical and constructive element in the heating system."

Go check out their how-it-was-done page (p2) and their page of potential silkscreen designs (p3).

Ten Questions with TiVo's Director of User Experience

Just AFTER I did a talk on TiVo and quality at work, this appears in my blog reading list: The PVRBlog Interview: Ten Questions with TiVo's Director of User Experience, Margret Schmidt. Margret started after I left the first time (although I did work with her when I was contracting there 2 years ago); I'm relieved to see so much similarity in what she says and what I said in my talk at my company. At least most of my experiences look still "relevant" for the current TiVo. (FYI: I'm planning a web summary of my talk for posting here.)