My favorite part of User Experience is talking with the people who actually have to use the product. Because our projects are often commissioned by people very far up the org chart, the day-to-day users are often people who are not invited to the project or design meetings. I have learned that if we can produce a product that makes the actual end-user happy, we will make the managers and administrators happy. Why? Because they don’t have to listen to complaints, they notice increased efficiency, and they see happier students and staff.
My personal preference is to meet with users one-on-one. Focus groups can be good, but one of their weaknesses is that they tend to discuss the product in general or theoretical terms. Additionally, strong personalities can really sway focus group discussions. One-on-one meetings with users allow researchers to discuss specific use cases, problems, and desired solutions. During one-on-one meetings, you can also observe the user interacting with the product, which can lead to additional insights about the user experience that the user may not be aware of.
User experience research is more accurate if it is conducted in the environment of the user. For example, watching the BYU employee at their desk or observing the student on their laptop in the Wilk are more effective than having them use a product in a different environment. Here at OIT, we often develop with 2 or even 3 large screens. That experience is different from the experience of a clerical worker who works on one old, small screen or a student who works on a laptop or mobile device. Knowing who our users are and learning what devices they prefer to use should inform our design. Observing the distractions and pressures around our users should help us empathize with their experience.
By now, we all know that mobile design is essential. Students are very tech savvy in their feedback to our frequent surveys related to the BYU Mobile App. They often say things like “We don’t want responsive. We want native.” When we ask follow-up questions, they say that they don’t want a large screen shrunk down, but rather easy-to-navigate screens that allow them to perform tasks. So, we must consider mobile to be the actual environment of most of our users.
Prior to meeting with a user, I like to send a list of questions so that the user has time to ponder the functionality of the product. Here are some examples of questions I might send to an employee:
- What work or business process do you need to accomplish with the product?
- What makes you crazy about your current product or manual process?
- What type of work-arounds do you use? Examples of work-arounds are: post-it notes, lists that you tape to your computer, things that you have to remember in your head, or tasks you have to do manually because the product can’t handle them.
- Sometimes products have fields that you don’t use and you end up tabbing through them to get to the useful data. What fields seem to be useless in your day-to-day use of the product?
- In what order do you think data should be entered into the system?
- What kinds of reports do you need?
By writing the questions in a conversational tone, I hope to set the user at ease and show them that I am really interested in what they have to say and how they feel about the product.
Ideally, I’d like the user to show me their existing product and have them narrate their experience. I want to watch them click around. This sometimes elicits some very passionate comments and even tears! User experience is empathy, and when we consider that students and staff often use the same program over and over, we can’t dismiss problems as quirks or bugs. An office worker on campus may use our product all day long and a “minor” bug that we detect in our short-term testing can annoy them repeatedly throughout their workday. We don’t want to make their jobs harder. We want them to be delighted with the tools we create for them because they make their lives easier.
When I begin the interview, I ask the user to answer the previously forwarded questions. It’s a great way to demonstrate my genuine interest in their experience, rather than starting with my comments or impressions. As the user describes their experience, I try to ask clarifying questions, often using a large piece of paper to map out their business processes or the flow of data. It’s very productive to do a paper prototype. I like to take 8 or 10 sheets of 11” x 17” paper and some markers and offer them to the user. By allowing them to physically draw out their problems and ideas, we get better clarity. Paper is cheap and we can work through a lot of issues well before presenting the design requirements to the engineers.
OIT’s focus on user experience extends to non-app experiences. Many teams already implement UX principles in their non-app projects, and we want to encourage more of that. A few years ago, I toured the new medical facility. They were very proud to say that their architectural plans were based on input from employees and patients. They explained that they had observed the nurses bending over all day to plug and unplug equipment. The nurses asked for the electrical outlets to be placed waist high so that they didn’t have to bend over so much. Asking a question about ease of use or “what annoys you?” really does expose user experience issues.
By involving our campus customers and end-users, we make them our partners. Asking for input from users and customers demonstrates respect and wisdom because shared decision-making prevents conflict later in the process. It also generates good design based on solid research and that saves time and money.
There is great satisfaction in delivering a great user experience. Here at BYU, we aren’t tracking sales or conversion rates on our products. The best measure of our success is in reduced frustration, fewer calls to the service desk, and the perception by our customers that OIT cares about their experience.