Don’t Just Build for Yourself

I like process and procedure. I didn't used to, and working with new designers it's often hard to persuade them it's worth it, but a project or two is usually enough to show them it works. We work with the client, gather information, interview users, codify everything, parse and organize it, and design systems that can be actually built and meet the needs of the identified user base.

Which is why I could not disagree with this blog post more if I tried. Oh, unless it's the much longer version this other guy posted which is where the first post came from.

One telling line from that post is:

For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.

Ah! See, like I mentioned above, there is a formal method to talk to users and gather information. And another thing a lot of people outside of UX don't get is that users lie. This is why we don't do focus groups. There are lots of other ways to get at what people do want, how they really use their existing products, and act in their life, etc. If you just ask them what they want, you'll build a product or feature they will continue to claim they want, right up till they do not use it.

And that's important when you get to the core idea these blogs brought up. Which is that you should trust yourself. I claim that you lie also. I know I do. The problem with focus groups and other preference-based surveys is that people are not trying to lie to researchers; they also lie to themselves. So you don't know what you want either. Really.

Back at Sprint our team decided to make our own "enterprise" software package. Okay, it wasn't for the enterprise, but it was internal software for a team of 40+ people. When announced, everyone ran back and made a list of desires, and developers started coding it. Then we assigned a team, interviewed each other, gathered data, etc. and designed it. Guess what? Totally not what had been coded and asked for by everyone, and in the end so exactly what was needed that everyone actually used it (unlike the enterprise software we were avoiding using by building this product).

Which is a good point. My products (usually) work great. I mean, they reduce calls to customer care, get good reviews from users on forums, improve customer satisfaction scores, increase the close rate by 250%, improve sales. Real, measurable results. And 90% of the features and design widgets I put into this work is distinctly not what I want for myself as a user. In fact, I don't use most of the consumer-oriented products I have built.

Whenever I rant like this a lot of the tech people I know get all upset with me, and take it to mean they can't do anything. Not at all. Developer input is important, software and database design are important phases, but user input is also an important phase. Just like a DBA can help you build the data store, user experience and usability folks can help you design what your customers actually need and use.

I’m right in line with you, even though UX is not my forte. A common quote that has been used “Don’t worry, I’ll give you what you need NOT what you asked for”. At first this is very offensive to people but after delivering effective solutions customers understand discussing the work/issues and not worrying about specifying a solution.

Try “Tuned In” if you want an easy read on this topic.