4 posts tagged “2006”

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:

1. 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.
2. Know your best assets.  They have planes, we have talent, design, and content.
3. 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's true, I can't make my documents any easier with words.  But this idea of using cartoons to express complex software interactions and desired user emotions for one set of documentation in the scoping process -- that's something I feel my team can get around to reading.

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.

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.