User interviews are the key to understanding how users are going to work with the software that we build.
We’ve already spent time before the user interviews getting to know sort of the business needs of the organization that we’re working for. Now we need to take that information to the user. Whether it’s in the form of existing software or just a list of questions, and we need to understand hot the user is going to interact with the application that the business proposes to build. The only way to do that, sit down with a real live human being that fits out target user description and talk to them about it.
Andrew Ward says that somewhere between 75 and 90 percent of the time, software is actually a product of internal politics and pressures. In other words, how it works is not defined by a user, it’s defined by somebody internally who thinks it should work a certain way. I think as a software development partner it is up to us to bring ideas that are backed by fact to the table so that we can influence the development of the software in the correct direction.
It is important to understand your user before you start developing software so you understand how they interact with the software and what their pain points are. It also allows you to ask the questions to understand whether or not there are certain features that you should build in, and how you should handle those. It lets you get a feel for if they’ll be successful using the software.
Why you conduct user interviews is to help you understand and build a relationship with your users. This will help you make decisions about how you integrate you software and measure things. One of the great things about agile is that you’re actually building things in iterations, so you can get back in front of you user to make sure that things are the way you assumed and can make course corrections as needed. It also allows you to understand certain analytics that you might want to build into your system so that you can measure those. Whether it’s click-through rates or abandons, or how quickly people move through the application. This will allow you to better understand your user, and also continue to build that relationship so your software is successful.
The most effective way to do a user interview is to see the user in their element. You may not understand exactly how they interact with the software. Are they using it on a mobile device? Are they using it sitting at their desk? Do they have to be up and moving around? Getting them in their element and building that relationship with them is key to understanding how to work your software and to build a proper solution for them. Many times when you are just going by what your assumptions are, you don’t necessarily build the features that fit their needs. When you see them in their element you may actually understand that they’re doing something outside of what you’re building in the software that you can incorporate in as a new feature. Ultimately, seeing them in their element is a key piece to building successful software. You may learn something about how they interact with the software, do they wear gloves, are they working at their desk, are they up and moving about? How often, how much of their day is taken in front of this application? It will allow you to view them in their element, and allow you to see certain things they may be doing that you want to build into your application as a feature. It also allows you to judge how successful your application will be in making their day easier.
Tim mentioned that we’re trying to develop rapport with the user so while we’re not really trying to get them on our side, rather give them a level of comfort. We don’t really want the relationship to be where they’re trying to please us, because then we get all yes answers. “Yes, I love the way that works.” We really want that user to be critical, if we have existing software, of our processes. So what we try to do is be prepared, have our questions ready in advance, knowing that we’re going to go off script at some point, but at least have a foundation ready to go. The other important thing is to let the user know, as they’re using the software in front of us, that we’re not evaluating them and how they use the software, we’re evaluating the software. That’s probably the most important thing to let them know as we get started.