Friction as a Function In User Experience
I’m often asked “Meirav, what does biophysics have to do with user experience?” Well, being a multidisciplinary person provides me with an endless pool of ideas, perspectives, and metaphors that I greatly enjoy using in my work as a designer. Borrowing the concept of friction from physics to describe a notion in digital product UX is a great example of connecting the two worlds.
In mechanics, friction is a force that resists the relative motion of two objects sliding against each other. But friction is at work in the digital world as well.
Friction in UX acts between the user and a product: While a user tries to complete a task, the force of friction acts in the opposite direction, backward. As a result, our user’s progress is slower, and he has to use greater effort to move forward and complete the task.
Steve Krug’s book Don’t Make Me Think (a must read for any UX designer) outlines the principles of good usability. Krug’s notion is that users should be able to accomplish their tasks as easily and directly as possible.
For users, “don’t make me think” means we shouldn’t need an instruction manual to operate the UI. It also means making the least number of decisions and using the least cognitive effort possible. We prefer to burn calories in the gym.
For UX designers, “don’t make me think” means incorporating known patterns into our designs, using common UX standards, applying consistency, and creating a solid, intrinsic system logic to make users establish habits. It also means decreasing visual load, creating good information hierarchy, etc.
But as a UX lead and researcher who has been working closely with users and customers for many years, I’ve realized that when it comes to complex systems that control critical functionality, the fast, easy, and standard way of doing things is not always the best for users.
When there is limited friction, everything goes smoothly—maybe too smoothly.
Bear in mind: In most cases the usability principles championed by Don’t Make Me Think are ideal for creating an effective user experience. It is up to us, as experts, to identify those rare features and cases that require a different approach.
I’ll explain this by demonstrating three principles, using research I conducted for a real project. Our user personas for this demonstration include Adam the system administrator, an expert user of a critical application with all the relevant permissions, and Jane, his manager.
The conventional rule of thumb: Decrease visual load. Make an interface as clean and simple as possible.
But there are cases in which we need to add text, visual elements, and functional elements to make functionality clearer and more easily understood.
For example, imagine a super-sensitive feature in a critical application that’s rarely used by Adam, the system administrator. The purpose of this feature is to edit system rule settings, each of which govern specific operational aspects of the system across the board.
My study showed that an administrator who rarely operates this feature (once a year on average) is unlikely to remember what each and every rule means or controls.
To remedy this lapse in memory of critical details, we incorporated inline help texts describing each rule in the feature’s main view where all the rules are presented. Furthermore, when a user drills down to the details view of each rule, a longer inline explanation appears followed by a link to the full online help documentation.
When it comes to rarely used critical operations, incorporate some inline help text — even at the cost of increasing the visual load.
The conventional rule of thumb: Don’t waste users’ time. Let them complete their tasks in the least number of clicks or steps.
But there are cases in which we should add more steps, such as when we’re dealing with confirmation of actions on sensitive operations. This is necessary to give users a sense of safety and control.
To demonstrate this principle, let’s go back to the feature discussed in the previous section, editing sensitive rules’ settings. Remember, this feature determines how the application operates across the board, which makes this operation critical and super sensitive, requiring the highest permissions.
There are two typical users who are relevant for this discussion: Adam, the system administrator, and Jane, Adam’s manager.
Editing rule settings is done in two steps: First we determine a rule’s activation state (active or inactive), then we edit other specifications.
Adam asked me to make it possible to change a rule’s activation state in the most direct fashion possible, perhaps by using an inline toggle that would allow him to “quickly switch between active and inactive states.” He also wanted to incorporate this functionality in the main overview screen.
However, when I continued to research this concept, things turned out to be more complicated. As you might expect, different types of users have different perspectives, motivations, and agendas.
Jane and I discussed this suggested solution.
“No way!” Jane said. “I wouldn’t feel comfortable knowing that Adam can quickly and easily apply such a critical and sensitive operation across the board.”
Interesting.
Jane continued, “I want to approve such critical operations myself prior to them being applied across the board.”
Very interesting.
So we increased the UX friction of this feature to make Jane feel safer and more in control. We designed a UI element that opens a bubble when clicked. In this bubble, the user can consciously select the desired state and proactively click the “save” button. Following this, a confirmation message appears with a short description of the consequences of applying this action. We want users to be aware of what their actions mean.
No to auto-save. Yes to conscious actions.
When it comes to the most critical operations that significantly affect objects, users, and environments, design multiple confirmation steps.
The conventional rule of thumb: Keep it consistent. When designing UX for any product or service, we’ll stick to some templates and patterns so users can form habits that allow them to more easily use the system.
But in some cases, when performing the same action on entities of varying sensitivity or criticality, we should design the flow in such a way as to prevent our users from operating on autopilot, potentially causing big problems by not being conscious of their actions.
To demonstrate this principle, let’s talk about three entities in our system, each of a different level of sensitivity:
Users can delete items of any type in the system. Naturally, the meaning and consequences of deleting items of different sensitivity levels vary.
So, we designed a different “delete” function for each entity:
In this example, we placed the same function in different locations and added more clicks to access it as the criticality of the operation became more severe.
When applying the same function to multiple entities, slow users down and make them aware of the consequences of their actions by breaking consistency.
As a rule of thumb, we design UX to achieve simplicity, so users can accomplish their tasks in the easiest way possible. We apply “don’t make me think” principles to create the most effective and delightful experiences possible.
However, there are unique cases that require a different approach. These would be the most sensitive, critical, influential, or extreme operations and features. In these situations, we need to increase the friction by carefully and deliberately slowing users’ progress and making them consciously consider their actions.
Increasing the UX friction aims to empower users’ sense of safety and control. Consider when, for whom, and how to do so. And while it’s always important to test and validate our designs, when UX friction is involved, it’s more essential than ever.
After all, there are times when an experience can go a little too smoothly.
Friction as a Function In User Experience
Research & References of Friction as a Function In User Experience|A&C Accounting And Tax Services
Source
0 Comments