The importance of feedback in user experiences
I work in a large room that’s offset from a larger and more public area. The room is locked, so that only people who work for my company can enter as long as they have an ID badge with the appropriate permissions assigned. There are two doors through which one can enter the room. These doors can be opened by anyone from the inside of the room, but you must first push a red button adjacent to the door.
One of these buttons produces a clicking noise. Once you hear the click, you know to open the door. The other button produces no discernible noise. And sometimes, for whatever reason, it doesn’t release the door lock. Perhaps the button was pushed too softly? Perhaps the button was tapped too quickly?
We’ll never really know why the button doesn’t work but the fact remains that the problem here is more with the audible feedback. Without a noise, it’s hard to know what the problem is and adjust my behavior as a user of the said door accordingly. Right now, I just hold the button firmly for at least 2 seconds and that seems to work consistently — for now.
This is not what we should do to our customers in interactive experiences on web and mobile, but it’s exactly what happens in many scenarios. A simple color shift, tactile vibration, or other simple response is often all a user needs to know that the desired behavior did something. It’s not that difficult to achieve, yet often overlooked.
Think about the number of times you load something and you aren’t sure if it completed loading or not. In those instances, it is likely that there’s no clear loading bar or wheel or any other indicator to tell you that, behind the scenes, that hamster is doing his best sprint around the wheel (however slow it may seem to you).
A clear error message is a great opportunity to provide feedback — especially for products where there is an expectation that someone else somewhere will be providing customer support. It’s a lot more effective for customers to voice that they were shown a specific error code to someone trying to help them rather than saying, “It just doesn’t work.” These kinds of things will also inevitable keep those folks at the forefront of the support more productive (and hopefully happier as a result!).
Ultimately, however you choose to do it, an interaction is not an interaction unless there’s something that the user sees, hears or feels (feels as in a vibration and not as in all the feels) as a result of their action. And it’s this kind of attention to detail that distinguishes good products from great products.
This attention to detail makes users feel good. A response can reinforce that the user did good and it can also serve as an opportunity to surprise and delight. Fitbit right now has a really good example of this. They’ve released a new in-depth sleep-tracking feature. Every now and then, they share a factoid at the top of my sleep logs. And you can either “Like” or “Dislike” it; a tap on “Dislike” prompts you to describe why while a tap on “Like” shows a modal window that says “We like you too!” In that instance of capturing positive feedback, they could’ve just dismissed the factoid but they instead acknowledged the feedback (via showing the modal) and then provided a nice positive message within. This is really extraordinary considering Fitbit is in the fitness space which has a tendency to skew toward body negativity very quickly. You can clearly tell that they are aware of this and their app does a really great job of focusing on the positives in their feedback to the user. My hunch is this is probably what helps keep their users from straying too far, even if they aren’t necessarily seeing the fitness results they had in mind.
And, of course, I’d be remiss if I didn’t touch on the topic of feedback within the process of designing and building products. Feedback to and from users is essential but feedback to and from members of a cross-functional team of marketing, product, design and engineering is crucial to getting anything done. I’d like to encourage more specific and pointed constructive feedback as it relates to ways to work more effectively.
There should always be a very clear vision about what the product is and what we are trying to achieve with the product. Thus, if something arises among the team that takes us away from that vision, all the team members can raise the issue and hold the team accountable to address the issue.
Straying from your vision can be useful but it should be intentional. Having clarity of purpose will ultimately help drive consensus for decision-making with stakeholders, too, allowing everyone to work without fear that the rug is going to be pulled out from under them. This vision has to be communicated early and often which, again, is the feedback that is so important when working within cross-functional teams (and especially distributed teams that don’t all sit in the same room let alone the same time zone).
I’ll share a personal example that feels relevant here. I recently inherited a product and let’s just say it is precarious at best. This is actually fairly common for me (I guess you could say I like the fixer-uppers?) so I’m not super surprised that there are issues that require my immediate attention which have nothing to do with my immediate roadmap.
In any event, before I can get to my roadmap and before I can fix any of the immediate issues brought before me, I simply send out an email to the user group. I simply let them know that we’ve uncovered an issue, I don’t know the cause yet, and I will keep them updated as soon as I have a resolution. The overwhelmingly positive response to this was surprising to me; I was sharing bad news but it was news! Despite the negative outcome as result, they were just happy to be informed. They craved any feedback, even negative feedback.
At the end of the day, it’s nice to know you aren’t the only one having problems opening the door using that stupid little red button.