Friday, July 27, 2007

Managing Experience: Adaptive Path nails it

The folks at Adaptive Path recently announced their 2nd "MX conference", which focuses on, basically, how to actually get things done. In the announcement, they say:

The unsung heroes are those folks who shepherd projects through an organization, demonstrating the value of an experience design approach, ensuring that their product maintains quality in the face of competing priorities. Such shepherding is hard, but is necessary for design to succeed.

This is why we created the MX Conference. MX stands for Managing Experience. It exists to fill the void between the practical discussions craft, and the hand-wavey discussions of The Power Of Design. The event is focused on helping people understand what it takes to get great experiences out into the world, in the process building a community of folks addressing similar challenges.

Bravo! On this blog, I've touched on this topic a couple times (like here, here, and here). Basically I feel a sense of frustration that more thought and effort isn't spent on what I would consider to be the core issue that faces most user experience professionals - how difficult it is to get improvements into a product. We spend a lot of time talking about how to create a good design, and we do a lot of chest-thumping about how important good design is, but as the post above notes, there's a large void between these two.

Don't get me wrong. I think good design is hard. I think it's reasonable that this is a major topic of conversation. I think as a profession we still have plenty to learn in this space. In addition, I think it's obvious that we've got a long way to go in changing the default IT culture so that the importance of experience design is a foregone assumption - so some chest-thumping is warranted.

But in some sense those are the easy problems to solve. I am guessing there are lots of places that fit each of the following three criteria:

1. They have quality user experience professionals on staff

2. They have an organization that understands the importance of experience design

3. Getting actual improvements into the product requires navigating around 100 roadblocks and an Act of God

I think the reason more time isn't spent on this subject is that it's uncomfortably murky. The roadblocks aren't the same from organization to organization. It's not always clear who in an organization should be the shepherd. And, to be honest, I think there are user experience folks who feel that their job is to create quality design... and if that design doesn't make it into the product, they've still done their job.

But personally, I think a lot of the roadblocks are common (though not universal), and it would be good for the UX community to discuss techniques for getting around them. It won't be a one size fits all solution, but I think we have a lot to learn from each other here.

Thursday, July 26, 2007

UIE: Interview with Scott Berkun

UIE has posted a short interview with Scott Berkun, author of The Myths of Innovation, which I have reviewed previously.

The best part of the interview is Berkun's response when asked whether there are situations when teams should NOT focus on innovation. Berkun replies:

Yes! Thanks for asking! I think innovation is overrated. Customers don't care about how innovative you are. They just want to be happy and satisfied. And that's about good design.

The best advice I can give is to focus on people and their problems. Few great innovators worried about anything else. The fact that they found a new idea had more to do with their passion for solving someone's problem than anything else. Innovation is a huge distraction these days. That's one of the myths I hope people will understand how to dispel from reading the book or attending my seminars.

I thought this was great, because I've always felt there was something hokey when companies encourage innovation for the sake of innovation. Who cares about innovation if the innovation is useless? The trick is create a culture in which problems that don't seem to have an existing solution are seen as opportunities for innovation, rather than dead ends. It's all about problem solving.

Wednesday, July 25, 2007

Via Croc o' Lyle: If architects had to work like programmers

Croc o' Lyle points us to a great faux letter that was apparently created by Software Technology Support Center. The letter is a PDF, but I've cut-n-pasted it here for your reading convenience:

