Imagine you have a house with a large family. You have a plan to turn it into the dream home for everyone; that is, to add EVERYTHING that each family member wants to the house! Everyone is so excited about the idea and eager to start the project right away. As the remodeling process kicks off with much enthusiasm, you soon notice that not all the features work nicely with each other or fit for the kind of a house you have. The whole remodeling project keeps getting delayed because you constantly need to make “quick fixes” to make features work together. Finally you finished the house! But what you now realize is that the house has a ton of top-notch utilities installed in a chaotic manner, and nobody is happy with the house anymore. You have created a beautiful model house that in reality nobody can comfortably live in.
This was the kind of problem that my client faced, except they were “remodeling” their web application. Their business management software used to be a leader on the market. Wanting to become the best in the field and stay ahead of the competition, the client started implementing all the new pieces of functionality that their top customers had requested. Over the years, after so many quick fixes, their product had become no longer intuitive or smart to use. They were no longer #1.
Though the client understood the shortcomings of their application and was very eager to fix it, they did not know where to start or what direction they should take. They had already spent a great deal of effort and manpower planning changes and had spoken to many different users for feedback. However, they realized that by making changes without understanding how users use their product and for what purposes, they would end up making the same kind of mistakes, patching together a temporary solution to fix their current problems. Plus, they were uncertain whether their big investment would succeed or result in a whole new set of problems. Not sure what to do, they hired my team to help them understand how their product was actually being used by real users.
User-centered Design is about knowing how to interpret user data to design ideas.
Every company engages in collecting some form of user data. After all, it only makes sense that we try to understand users before designing any meaningful goods or services for them. There are too many data collection methods out there to list them all, but for the purpose of this blog, I’d like to focus on user-centered design methods. User centered design utilizes contextual user data, which I believe is the most beneficial kind.Online surveys, questionnaires, and Google Analytics are all popular user data, and they are relatively easy to gather from many users in a short period of time. They give us valuable information about what users like and don’t like, and they help us listen to real users’ voices. However, this kind of information alone is not enough to improve the user experience because it only tells small bits of stories about our users. Most of the data focuses on end results, when the root of the problem often stems from something totally unseen. In such cases, if you focus on fixing the apparent issues, it may seem that the problems have been resolved for a while, but later they could lead to a different set of problems. Some of the popular ones I’ve seen in the past are:
- What if a new solution breaks seemingly unrelated existing functions once it is implemented?
- What if users realize what they asked for doesn’t work and change their minds once they start using it?
- What if different users give equally valid but contradictory feedback?
- What if you keep finding yourself trying different solutions for the same problem?
To give you an example, one of the features that was frequently requested to the client mentioned above was having a more prominent Excel export button and making it visible on more pages. Once we talked with and observed users, we discovered that the real issue was not about converting the data into Excel files; what users really wanted to do was to easily sort the data and create reports for different managers, since this particular domain required the data to be analyzed from many perspectives. However, the current application didn’t support that level of flexibility in data viewing, so users had adopted Excel as their workaround to get the information and view the data the way they needed. Once we proposed a solution that allowed flexible data viewing and the ability to pull Excel reports by different values, users were thrilled! This new solution not only saved them time (by eliminating the need to manage Excel files), but also streamlined the process of creating reports for different roles.
How to observe your users
Another insight we can draw from the above example is that it is hard to predict the different kinds of environments our users are immersed in when designing a solution. We tend to imagine users looking at our product in a distraction-free, single-task oriented environment, just the way the focus group or testing lab is set up. However, users are not so focused in real life; they have other applications open along with our product, constantly flipping between different screen views to do their tasks. This is where the intended product usage doesn’t meet the actual user work flow.
As developers and designers, we all know very well about the product’s core functions and what it is supposed to do, but not much about other related tasks that people are creatively adapting our product into. While we can’t anticipate every possible scenario, deciding on a product’s final features without any consideration of other surrounding interactions doesn’t sound like a good idea. After all, we don’t consider the iPhone to be one of the greatest inventions just because it lets us make quality phone calls and play games. Other small tasks that the iPhone lets us take care of seamlessly on the fly is what gets us addicted to the device.
This leads to another question: Users all work in different environments. Over time, users’ needs may change as technology evolves, and people may demand various add-ons depending on the context of their work. Designers can be quickly overwhelmed with all these requirements. How can we come up with a design that will satisfy so many different user scenarios? Despite all of these variables, one thing stays constant: the user’s intention - what users want to accomplish through their actions.
Understanding user intention is one of the critical components that makes user-centered design successful.
On average, if I observe ten users in their real work setting for the same application use, I’d say I could easily witness about 3-4 different ways to do the same task; in some cases, these will include at least one that is totally unexpected. But surprisingly, what all those users are trying to do is not to abuse the system, but to come up with ways to help them get their work done more quickly and efficiently.
Without understanding the real users’ intentions, we could easily say that those seemingly odd behaviors are one-offs and dismiss them from the design and research process. However, if we pause and think about what all these users are trying to accomplish, knowing the intentions behind this behavior could lead us to design better solutions that are longer-lasting and more useful.
Knowing the users’ intentions also empowers you to design beyond what users ask for. As designers and developers, we can take charge of our design and recommend more creative and dynamic solutions to users, as long as we keep their intentions in mind. Going back to the house story from the beginning, if you had taken time to understand why everyone’s feature demands were made instead trying to comply with everyone’s wishes, you could’ve have come up with a blueprint that might not have matched every request, but that worked more harmoniously for everyone.
How do we find out about user intention?
Most importantly, ask users about their experience. We need to understand everything about using the product - not just what users like and don’t like, but when they use it, what leads them to use it, what they do after using it, and what other things they consider while using the product. Keep probing about what bothers them and why a particular function or incident can be problematic. Ask about the actions they were doing at the time and try to picture everything in context. Our goal is to uncover as many intentions as possible, and these intentions may reveal bigger overarching intentions to us.
Keep offering your hypothesis of what the user was trying to accomplish in the moment; the user will validate or disprove your statement. Don’t assume that your interpretation of what you observe is right. Some users may be good at articulating their thought process, but some are not. However, when you share your interpretation of what’s going on, you will quickly understand that users are good at correcting you or building on your interpretations.
You may uncover different intentions that no one has anticipated.
Once you try this method of user interview, you will understand that leading conversation to talk about intentions is not easy. Mastering this skill takes years of experience, because users don’t typically ask themselves why they do or like the things they do. When users are experts, it becomes harder to explain because the more expertise they have, the more they do the tasks automatically.
Getting comfortable talking to users and uncovering hidden motives is the cornerstone of user-centered design. But even if you aren’t ready to hire professionals to do the job yet, try it out yourself. You’ll be amazed at the insights that are revealed when you shed some light on your users’ context and intentions.
