Takeaways From UX Office Hours

I had my first User Experience Office Hours today at StartPad. The idea is that, once a month, I'll spend half a day helping whoever shows up with user experience issues. It's free and I don't get anything for it (in fact, if you count parking, it costs me). I'm doing it largely to give back to the community, but I'm not oblivious to the fact that my efforts might indirectly contribute to a future consulting gig or even a job. Even better, maybe I'll benefit because somebody else with skills that I don't have will step up and end up helping me in the future.

One interesting thing today was how different and how similar my four visitors today were. Because I didn't say I was going to blog about it, I'm going to have to omit the details this time around.

Two of the people had completely unpolished user interfaces and two people had user interfaces that were attractive already. The four products were in four completely separate areas with radically different user bases. Two were pretty early and two were getting ready to ship.

Three of the four shared a common problem -- they were doing more than one thing. Here's a good rule: Do one thing and do it really well. This is a good rule for UX in general -- focus your UI on what you want to enable for your users and make every part of your UI resolve around it. But, this is a particularly good rule for startups. You simply don't have the time or luxury to do two or more things.

Put another way, your startup is making a bet. What is that bet? Figure it out and go all in. Don't make two bets or five bets. If you believe that your widget is going to change the world, don't also build an anti-widget just in case you're wrong. That's a way to fail even if you're right.

Not surprisingly, all four really needed to understand their potential users better. This is an issue even at big companies. There are lots of techniques for this, but, fundamentally, they all boil down to this: if you were a user, what would you want? One guy's project is for use by experts in a particular domain. He didn't even know how lucky he is -- there is no UI easier to design than one that's for experts. Experts know the domain, so you don't have to explain anything to them. They're willing to learn your product if it makes them more efficient. If you're a developer, think what you want from your IDE. Raw speed. Same here. This doesn't mean you should make it ugly, but looks certainly aren't the high order bit.

In another case, a small company had built some really cool technology which integrates with software from a certain large company. But, they're trying so hard to fit in that they don't stand out. In a large sense, their company is predicated on the notion that the big piece of software isn't satisfying the needs of some users. I think they're right. Yet, their small product looks too much like the big product. In terms of the user interface, it's similar in more ways than it's different. And they need to be different -- if the big product isn't satisfying user needs, they need to be less like it, not more like it. They need to understand those dissatisfied users, figure out how what they've built will satisfy those users, and put that front and center. Unfortunately, it's hard work, so this problem was the one where I was the least helpful.

All in all, I think it went well. I learned a few things myself and I certainly hope my visitors found it useful. Future office hours will be on the third Thursday of the month, so that makes the next one Thursday, October 16th, from 2-6PM at StartPad. Maybe I'll see you there.