A key interaction design principle is feedback. To be clear, we're not talking about the kind of feedback gleaned through user testing efforts. Rather, the kind that serves as a communication between the system and the user, also referred to as "Visibility of System Status."
As a dev with some UX and research background, this principle fascinates me. And to know that I directly affect how well or poorly a system provides feedback motivates my daily work. This post is born out of some reflection I had while doing some work around my house. You can expect to learn the what, why, and how of feedback in UX.
I wrote up an example in code for this, and you can find that here if you want to take a look!
What’s “feedback” in UX / interaction design?
Feedback in UX is how a system communicates to its users that an action has been taken. Think of a “Post Published” modal with a fancy green checkmark, or the whooshing sound when an email is sent.
What’s Skeuomorphism?
Skeuomorphism is a term for using something known to represent and explain something unknown or novel. Skeuomorphism was key in the rise of modern computing, because it helped people relate to the computer in a way they already knew.
Perhaps the biggest example of this is the “desktop” on one’s computer. Having “desktops”, “files”, and “folders” made the arcane experience of a computer feel similar to something they already have at home and work: a desk where they manage their tasks, mail, and documents.
Poor feedback leads to major user frustration
The value of feedback is made especially evident with an example of poor feedback.
We've all encountered an app or website where we navigate to where we want to go, and (almost inevitably) when you get to the point where it's time to pay for some good or service, everything seems to stop. Immediately, the questions start spinning.
Did they sell out? What happened to my money? Will I have to restart this whole process?
All of this panic could be solved with a spinner or some other visual, audio, or tactile (mobile) queues to the user! That's feedback.
A real-world example of feedback (skeuomorphism)
It’s something that we often take for granted with physical goods. We know that knobs have resistance, and toggles click. A great example of UX feedback with a tangible item is a ground-fault protected (GFCI) outlet.
Using our GFCI, we can see that the feedback we receive is visual: the button depresses. We get tactile feedback when we press a real one. The resistance in each button grows with the depth that it's depressed.
Similarly, our mobile devices vibrate to provide feedback to the user on the severity and length of interaction.
We also get auditory feedback from a GFCI. The button clicks when it falls in place. This too can be emulated in mobile and web.
Considerations
Often when we consider feedback in UX and dev, we think of visual feedback for buttons. Hover states, active states, etc. are good starts, but sometimes an additional sensory is appropriate, and might just be that extra oomph your product needs to surprise and delight your users. Consider audio and tactile feedback too! Motion can help indicate intent as well.
One often overlooked area of feedback relates not so much to direct actions as to events. Logs, error messages, confirmations, alerts; all of these are examples of feedback. It's important to keep in mind that sometimes one may have too much feedback, and that can be as big a problem as not enough feedback.
TL;DR When designing and developing products, consider what information you give to your users. Sensory feedback is crucial for creating realistic experiences, and copy defines the conversation between the user and the system.
When feedback should be included
In considering when to give feedback, the answer isn't so easy as "always." It doesn't always benefit the user to have extra information. CLI commands have --verbose for a reason: more isn't always better.
Yet some feedback is usually good. Here's a guideline. Send feedback any time that:
- The user interacts directly with the UI.
- The server sends something to the UI.
- The server and the UI are out of sync or working on something (loading, errors)
Where feedback can be applied
Where feedback is placed is almost as important as what feedback is given. As an example, it wouldn't make sense for the GFCI to have that tactile resistance when plugging something into the outlet if everything works fine. Similarly, it wouldn't make sense to give feedback that doesn't match the situation, like having the status indicator light glow red when the circuit works just fine.
But again, feedback often should include copy that gives the state of the situation and/or instructions to the user. And there's a place for that information to live. This is part of where modals, alerts, and confirmation dialogs find their strength. They grab the user's attention and present information that has a higher chance of creating conversion on whatever action the user should take at that point. Prominent placement of this text is crucial for making sure the user knows what to do and where they are.
TL;DR Feedback should live in the interactive elements, in modals, and in places where users should actually see it or experience it. Again, don't forget to use tactile and audio feedback where it makes sense or could improve the experience!
Why feedback is so important
Feedback is important because it's one of the main ways (or the only way, in GUI-less interfaces) that we who create products and systems send information to our users and continue the conversation. Done well, feedback feels seamless and facilitates a delightful, friendly conversation that leads to a great long-term relationship. Done poorly, it can alienate users, ensure drop off, and raise customer support costs.
Some links that helped me in writing and thinking through this are below. If I could summarize the whole "Why" in one small phrase, it would be this:
We want to treat our users to the kind of experience we desire for an app. We want to improve their lives. Feedback is a primary mechanism accomplishing that goal.
