Saturday, January 16, 2010

When is Bad Good?

I frequently give people conflicting advice in both my UX consulting and my UX Office Hours. What's right for one product is frequently wrong for another product.

Case in point: two people, one after another, one of whom I told that he should get rid of all his icons and use text, and the other who I told to get rid of all the text and use icons.

Person 1 had an interface where each icon appeared exactly once. All were cryptic. The icons needed to be large because they all represented complex functions, so there was no text with the icons (even if there had been, it would have been tiny). Better to use just text and lay things out neatly as in an on-screen menu.

Person 2 had an interface that included a monthly calendar. Inside the days, there were one- and two-word indicators that applied to the individual day. A small calendar filled with small words just becomes a big mess, hard to see what's going on. But, since there were only a half-dozen different things in the calendar, and each was easy to represent by a simple, highly recognizable icon, switching to icons would instantly make it less cluttered and more usable.

But, yesterday, I gave some advice I've never given to anyone before. For a commercial product, I told him his input format should be a text file.

Why? Well, his product has two classes of users, like many crowd-sourcing products. The millions (hopefully billions) of people who will flock to his site to use it, and the thousands (and hopefully millions in the long run) who will provide the content for the first group. Initially, the people in that second group is probably tens of people. Every bit of energy he spends on them is time he didn't spend on the group that matters more, the visitors.

Is there a risk? Certainly. There's always a risk, and we talked about how to minimize the risk by what the text file looks like and how it's used. And we did spend time talking about a design for a "v2" that would be a step up from the text file. But I think the risk of not shipping while trying to build the perfect product for the content providers, or even trying to build the v2 we talked about is greater. Shipping is about focus and, in this case, I think focus is about delivering the right product for the people that matter the most. If he hits his goals of billions of visitors and millions of people putting content up, then he'll have ample time for v2 and v3 of the content provider tool.

Friday, January 15, 2010

Enabling Experiences

Something great happened during my free UX Office Hours at StartPad yesterday.

Usually, I help people, then they go off and I never get to see what's happened. Occasionally, I see a product launch (like PicTranslator). The same is largely true in my consulting practice, though there have been a few notable exceptions with really big companies.

This isn't by accident. As you might expect with a UX consultant, it's by design.

I've noticed that many consultants see it as their job to make their job take longer. And many companies see consultants in that role -- they hire consultants to fill chairs. Instead, my number one goal as a consultant is to enable my client -- enable my client and then leave. We've all heard the old saw, with apologies to vegetarians, "Give someone a fish and they eat for a day; teach them to fish and they can eat for a lifetime." I want to enable my clients to build their product without me, rather than convince them that they can only build their product with me. It's probably not the business-savvy way to build a thriving consulting practice, but I sure feel better about it and I have happy clients.

Enabling is even more important when you only have an hour, which is what you can get for free in my monthly office hours. I can draw you a pretty picture or design some piece of your system, but then what?

Back to the great thing that happened yesterday.

A few months ago, somebody came in and asked me to critique the design he'd been working on. I told him to throw it out. Sounds harsh, I know, but it was completely wrong for what he wanted to do, the customers he wanted to serve, and how he hoped to enable them. I'll could go on. We spent most of the time talking about UX strategies that would work for his customers. I even drew some pictures on the whiteboard showing some examples.

Yesterday, he came back and showed me his new design. It bore almost no relationship to what he'd brought in earlier -- it was light years better. Honestly, it didn't look like the stuff I'd drawn on the whiteboard either. He learned something and then applied it, and he applied it in the way he thought made the most sense for his customers. I told him that he could ship with his design as-is and be ok. Yes, we could make it better (and we spent the hour discussing how to do that), and, yes, if he spent oodles of time on it (which I recommended against), he could make it way better, but the difference between the first and second versions was great to see, and it looks like he's on a good path.

It was one of those rare instances where I got to see what happened, and it felt pretty good.

Tomorrow, I'll write about another lesson from the same session: When is Bad Good?