2 posts tagged “creative”
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.
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.