Dear Mr. Architect:
Please design and build me a house. I am not quite sure what I need, so let’s get started. My house should have between two and 45 bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I’ll make the final decision about what I want. Also, bring me the cost breakdowns for each configuration so I can arbitrarily pick one at a later time.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like insulated windows or composite siding. (If you choose not to use Anderson insulated windows, be prepared to explain you decision.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that the kitchen should accommodate (among other things) my 1952 Gibson refrigerator.

To assure that you are building the correct house for our entire family, you will need to contact each of my children and our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure you weigh all these options carefully and make recommendations. However, I retain the right to overrule any recommendation you make.

Please don’t bother me with small details right now. Your job is to develop the overall plans for the house and get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpeting; however, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It should — therefore appeal to a wide variety of potential buyers. Please make sure, before you finalize the plans, that there is a consensus of the potential home buyers in my area that they like the features of this house.

I advise you to run up and look at the house my neighbor built last year, as we like it a great deal. It has many things that we feel we need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe you can design this into our new house without impacting the construction cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction cost as a result of later design changes.

You must be thrilled to be working on such an interesting project! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your ideas and completed plans.

The Client

PS: My wife just told me she disagrees with many of the instructions I have given you in this letter. As the architect, it is your responsibility to resolve these differences. I have tried in the past and have failed to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.

I think the part about the 1952 Gibson refrigerator is my favorite.

Wednesday, July 18, 2007

Todd Wilkens: Why usability is a path to failure

Todd Wilkens of Adaptive Path expressed some frustration about usability:

When talking of a great writer, how often do people talk about how amazingly legible they are? When talking about a great photographer, does anyone ever talk about the fact that his prints actually developed and thus are visible? Obviously, the answer is no. Legibility and visibility are the bare minimum of requirements for a successful piece of writing or a photograph. Any person who focused most of their efforts on legibility or visibility would probably have almost no chance of being a successful artist. Something that is fundamental to great creative acts is aiming high. If your goals and strategies are not oriented toward excellence then it is highly unlikely that your tactics will get you there. No one tells their kids to aim for a C- and then expects them to get an A.

So, why oh why do people in this day age still hold up “usability” as something laudable in product and service design? Praising usability is like giving me a gold star for remembering that I have to put each leg in a *different* place in my pants to put them on. (Admittedly, I *do* give my 2 year old daughter a gold star for this but then she’s 2.) Usability is not a strategy for design success. The efficiency you create in your interface will be copied almost instantaneously by your competitors. Recently, I’m even coming to believe that focusing on usability is actually a path to failure. Usability is too low level, too focused on minutia. It can’t compel people to be interested in interacting with your product or service. It can’t make you compelling or really differentiate you from other organizations. Or put another way, there’s only so far you can get by streamlining the shopping cart on your website.

Obviously this can lead to a religious terminology war, but for the purpose of this post I'm going to assume that Todd defines usability as "making sure that users can complete their tasks with a reasonably low failure rate"... and nothing else. Of course, I agree with Todd that this is just the beginning of designing a quality product, but I think perhaps he's not giving usability enough credit. Here's why:

1. I think it's nearly impossible for an organization to successfully focus on other aspects of experience without first becoming (at least) competent in basic usability. It's a step that can't be skipped, for all practical purposes. So an organization that went from nothing to doing basic usability should be praised for making progress, because they couldn't have chosen to go beyond basic usability in step one anyway.

2. Great artists break the rules... but great artists know the rules. If an artist creates a masterpiece by breaking rules that the artist didn't know about, it isn't genius, it's luck. In some sense, basic usability means "knowing the rules". For example, whenever we talk about the value of consistency in my job, I always make the point - it's okay to not be consistent, as long as the inconsistency isn't done out of ignorance, but by design. Usability is the foundation for everything else.

3. And last but not least... usability is HARD. Look around. We're surrounded by unusable crap. (I was editing a wiki page today and my username timed out while I was editing, so when I tried to save, it prompted me for my id and password, then took me back to the wiki homepage and threw away my work!) There are many, many roadblocks to creating a product that is usable in even the most basic sense. Kudos to the ones that achieve it. Is it enough? No, but for most teams it's a praiseworthy first step.

Tuesday, July 17, 2007

Post-vacation roundup

After a long weekend of taking my son to the Smithsonian Institute for his 9th birthday, here's a few of the things I missed while I was out:

  • Adam Polansky has an article on Boxes and Arrows about "Faceted Feature Analysis", which is basically a way to prioritize feature requirements in a way that takes ego out of the mix.
  • A discussion of Charlie Card usability problems at Compete on Usability - as if we don't have enough problems getting people to use mass transit in this country.
  • Bokardo has a discussion on why the Netflix site is so good - which I agree with completely. I've been sticking with Netflix for longer than I probably should because a) Blockbuster is evil, and b) I love the Netflix app.
  • Jeffrey Veen tells an interesting tale of how design inspiration can come from strange places - like Raiders of the Lost Ark - and why you should sleep with your laptop.

Monday, July 9, 2007

Kudos to Yahoo! Photos

Yahoo! Photos is closing. I got an email from them over the weekend. Here's a section of it:

We will officially close Yahoo! Photos on Thursday, September 20, 2007, at 9 p.m. PDT. Until then, we are offering you the opportunity to move to another photo sharing service (Flickr, KODAK Gallery, Shutterfly, Snapfish, or Photobucket), download your original-resolution photos back to your computer, or buy an archive CD from our featured partner (for users of the New Yahoo! Photos only). All you need to do is tell us what to do with your photos before we close, after which any photos remaining on Yahoo! Photos will be deleted and no longer accessible.

Of course, we hope you'll join us at Flickr (you can even use your Yahoo! ID), but we also realize that Flickr may not be for everyone. In the end, we want you to find the service that's right for you, and we hope you take some time to learn more about your options before making this important decision.

That's an exceptional marketing move - give people the option of automatically migrating to a non-Yahoo!-owned photo service. Forcing everyone to migrate to Flickr would have been the easy thing to do, but this is smarter. People like choices, and there will be people who are angry that Yahoo! Photos is shutting down and forcing them to change services. By giving them a choice of services for migration, Yahoo! gets their Miracle on 34th Street moment instead of bad press.

Nicely done.

Nielson: bad blogs

Nielson on good articles, shallow blogs. Me no likey. Think Nielson misses point. Will write more after I find my crayons.

The little deviants

I took the kids to see Fantastic Four: Rise of the Silver Surfer yesterday. In the commercials before the movie, there was this:

So the commercial has demons living in the sewers who emerge to attack the "sheeple". The demons decapitate the sheeple, play with the decapitated heads, slip into the skin of the sheeple, and, apparently, customize their cars. The demons are the good guys in the commercial. My 8-year old son had nightmares last night from that commercial... seriously. And the worst part is, I bet Scion would be happy to hear that. This reminded me of another recent commercial, where a cellphone company was trying to sell a new feature that, I guess, allows to text message multiple friends at a time. What should you do with this feature? Apparently arrange so that you and your friends can all simultaneously vandalize a grocery store. Again, the people doing the vandalizing are the good guys in the commercial. The target audience. This is not trend I'm happy about.

Compare that to this Liberty Mutual commercial:

How do you want your company to advertise?

Tuesday, July 3, 2007

UIE: "Ten Ways to Kill Good Design" by Kim Goodwin

UIE has an excellent article from Kim Goodwin called, "Ten Ways to Kill Good Design". I don't have much to add, other than, "Yeah, what she said!" In particular, she nails one of my pet peeves - developers making business decisions. She says:

When we say the inmates are running the asylum, it means the programmers are making business decisions that should be made by executives. In most cases it's not intentional, and the majority of people are unaware of the extent to which it happens. However, every time a programmer says "That's not technically feasible," he's just made a business decision that's invisible to most people, since "not technically feasible" really means "not in the tiny amount of time or with the constraints I know you're going to give me."
I have an enormous amount of empathy for developers. They often have unreasonably huge amounts of work to do and unreasonably tiny amounts of time to do it in. But when a requirement is in plan and then the developer guts half the requirement by saying "no" to designing it well, that's a business decision that needs to be made somewhere else.