I heard Barbara Brennan speak about being an exhibit designer with The National Air & Space Museum. She reinforced the same concepts that we use in software design as they apply to museum design:
- Know your audience. For her museum, the audience is huge: infants to elderly. She has the unique challenge of making an engaging user experience for foreigners who don't have a command of English. It makes up 40% of her audience.
- Know your best assets. They have planes, we have talent, design, and content.
- Focus on the user experience and the brand will take care of itself. Direct quote from Michael Bierut. Being part of the Smithsonian, they have a strong brand, but have never really leveraged it. They are only beginning to have these discussions.
More great stuff from Barbara. Will post later.
Great talks are the ones showing me a big personal problem I didn't realize I had. The best ones help me solve these problems.
Chalk up "Communication through the use of comics" in the best talks category. If you ever have the chance to see Kevin Cheng, interaction designer at Yahoo, give this talk, definitely go.
My career of writing, writing, and more writing
My life is all about documentation. In any given day, I'm facilitating meetings drilling on project scope (with a scope document written afterward), getting everyone up to speed on what I'm doing and what they should be doing (with the subsequent status mail), writing use cases (on a wiki), defining functional specifications for features (again, a wiki document), communicating what's going on in my head to others (this blog), while writing email after email about all kinds of crap. When I first tried to explain my job to my parents, I used the accurate albeit pithy explanation: "a lot of e-mail".
Information overload
It's impossible to read and digest the amount of text I churn out. But I can't stop writing documentation; it's a necessary and important part of my job. Eventually, every piece of documentation I write is useful to someone at sometime. It may be immediate, in the case of a spec point regarding how our geography disambiguation feature should work. It may be in the future, when the company tries to figure out the reasoning behind some decisions I made with a feature. Or it may be in the way future, to understand the baseline usability of our product and how far we have come. With so much documentation comes so many problems.
I've always have had issues with stakeholders reading the deluge of documentation I produce. Most of it they can skip (for now), but some of it is very important at this moment and quite pertinent to their jobs. Unless I go out of my way to make sure these stakeholders read the nuggets of wisdom, they won't expend the effort. I've come up with innovative tricks to overcome this in the past. For example, find the hidden misplaced sentence in the spec for a prize. But these tricks suggest there's a fundamental problem with the documentation, not the people reading it.
I've come to realize my documentation is unusable. Everything the business owner, developer, tester, manager, designer, sales person, account manager, and business developer need to know about a certain project is in my documentation and if they just sat down and read it all, we would all be fine. My initial reaction is to say, "It's their job to read it." That, however, is totally unfair. Until I read every piece of documentation these folks churn out, I refuse to say that. Or, there's "I can't make this any easier to understand." I don't think I could simplify my functional specifications any further without sacrificing quality. It's worse in the long run to have the highly readable but not-at-all actionable spec:
"Make it usable and pretty. Oh, and increase our conversions by 20%."
The solution?
It should also be noted, at the end of the day, I'm a user experience designer. It's my job to make things usable, fun, easy, accessible, and full of character. If I can't spend time trying making my internal deliverables to embody these characteristics, there's no hope for me as a UX designer, period.
I'm far from advocating throwing away all my documentation for some cute cartoons. But, as a scoping exercise and a high level view of the software's desired behaviors, cartoons is a universally understood tool that engages people and helps them to better understand the nuances to look for in the functional specification. Why wouldn't you do it?
Because you can't draw? Pssht. Not having a talent never stopped me from trying something new. I'll let you know how it goes.
Kevin's deck is located here. You should really go see him talk about this stuff instead. Really.
My first breakout session on Monday was around web content, with the pleasant title "Understanding your content". Here's a classic example of a disconnect avoided if I just read the fine print. I believed the session was going to be around user experience in content, developing voice, brand, and an identity. Here's what the session was actually about:
Content analysis is a core component of the information architect's toolkit. Content analysis is the examination of the content and features that make up a website. Through a content audit, or sampling of representative pieces of content, an information architect can understand the relationships, interdependencies and patterns that exist within the current content on the site. This process also allows the information architect to understand requirements and constraints inherent in the content. Content genres, or types, can be identified and used to create a content map of the site and site templates. The content map provides the basic building blocks for gap analysis, which maps user tasks with the content genres.
Reading any of the bold statements in this paragraph would have clued me in. Unfortunately, this is the first time I read this paragraph.
So, I went to an IA meeting about content analysis. I don't know much about the subject, so I can get something tangible and actionable out of this. WRONG! As it turns out, not only is the presentation not tailored to what I need, it's not detailed enough to enable action or doesn't cover any real-world examples deep enough to extrapolate anything meaningful. Oops.
I know ASD really needs a content audit badly. We have content sitting in probably 5 unique systems with unique tools to edit each one and unique quirks in the UX of these tools. It would be great to get all content under one big umbrella and sorted, organized, and processed into a taxonomy. I would need a lot more than this breakout session to start doing that.
I can only imagine those with IA backgrounds felt about this presentation. This must have told them exactly what they already knew. Do a content inventory first, move to the content audit, then build a content map, and finally do some content analysis. Each step, use either OmniGraffle or Excel to track everything and done.
Not much else to write. Nothing actionable, nothing immediately applicable. Just a general overview of how IA's do their job.
Google hosted a drinking party tonight at a bar for all the attendees of the UX Week 2006 conference. It was announced, during one of the sessions, that this is a recruiting party. BUT! It's not a free-for-all recruiting party for anyone interested. No, Google has a special list of people to talk to and will only talk to people off that list.
So not only was Google being cheesy hookers for recruiting at a conference, but they couldn't even bother to give the vast majority of conference attendees a chance to talk with them about job opportunities. Pathetic!
Was yours truly on the list? No.
Do I know how Google selects people for their list? No.
Am I jealous? Well, I would have liked to have been on the list.
Would I work for Google? No.
Best I wasn't on the list, as it turns out. I was really turned off at the whole spectacle towards the latter hours. After buying round after round of drinks, out come the shots. When a fellow conference attendee tried to shove a shot in my hand, I had just about enough and had to leave.
I never thought I would be offended by alcohol consumption. Huh. Must be growing up.
User experience is providing structure. What we do defines and helps people understand their daily lives. It is an ancient art and one vitally important to human existence.
I paraphrase a bit, but that opening statement is how this year's UX Week 2006, hosted by Adaptive Path, kicked off here in Washington D.C. I'm here for four days, basking in the glow of all things user experience: design, interaction flow, information architecture, usability, accessibility, color, brand ... the list goes on.
After each day, I promise a series of posts about user experience and the takeaways. This isn't as much for you as it is for me; I learn best from writing and re-writing key points.
If I had to make a checklist of things co-workers should never give me, because they drive me batty, Search Engine Optimization checklists would rank high.
Unfortunately, I never gave my co-workers such a list. So, when I walked into the office this morning, I had two sample Search Engine Optimization checklists sitting neatly on my keyboard. These lists are from some piece of internet dreck called Deliver First-Class Web Sites: 101 Essential Checklists by Shirley Kaiser.
Shirley, being a true expert in the web, realized no one in the technology industry has the attention span to read a book that isn't in list format and that she doesn't have the content to write more than a few hundred pithy statements about what makes a web site first class.
I have no problems with SEO and really no problems with checklists. Best practices have their place and a list reminding you what those best practices are is helpful. My problem is when best practices are elevated to essential checklists for first-class websites. I know plenty of folks that will shake their head at a feature implementation because it violated one of these sacred checklists. "You've violated rule #14 on good web design," the SEO checklist holder says. To which I reply, we are building a great user experience. I don't care if we violate rule #14 or any other rule for that matter, because building a great user experience trumps any rule.
Let me repeat that: building a great user experience trumps any rule. It's the one rule that puts a site like craigslist over SEO optimized classified ads. It's the rule that puts EBay way above any other auction site, even with their dynamic variable loaded URLs (Rule #22). They built brand. They built a cult. And there's no list that will beat brand and cult.
In typical, passive-agressive Seattle fashion, I made my own SEO checklist and wrote it on the company's whiteboard, so everyone who passes by the windowed conference room can see it. It reads:
Build great sites that people love.
And that's it.
