But here’s an obvious question: shouldn’t the benchmark of a UX professional be happy users? Shouldn’t some metric of positive user experience be our benchmark instead of following some process exactly? What if we start optimizing for happy users over everything else? (we must make sure that happy users = happy business…but let’s for a moment assume that our business model is correct).
No process guarantees success. If there were a process that guaranteed happy users everyone would be using it. Nobody gets it right every time. Design doesn’t work like that. It’s iterative, responsive, ever-changing. You have to react as much as plan. You have to change your process on the fly to react to the marketplace. That’s why we need to optimize for what’s most important, a happy user, and do whatever it takes to make it happen, process be damned.
[side note: my professional tagline is “clear deliverables + an agile method. At your side to create happier users”, now i’m even more confident about this choice!]
Ship early, ship often, iterate and listen to all of the feedback. I think that if you have the courage to listen and the ability to take the feedback and iterate on your product, you will better off than waiting and trying to deliver something perfect. Imagining your product or project as a way of communicating with people and thinking of product development as a conversation might be one way to think about it.
The user experience is made up of all the interactions a person has with your brand, company, or organization. This may include interactions with your software, your web site, your call center, an advertisement, with a sticker on someone else’s computer, with a mobile application, with your Twitter account, with you over email, maybe even face-to-face. The sum total of these interactions over time is the user experience.
All of these touch-points are important parts of the larger system.
Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.
When you need help fleshing out the basic design, the deliverable can serve as a springboard for discussion… keeping the polish to a minimum can help: Participants may be unwilling to contribute if the deliverable looks like it contains fully realized ideas.
