Chapter 3. Working with Users
“Coming together is a beginning. Keeping together is progress. Working together is success.”
I realize that involving users can be a scary thing. Let’s face it: users have a tendency to muddy up our development processes; they don’t understand what’s required to build an application; and most of the time they have no idea what they’re asking for. Sometimes, their requests are unrealistic and unhelpful. How could they possibly lead us to any sort of meaningful breakthrough on a software project?
It’s becoming increasingly clear that the job of a developer exceeds the realm of writing code. We have to be more attuned to our users’ needs, and the only way to do that is to spend time with them. We have to constructively guide our users so they provide us with (whether they realize it or not) the information we need to make a successful application.
This requires us to do more listening by remaining observant and inquisitive.
What If I Don’t Have Access to Users?
Many of you could be reading this and thinking to yourself, “I don’t have a group of users that I’m directly working with.” Maybe you’re building something for the mass market, like a smartphone application or website. If that’s the case, you may be confused when I start talking about engaging users and actively working with them.
Here’s my advice: if you’re not building an application for a specific client or group of users, then I’d encourage you to find some. Perhaps this seems obvious, but I’ve seen many developers set out to build an application assuming, if they just build it, users will come. These developers put very little effort into understanding whom those users might be and what their needs are.
At the end of the day, the application you’re building should be serving someone. The trick is finding people that personify who that someone is. I find social networks like Twitter and Facebook are great ways to find friends or family willing to offer feedback or answer questions.
Granted, the process is not as straightforward as building an application for a client or in an enterprise environment, but the principles of user-centered design still hold true. The key is making sure users are involved, at some level, in your software design choices. This is the best way to ensure you’re building an application people want and need.
Some developers might limit their interaction with users and choose to go with their gut. To a certain extent this is admirable, but it’s not the most effective way to make decisions about your application’s design. That’s not to say there hasn’t been evidence of developers using their own intuition to make successful products. We’ve seen countless examples of developers who have pioneered revolutionary software and services, simply by having the foresight and intuition to decide what was needed. They didn’t need a focus group or extensive market study. They just knew that the application should be built.
I’ve revised a quote from Steve Furtick, pastor of the Elevation church in North Carolina, and I think it best qualifies my response. Don’t compare someone’s highlight reel to your behind-the-scenes video.
In other words, it’s easy to look at products like Google, Facebook, Twitter, Amazon, Groupon, (and on and on) and think that creating software is all about the big idea. We mistakenly believe that, like Newton, an apple fell from a tree and plunked these developers on their heads, magically ushering in a digital revolution. So I see developers waiting for the apple to hit them, too, and I think to myself, “You know, if they just spent some time with people, they’d probably get there faster.”
If we’ve seen only the high points of someone’s application and none of the mistakes, it’s easy for us to believe the developer just happened on a great idea.
Leonardo da Vinci, for instance, had notebooks full of sketches and drawings for his final work on The Last Supper. He didn’t just sit down one day and paint his masterpiece. He spent years sketching, erasing, and redrawing different ideas and concepts, as is depicted in Figure 3-1. Most of us aren’t even aware of these early sketches; all we hear about is the final painting that has been adored by millions.
So the point is this: don’t mistake the process of creating a user-centered application as a straight line from A to B. It can take years of observation and study to lead you to your breakthrough moment. Your process should be a curvy line from A to B to E, back to A, and moved so many times you lose track.
If you’re willing to spend time asking questions, being curious about the world around you, and observing user behavior, you increase your chances of gaining insight. Over time, that insight will expand your intuition and, quite possibly, lead you to a successful product.
Knowing When to Listen to Users and When to Not
Just because I’m suggesting that we listen to users does not mean that we should listen to everything they tell us. This is not like the retail experience where the customer is always right. Most users have no idea how technology works. They don’t know what’s possible or impossible. Sometimes their ideas are just plain crazy; however, if they are carefully guided, their knowledge can be extremely valuable. At the end of the day, we need to learn what to hold onto and what to throw out.
One morning, I was walking by a visitor kiosk I had built for our front lobby. The kiosk allowed our visitors to locate the patients they were visiting within the hospital. It also had locations of various points of interest. I saw a woman and her daughter using the kiosk and decided to use the opportunity to question the woman about her experience”
“Hi, my name is Travis. I work here at the hospital. I was wondering if you were able to use the kiosk OK.”
“Oh yes! I mean, my daughter had to help me at first, but I think it’s really cool!”
“Great; were you able to locate the patient OK?”
“Yes. We found my dad. You know what would be great? If the tiles in the floor lit up and took us where we could find him!”
Now, this may shock you, but I wasn’t able to create a system that caused the floor to light up. Frankly, if I could do that, I’d probably be living on a beach somewhere collecting my millions. This was a ludicrous idea. Clearly the woman had no idea how technology worked or what I was capable of delivering.
However, she had touched on an interesting problem. It’s difficult for users to take information from a computer directory and translate it to the world around them. In other words, I was presenting the room number and floor, but there needed to be a clear indication of where to go next.
Throughout the development, I had already anticipated this problem and created a series of animations using dots and a map of the floor. Much like her idea of a light-up floor, these animations, shown in Figure 3-2, lead the visitor to the nearest elevator.
Therefore, this woman’s outrageous request had validated my earlier assumptions and caused me to reflect on the value of the animations. Sure, the floor wasn’t lighting up, but a map with animated dots was the next best thing.
What most users provide is the understanding of their own workflows. It’s up to you to explain how you can augment those workflows with your programming skills. It’ll be your job to educate them and bring them into your process. Teach them the right terminology so they can adequately explain their needs.
Through active listening and coaching, you can guide users into giving you the information you’re looking for. You have to ask the right questions, and if you’re not getting what you need, you have to ask them a different way. Be persistent.
In the past, I’ve spent 30 minutes on just one question to ensure I’ve received the proper information. If a user is giving me something I don’t need, I’ll politely explain how that information doesn’t help. If a user is explaining something I don’t understand, I’ll tell her. I don’t hide the fact that I have no idea how her task or process works. When I let my guard down and admit that I don’t have all the answers, not only does it take the pressure off me, but it also makes me more relatable to the user.
In Observing the User Experience (Morgan Kaufmann), author Mike Kuniavsky describes this as the master/apprentice model. In this model, you treat the user as the master craftswoman who is focused on providing you all the necessary details of what she’s doing.
This is particularly useful in jobs or industries that you’re unfamiliar with. If you were building a scheduling application for a veterinarian’s office, it would make sense to have you shadow the office receptionist.
I encounter this at the hospital all the time. As much as I might wish I was a doctor, even after all these years, I still don’t have enough terminology to star as an extra in Grey’s Anatomy. Every day, I’m learning new workflows, acronyms (so many acronyms), or services our hospital provides. I’m never too shy to admit I don’t know what a user is talking about. Through a series of questioning, I’ll get her to describe her workflow in a way I can understand.
I think programmers often come with a stigma of being all-knowing or beyond normal intelligence. Users can sometimes feel intimidated. A great way to open them up is to be the first to admit you need help. This puts users in the right frame of mind. They’re the ones with the answers, not you. Their job is to help you learn what they do so you can build a better product for them. That’s how user-centered design works!
Dealing with Different Types of Users
There’s no one solution to help you get the information you need from users. Each person has a different way of tackling problems. You have to be flexible and willing to adapt to differing approaches and styles. Here are some common personality types I’ve come across:
The Information Overloader
These users like to give you information—a lot of information. They’ll come to meetings with stacks of papers and memos. They’ll copy you on emails with long threads, giving you no context as to why you’ve been included. They’ll explain the entire history of their process with great detail and even include a story about their first vacation to Hawaii. They’ll give you copies of notes they’ve taken from every meeting they’ve ever attended. They’ll call you about an idea for version 2, even though you haven’t started building version 1. Their heart is in the right place, but they don’t understand that you can’t keep up with the amount of information they’re giving you.
The challenge with these types of users is that you don’t want to discourage them. If the problem is that they’re giving you too much information then, in reality, that’s a great problem to have! With that said, you have to set boundaries for the information you’ll consider. Coach them in the proper ways to communicate with you.
If you’d rather not receive phone calls, let them know it would be best to communicate nonurgent items over email. If they’re still calling, let them go to voice mail. Then, politely and promptly, respond to their message with an email. This is a great way to coach them into using the preferred forms of communication.
If they want to start talking about the next version, explain to them the importance of staying focused on the current version. These types of users have a tendency to get ahead of themselves, so continually bring them back to the task at hand.
I find that providing status updates via email is a great way to remind them of what you’re focusing on. I create recurring calendar appointments to make sure I’m continually providing users updated information about their projects. This is a more proactive approach where I’m contacting them before they feel the need to check in with me. It also helps to schedule time to stop and reflect on what’s been accomplished and what still needs to be done.
Most likely, users’ willingness to help is a result of just being excited. They’re finally getting help, and they want to make sure you have everything you need. As my father-in-law says, “Sometimes, you have to let them get their words out.” Be patient with them and try to be thankful they’re willing to provide information. Remember, at the end of the day, they’re your customers, and they should be respected accordingly.
The Control Freak
Control Freaks want to be involved in every decision on the project. They exert their presence in meetings and will often derail presentations or discussions. They’ll complain when they don’t run things or when the group decides to go in a different direction. In short, these users want to be the ones calling the shots. They want to tell you how it’s all going to be done.
My experience is that the need for control comes from a sense of insecurity. If you’re willing, try to get to the center of what they’re concerned about. You might try having a private meeting and let them know what you’re trying to achieve. Remind them that your desire is to make the best application possible. Give them examples of how they can help you and remind them that you’re on the same team!
Choose your battles and let them make decisions on things that have little impact. Also, it’s best to present choices before letting them decide. By limiting their options, you can minimize their overall influence.
Sometimes they just want to feel included and respected. Make sure to prompt them for their opinion during meetings and politely move on when things get off track. Your job is to make sure you hear from everyone. Don’t be afraid to mediate during meetings if one person is taking over.
More often than not, these users end up being your best allies because they can be incredibly knowledgeable. At the hospital, we have special users we refer to as super users. These are folks who we partner with to achieve better outcomes. If you build applications for the mass market, think about establishing a beta program where some of your more vocal users can use unreleased or test versions of your product.
For the super user, the role may come with additional responsibilities and a greater expectation of involvement. I find that this elevation of engagement works very well for this type of personality.
Unlike the master/apprentice model, this is referred to as the partnership model. These users have the ability to examine their own (or others’) usability behaviors and make assessments on what may be needed. Rather than just being another user to be observed, they can actually help in developing and implementing your user-centered design strategy. Because they are more intimately involved in the outcome of the process, you may find that they back off and become more of a team player.
The Devil’s Advocate
“We’ve already tried that.”
“If you change the menu, no one will use it!”
Devil’s Advocates have a hard time coming up with their own ideas, but they’ll gladly tell you why yours won’t work. By playing the role of the Devil’s Advocate, it allows them to tear apart your idea while not being the bad guy. After all, it’s not them saying it. They’re just advocating on behalf of the Devil.
In The Ten Faces of Innovation: IDEO’s Strategies for Beating the Devil’s Advocate and Driving Creativity Throughout Your Organization (Doubleday), author Tom Kelley explains how to encourage more constructive personalities on your team and minimize the effect of the Devil’s Advocate.
By giving users (or team members) detailed roles to play, you’re empowering them to participate in a specific way. Each persona is responsible for an aspect of the creative process.
For example, the role of the Anthropologist is responsible for observing human behaviors and reporting back to the group. The Experimenter tests new ideas and validates assumptions. The Cross-Pollinator explores other industries and cultures and then translates her findings into new insights.
You may have people on your team who naturally fit these personas, or you might have to employ one person to fill many personas. The key to Kelley’s model is giving each member a defined character or role to play. Each person will then have a responsibility to represent her view from the perspective of her role. Therefore, it makes less sense for someone to be against an idea, simply because she’s playing the role of someone who disagrees. That role just doesn’t exist. The Devil’s Advocate becomes marginalized by the stronger points of view.
In his book, Kelley details the roles and responsibilities of each of the ten personas and, although they might not completely eliminate the Devil’s Advocate, they certainly help. After all, it’s not the person who is disagreeing with the Devil’s Advocate; it’s the persona she’s been given:
The Devil’s Advocate may never go away, but the ten personas can keep him in his place. Or tell him to go to hell.
So, instead of hearing, “Let me play the Devil’s Advocate for a minute; if we change the menu system, our users will be confused and frustrated,” you’ll hear, “Let me play the Anthropologist for a minute. I’ve been watching our users with the current menu system, and they’re already confused and frustrated!”
Dealing with Negativity
Working with users isn’t always easy, especially if they want to focus only on what’s wrong. Developers are required to have a thick skin: you can’t be in this business if you refuse to be criticized. However, we have to admit that negativity reduces our morale and motivation.
Our job is to remain optimistic. We have to have faith that we can provide the solution our users need. We must believe the answer is waiting to be discovered, and with enough persistence, we can uncover it. That’s not to say that we should be delusional or unrealistic, but I think we have to actively work against the negative mindset.
To be honest, it’s much easier to make a list of what’s going wrong than what’s going right. We’re kind of wired to think that way. As developers, part of our job is to focus on errors in our code and processes that aren’t working. We search and root out failure by eliminating bugs. Unfortunately, we end up applying the same focus to every situation by mistaking a problem as a collection of bugs to be fixed. In turn, we become hyper-focused on what’s not working.
Instead, we might consider taking time to actively look at what is working.
Let me be clear. I’m not suggesting that looking for mistakes is a bad thing. We should always remain focused on finding errors or things that aren’t working. It’s essential to the software development process. However, I think we can balance our time to include the evaluation of things that are working. There’s a lot to learn from our mistakes, but there’s a lot we can learn from our successes, too.
In the book Switch: How to Change Things When Change is Hard (Crown Business), authors Chip and Dan Heath refer to this shift in focus as “finding the bright spots.” Essentially, they believe that motivation and change come from focusing on what’s working and not what’s failing:
Imagine a world in which you experienced a rush of gratitude every single time you flipped a light switch and the room lit up. Imagine a world in which after a husband forgot his wife’s birthday, she gave him a big kiss and said, “For thirteen of the last fourteen years you remembered my birthday! That’s wonderful!”
What if we tried shifting our focus? What if we spent time during our team meetings to explore things that were successful? By fully understanding our successes, we ensure that we repeat them in other areas of our applications.
For example, if we learned that a particular design layout encouraged more purchases on a retail website, how could we apply that knowledge to increase reservations on a hotel website? Are there parallels that we can take advantage of? If so, what are they?
What if we were getting positive feedback on a change we recently made to a commenting engine on our website? If we only read them briefly, smiled, and went back to fixing bugs, we might miss opportunities to explore what’s working for our users.
Again, I’m not encouraging you to be pie-in-the-sky optimists who only listen to positive feedback, but I think a case can be made that positive feedback provides equal amounts of insight as negative feedback.
Additionally, when you take time to focus on exploring things that work, you’re not only reminded of your successes, but you open yourself to new insights. A mind filled with positivity simply works better.
We also need to be mindful of the negativity that we bring to the experience. I’ve sat in on discussions with developers as they complain about the proverbial stupid user. The application’s design is never the problem. It’s always the user’s fault, and we blame them:
“They’re just lazy.”
“No matter how easy you make it, they’ll never use it.”
I’ve fallen victim to this sort of thinking myself. It’s easy to do.
Lee Ross, a Stanford psychologist, defines this as the Fundamental Attribution Error:
Essentially, the error lies in our inclination to attribute people’s behavior to the way they are rather than the situation they are in.
Fundamental Attribution Error can adversely affect the way we relate to our users. It blinds us to what we’re doing wrong.
For example, let’s say we’re frustrated because our users continually forget to properly log out of our in-house corporate filing system. We’ve educated them numerous times on the importance of logging out and we’ve even tried moving the logout button to various locations on the screen to increase visibility. However, users continually leave their session open, creating problems when they try to log in from another location.
In this case, it might be easy to blame users for not clicking the clearly visible logout button. We might even try threatening disciplinary action for failing to comply with logout procedures. Of course, this is the wrong frame of mind. It’s obvious that the system is failing the user, not the other way around.
So we might have to go explore what’s preventing users from logging out correctly. Perhaps it doesn’t have to do with our application at all. When we visit and observe our users, we realize that their workflow is really not conducive to remembering to log out. We discover that users walk away from their computer with the intention of returning but get sidetracked and don’t return for several minutes or even hours.
After this realization, we decide to create an auto-logout function that activates after 30 minutes of inactivity.
This is what user-centered design helps us do. Every user behavior (whether positive or negative) is a reaction to our application. It’s our job to learn why our users are reacting the way they are. The Fundamental Attribution Error works against this by introducing negative assumptions about our users and clouding our perceptions of what’s really happening.
Creating amazing software experiences requires a great deal of self-motivation. You have to possess a deep desire to get things right. Do your best to eliminate negative language and attitudes. This will help you and your team remain positive, focused, and moving forward.