Steve Jobs once famously said he didn't run focus groups because in his view, customers couldn't know what they wanted until he showed it to them. In some sense, the same can be said for interviewing users about what they want in an app or a program.
Your users may have a vague sense of what they want. If it's search, you can be sure they want Google in the enterprise. If it's sync and share, they want Dropbox for the enterprise. But it's not always as simple as what they think they want.
Instead of asking your users, watch them as they do their jobs and you are going to learn so much more. See what they do in the course of their day and what it takes to do their job. What are they doing now manually or with clunky business software that you could simplify and make easier?
As you watch them, the answers might be right in front of you. Sarmad Salim, who is director of application design and mobility at drug company Sanofi, spoke about this at the CITE One-Day Forum last week in New York City.
"We typically start with the use case. We don't ask them what they want, we ask them what they do. You have to change how you define applications development. App developers used to be coders, but we had to hire people who know design."
He said after the application is released, they don't learn from the complaints nearly as much as they learn from watching the employees use the application on the job and see where the issues are. It's much easier to observe the problem than trying to tease it out of the users.
Brian Katz, who not coincidentally also works in mobility at Sanofi (and occasionally guest blogs for CITEworld), described a similar philosophy at the E2 Conference in Boston in June. He suggested going on ride-alongs where you follow the user around for the day and see how they use the app you so carefully designed. You would be surprised what you could learn.
He said he did this with one app designed for sales people that relied on having a solid connection to enter and retrieve information. The trouble was, as Sanofi is a drug company, salespeople were often on-site at a hospital where they prohibited cell phone use. Learning that was a huge eye-opener for Katz and his team and it allowed them to iterate in the next design to build the app so it was better suited to the way the users actually worked. If he hadn't ridden along he probably would have seen user stats showing they weren't using it very much, but he couldn't know why until he watched them.
Kevin Jones, another speaker at the CITE Forum, said it's about putting people at the center of the process. "One of the factors that will kill anything social or collaborative is to forget about the people. As technologists we forget that. We forget that people have to use it." Jones says when we stop listening to our users, we end up rolling out software and it doesn't get used --and we're surprised. He says all software projects are not about the technology so much as the people.
Simplify a process
CITE Forum speaker Scott Blanford, who is CTO for retirement and individual technology at TIAA-CREF, explained how his team looked at how customer service reps processed information. The reps had to cross 12 pages to build an entire picture of the customer, all the while trying to ascertain the customer's problem and find the information. It was a daunting task.
Blandford's team decided to simplify it and create what he called a Wikipedia-style page with all of the information in one place. Instead having to open and authenticate across multiple systems, the system built a single page from the various databases for the customer service person. It's so simple when you think about it and makes so much sense, but nobody had ever done it before because they accepted the old way as the standard way of doing business, warts and all.
"For us, the takeaway was think deeply how this problem would be solved by regular people outside the office, because home tools so outstrip what they have at work. If I was at home how would I do that and that's how we do it in the office," Blandford explained.
Blandford said once they deployed, he listened in on calls and they learned what had worked well and what didn't and iterated to make it better, redeploying the software quickly so users could take advantage of the changes.
Even after they improved the experience to the degree they did, users wanted it to open even faster. They had taken a process that took at a minimum 50 seconds before and reduced it to 12, which is pretty impressive. But once users felt the power of the new system, they wanted it faster -- after all, Wikipedia doesn't take 12 seconds to load. The team listened, investing in the engineering and reduced loading time to an almost negligible 4 seconds.
Listen, observe, iterate
You shouldn't really stop listening to your users, but the point is you aren't always going to hear from them exactly what they need. In some cases they may know, but in many they may not, or at least they won't be able to articulate it in a way that enables you to build a solution that really improves their working lives.
The best way to do that is go down on the floor or for a ride or wherever the employees who will be using the software work, and watch them and learn and put your expertise to work on the problem.
And most of all. remember that the app is never really done. You need to keep iterating, refining, and improving because needs change -- whether your customer is internal or external -- and what you did last week might not apply forever.