Pages

Monday, August 20, 2012

When Talking to Users Saves You Time

I mentor a few young designers, which is great, because not only do I know exactly who I want to hire when I’m building a team, but they also share interesting stories about their current companies.

I was speaking with one of them a couple of weeks ago, and she shared a story that sounded incredibly familiar. I think this happens to all designers who work with a sales force at some point.

 The designer, whom we will call Jane, is working on the user experience for an enterprise product for hiring managers. The product has some competitors that have been around for awhile.

One day, a few weeks back, the sales team came to the product team and said, “We need Feature X. All of our competitors have Feature X, and we’ve heard from some of our potential customers that they won’t buy us if we don’t have Feature X.”

 Jane and her team looked at the competition’s implementation of the feature, which had a lot of bells and whistles. The product team asked sales which parts of Feature X was most important to the potential customers. “All of it,” sales replied.

Jane’s team starting pushing back. This was not a simple feature. They estimated that it would take months to get the feature to be comparable with the competition. There was one part of Feature X in particular, the live video part, that Jane knew would be incredibly tough to design and build, simply because of all the implicit requirements that would make it useful. They explained this to the sales department, but the sales department continued to complain that they couldn’t do their jobs without Feature X.

Finally, Jane insisted on speaking directly with a customer. A meeting was lined up with a few representatives of the company. Jane started off by asking how the potential customer would use Feature X. They gave detailed explanations of exactly the places that they needed Feature X, none of which had been conveyed by the sales team.

Interestingly, none of the uses they had for Feature X involved the live video part of the feature that was worrying the product team. Finally, Jane came right out and said, “Tell us about live video. How do you feel about it.” The potential customers shrugged. “I guess it might be useful,” they said. Jane asked, “Would not having live video prevent you from buying our product if we had Feature X?” “Not at all,” the potential customers said.

Jane’s team then had a similar conversation with other customers and potential customers. The product team gladly put the much smaller Feature X, minus the expensive live video feature, onto their product roadmap. They also left out a few other parts of Feature X that didn't solve actual user problems, and created a design for Feature X that was significantly different from the competitors' versions but that addressed all the customers' issues.

Sales was happy because now they could tell potential customers that they were competitive on features. Jane was happy because she was able to quickly identify a real customer problem and solve it, rather than fighting with sales about something that would take too long to build and would include features the customers didn’t actually want.

 My prediction is that Jane’s version of Feature X is going to be significantly better than the competitors’ version, simply because it will only have the pieces that customers actually need and use.

The new feature won’t be made needlessly more complicated by bells and whistles that are only put there so that a sales person can check something off on a list. They’ll be put there because they solve a problem.