Sorry I haven't written in a while. I'll talk more about that in a future post.
Ask.com has come out with a new "experimental UI" called Ask X. While I appreciate the effort to differentiate from first-tier players, the focus on whiz-bang UI flies in the face of good user experience. Search engines should focus on relevance more than window dressing. But, if you're going to focus solely on the window dressing, have the common decency to put up some nice curtains, for crying out loud.
I seriously thought this was fake when it was sent to me.
Ask.com designers really need to understand the web landscape. I wonder how many of them use digg.com? What about 37signals software? I'm guessing few if any. Red to blue gradient? Bevel and embossing? It's gross and cheap looking. It feels more 1997 than 2007.
Ask.com executives: make some budget to allow designers to attend a UX conference. Or make your designers use brilliant leading edge websites like Vox, Threadless, Amazon's new gold box ...
Violating the Google Principle.
Regardless of the window dressing, search results brought back still aren't relevant. Instead of doing test searches I never do in real life (like "Seattle" or "wedding") I did some real searches (like "online mba" and "nicole richie dui".) Although the narrow and expand results are novel, I never find it vectoring me to more relevant results. I usually see the same links when I "narrow my search" or find a bunch of irrelevant cruft in "expand my results"
So, regardless of the window dressing, Ask.com hasn't won my heart or mind by achieving their core objective: helping me find what I need quickly. That's the search engine secret sauce, not some attempt at slick UI. Haven't we learned anything from Google, people?
I confess. The title of this post is strictly to inflame the Mac community into sending me hate mail. Please, feel free to barrage me with your naughty words! Post comments or write me at vox@ponyloaf.com.
Working at Microsoft in the home productivity software division taught me users were desperate for a simple-to-use money management software package. The Money team saw the opportunity and tried valiantly, with their Money 2005 suite of products, to nail this growing user segment. But Money was, is, and always shall be a heavy, over-architected, hard-to-use product. This is strictly by design. With a decade of legacy and a loyal user base used to features and functionality, pulling Money in the minimalist direction would take nothing short of a re-architecture. To scrap their product and start anew would spell disaster for their P&L.
So, when I saw a piece of Mac software trumpeted as a "slick new money management app," I was intrigued. Maybe they finally got easy money management nailed. The software, called Cha-Ching, is heralded on their website as "the fun and easy way to manage your cash." One of my co-workers went so far as to say, "I wish I had a Mac so I could run Cha-Ching." Oh, this must be the Quicken killer users have been waiting for! Cha-Ching will usher a bold new era of money management.
However, after using the application for 5 minutes, I realized Cha-Ching demonstrated everything wrong with modern Mac software. In the spirit of trite, easily digestible lists people seem to love these days, I'll give you the four reasons why Cha-Ching, and other vapid applications of its kind, is bad for the Mac.
1. Look! It's pretty!
Slick! New! Shiny! Look at those gradients! Wow, this really must be a fantastic money management application! I mean, it looks like it came straight from Cupertino. If it looks like a Mac, it must work like a Mac!
Why are Mac people drawn to reflections and gradients like moths to a flame? Misconception #1 regarding Good Design: a good graphic design begets a great user experience. Mac software seems to fall in this trap more often than web or Windows software and it's killing the platform's reputation. As people become more accustomed to great user experiences, Mac software and the Mac platform look more and more like candy-coated dung: pretty on the outside, but still a pile of crap.
Lesson #1: Make your Mac apps more than just prettiness.
2. Only $14.95 to find all of your bugs? I'll take two.
My initial visceral reaction, before ever using the software, was complete disgust for putting a trial period and a license structure in place for beta software. By definition, beta software is incomplete and buggy. Why are you compelling me to pay for it?
I believe this is an unfortunate misuse of the principals in Getting Real, the book written by amazingly productive 37signals folks regarding their software process. In this book, 37signals encourages you to have a bias towards action and releasing, so you can get software in the wild to see if and how well it works. They are all about rapid iteration and cutting feature sets down to size for your v1, v2, etc. Simplicity is king.
However, releasing a beta and timebombing it so I'm forced to pay you for your buggy software doesn't seem like the direction we should be going in software. So I have to pay to test it, now? Is that user-focused?
I have received comments saying my characterization of Cha-Ching's licensing is not fair; that, my reduced price license purchased during beta is a lifetime license, where you would get upgrades post-beta as well. And that I'm not being compelled to buy as much as "supporting [their] cause" (quoted from the Cha-Ching's website.)
First, the product is timebombed after 30 days. Betas should not compel you to pay for the product, period. Put an expiration date, requiring me to download the new version like Omni products do. But don't make me pay for it.
Second, as my friend isnoop so eloquently put it: "You just can't ignore the fact that the app sucks. That's like saying 'pay me $15 for a wet dog turd and we'll give you free flies for life!'"
Lesson #2: Charge for your Mac apps once they are valuable.
3. You can take pictures of your things!
In a misguided attempt to figure out other compelling user scenarios to put on their product website, the makers of Cha-Ching thought it would be pretty cool to take pictures of your things with your built in iSight camera.
At long last! A money manager that lets me take pictures of things while I make funny faces at my iSight with my little, ironic Nacho Libre mustache!
Why would I possibly want to take pictures of transactions I'm entering in a ledger? There are probably 100 other personal money management use cases I would have spent my effort on that would make a real difference in software quality rather than the easy-to-code iSight integration. Instead of Mac software developers creating a feature for the sake of putting it on the box or the website as yet another bullet point, why doesn't Mac software focus on what I want it to do?
If you must keep the photo feature because it's just so awesome, figure out compelling user scenarios that would be enabled by it. A home inventory system, perhaps?
Lesson #3: Make sure every feature in your Mac app is there for a good reason.
4. So, what does it do again?
This is the crux of my complaint about new Mac software and what I care about the most, being Mr. User Experience guy. There was little thought from the Cha-Ching developers about what people want to use a money manager for. The reason the Internet heralded Cha-Ching as the new hotness is because Quicken is so damn lame people were craving an easy-to-use money manager to kill it. However, no one wants an easy-to-use money management application that does nothing.
My only guess as to why this was released into the wild is because the 37signals way of developing software was brainwashed into these folks and they actually believed they had a solid beta. It's a real shame we're starting to see the simplicity pendulum swing too far to the no-features-for-$16.95 zone.
Lesson #4: Make sure your Mac app does something meaningful.
I just read a fantastic article on boston.com about the design and branding for The Evening News with Katie Couric. Lots of insight into the process of marketing and brand for something as conventional as the national evening news. It's also a good way for people outside of the industry to understand how much thought goes into every design decision for a tightly-controlled brand like Katie Couric.
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.
So, I received an invite to VOX and am intrigued by it. But I have this blog already, so you can understand the quandry. I've never been a two-blog kinda guy. (With exception to FTRS, but that doesn't really count.) I've decided that VOX will be my "professional" blog while LiveJournal will stay as my posting ground for random crap that comes to my head.
