Everyone who works on projects knows that in the IT industry there’s no such thing as a finished product. There are various reasons: sales is not going as you’ve expected, you don’t like some things, or your clients tell you to introduce some changes. The latter is a dream situation because you’re assured that what you change will meet their needs and usability requirements. However, you shouldn’t count on all of your users to give you feedback, let alone constructive one.
Researcher’s comment: when I think about feedback from clients I frequently come back to a, clichéd in the UX context yet very accurate quote by Henry Ford: “If at the beginning of my career as an entrepreneur I had asked clients what they wanted, they would have said faster horses. So I never asked.” Luckily, observing people in their natural environment provides us with an opportunity to learn the most about their real behavior. If there is such an opportunity, why not use it?
What value does observing users provide? Why and when should you do it?
It’s pretty obvious that most time and money required for the development of a product is invested during the pre-production phase. But usually it’s a shot in the dark, as there is never a 100% certainty about how the market will respond. Below, you’ll find out when and what you should check in order to minimize the risk of designing a useless product.
- Prototyping/creating mock-ups – save some time!An idea is sprouting up in your head, you have a clear vision of what you want to accomplish and to what need of the market you want to respond, but what you lack is the validation from the potential users. That’s why, when you are creating mock-ups, you should confront your current ideas with potential users – thanks to that you will save time by introducing corrections before designing and coding your project.
Programmer’s comment: when you show your team who they’re designing for, and how people actually use their product, it will allow them to save time and energy. This is because they will be able to see the real problems, which can usually be solved quickly. I know from my experience that it will boost team’s level of engagement and can solve a frequent problem: software developers and designers don’t understand project manager’s vision and get into disputes.
Obviously, when you create mock-ups not all details are polished, but you can definitely observe a few things:
- How users move around and use the functionalities you’ve proposed,
- Whether they search for information or CTAs where you located them, or are ignoring them,
- How the traffic on the website looks – whether the planned information architecture of the service is intuitive,
- whether the direction of development you’re headed is the right one or maybe you should introduce a small change that would better respond to customer needs.
At this point, a good solution is to give your users a, so called, free hand. Let them use their own computers so they’re not distracted, are not trying to be polite, or prove that “of course that you have a great product!” People, when tested, tend to act as if they were experts and accommodate to potential expectations. On the other hand, sticking to specific scenarios narrows down the way of using a product to what you imagine. And who knows how it might actually be utilized by users?
- Redesign of existing product/website – leverage accumulated data!Yet another situation is the moment when the website advertising your product or service needs a redesign. This is a much simpler situation. Based on previous user behavior you are able to, for example, diagnose current problems or define the aim of the visit on the website. Very often, during workshops or interviews with clients, we come across a statement that they intentionally don’t test user behavior because the website will be redesigned anyway and there is no point in testing it. That’s a mistake! If you’re not planning to change line or character of your business, this is the perfect moment for testing:
- What your users interacted with so far?
- What are they not interested in the least?
- What draws their attention?
- What is causing problems for them?
Translating your observations into business goals will allow you to eliminate irrelevant content from your website, simplify user flow, and drop inessential features. You can knowingly build a new, much more usable website, not relying on your intuition and current trends, but on data.
- Testing – how does the product fall when interacting with users.In an ideal workflow, even if it has not been possible before, the moment for testing always comes. Usually, this is the first moment when, after hours of project team’s work, the product meets users. Then, you might come across a problem where to find testers. If you have a budget and time, the best option is to hire an agency for UX research. But let’s be honest – very often, there are no resources for that. Many UXers use opinions of their colleagues from different departments as support, which does not convey the real picture of how users will deal with the product.
Researcher’s comment: to be clear, I’ve got nothing against hallway testing, it often is a good solution to quickly verify your idea. But it can’t be a replacement for confronting the idea with those who will actually be using our product. Especially at this stage.
The tools for observing users online allow you to:
- Acquire hard evidence (concrete data, for example in the form of heat maps, will act as a perfect argument for the decision makers),
- Conduct research even with a very tight budget and little time,
- Conduct remote testing,
- Enrich tests with users’ natural reactions and behavior,
- Avoid the situation when your colleagues play the role of potential clients.
These are of course only some of the advantages that observing users give you. In the era of client-centric approach, and from a business point of view, it’s always good to know as much as possible about your users. It’s also important to be aware that you don’t have to be an analyst in order to start observing your users. You just need to know which tools you should use.
Originally published in polish here
Translation: Magdalena Sobieszuk
Categorised in: Analytics