Context based feedback and its pitfalls

When users interact with our products, what are they trying to achieve? That’s the million dollar question in product design and development and we have some methods to try to get to that answer. But product work generally has a difficult problem of making things truly based on what we know vs what we like to think that we know. The approach of the user is one of the most notorious ways this comes up.

Have you ever had any disagreements with engineers or designers who said something like “I don’t think the users would want to do it this way, they would rather do it that way”. This is a tough situation, because product professionals have a work to do and this seems like second guessing by someone who may or may not have the right perspective. But you can’t outright tell people they are wrong because they are in the wrong department. Other people in the organization have great insights and have personally saved me from calamitous decisions. So the right approach is to explain your reasoning and hopefully you have either a solid principle or data behind your argument.

But we don’t always have the data, and we sometimes cover up our intuitions with some language about best practice. One of the ways this continuously comes up is when we think about a feature in a specific context and have a hard time departing from that context.

Let’s say you are building a banking app and listing the connected accounts a client has. You have limited space and you need some kind of decision about which ones display fast. Often our approach is based on context, usually the context that was set by our intuition, research or anecdotal evidence. When a client asks for something specific for instance they are coming in from their own context. So for our app we maybe say the most recently viewed ones are most important because you believe this is the most common use case. Several months later you hear from a client who is providing their context saying that they use their account dashboard to quickly take a look at their balance. Their most active account is never there although that’s the one they are interested in most. So you ask them why they don’t visit their most active account if it’s so important. At this point your client is probably rolling her eyes and wondering why they have to explain their behavior to you. It turns out they sell items online and are not using the bank account to view details but it’s the fastest way for them to see if their earnings have been sent to the bank account. So now you have another context are you going to change everything?

Another example is for UI elements. Let’s say you have a very long text input field and you need to add another button to that row so you ask yourself why on earth is that field so long? It’s only for a name after all. So you make it short. Engineering complies and several months later you get complaints that users can’t differentiate their file names because the name input field is too short. Everyone is wondering at this point why you made it so short in the first place.

Context makes us feel relatively sure about what needs to be done. It’s often urgent, sometimes it’s tied to a sale and there is a dollar figure around it. Sometimes the logic of it seems so clear that you feel dumb about having done it differently in the first place.

However context is not data and if you are building products with context there will be a lot of back and forth and wasted time. One of things that will help you is some research. For instance if you are building a dynamic text or input element, you can query your database to see what is the range of character lengths existing clients use for this purpose. You don’t even need the actual text itself for this specific issue, you just need to know the range and details on the variation (basic descriptive statistics will help you a lot here).

Having (and saving somewhere) this data and how you got it will improve your design and product process. For one thing you will know why you made this decision and when you show the data you will receive a lot of respect and buy-in from otherwise skeptical stakeholders. You will also in the future remember to not impulsively undo your work because users complain. One of the hardest things to do in product is to tell your team that although you received some negative feedback from some clients you are not going to make any changes. But remember that this kind of continuity is good for your business and good for your product.

To make sure that your decisions are not purely context based ask yourself these questions:

  • Why do users want this? What are they actually trying to achieve?

  • Is there another way to solve this?

  • Why did we implement our current method in this way? What resources can I find to give me context?

  • How many users have wanted this before?

  • How have existing (historical) clients interacted with this feature? What does our analytics tool say about the use?

  • Are there patterns that people want this feature have in common with each other?

  • As this request makes life easy for some users, will it make life harder for others?

Another way to make sure context based thinking will not determine your actions you should use UX tools that give you some stability in terms of who your users are. Personas are a good resource for this when done right. They indicate the major types of uses for your product and feature and make it easy to systematically cover different user needs at any conversation. Simply go through each persona in your list and see how the change proposed would affect their experience.

And lastly write things down. Documenting this, even with some notes, will help you next time some context related request about the same feature comes in.

Photo by marianne bos on Unsplash

0 views
Let's connect on LinkedIn

© 2020 by Caner Uguz. Good job, you are reading the fine print but there is nothing interesting here.