A welcome change.
How to alter a user’s process without losing their trust.
As designers of a product, perception is just as powerful a variable as reality when it comes to garnering adoption. To a user who has acclimated to the rising temperatures of their proverbial water, change can feel scary even if it is in the right direction. How we roll out a new feature can make or break how useful it becomes for our users, and so we must protect the trust they’ve placed in us to deliver more and more value. In this post, we will discuss a few tactics that could help ensure change is seen as an opportunity rather than a challenge to overcome.
Taking our own advice a bit, let's start with a common reference point widely known within the design community: NN/g UX heuristics. The 10 user experience heuristics championed by modern design thinker Jakob Neilson serve as a guide for building thoughtful experiences. If you are unfamiliar with these principles, don’t worry. We will only focus on a few of them today and walk through how they can help us rationalise the deployment of certain tactics to keep our users hopeful about their future with our product. This is especially true when it comes to internal products (i.e. products used by your employees) as our users are motivated by a job to do and often don’t have any other options of what platform to use.
If you’d like to learn more about these heuristics and then come back here then take a look at the following link for a simple breakdown: [but make sure you come back :) ]
Match between the system and the real world.
The key is to set realistic customer expectations, and then not to just meet them, but to exceed them - preferably in unexpected and helpful ways
- Sir Richard Branson
The first principle we are going to take a look at is that of ensuring there is a match between the system the user is interacting with and the real-life scenario the system is mimicking. What this means for our users is that the interface they interact with is not so far removed from their understanding of the task at hand that they cannot see the parallels therein. It is our job as designers to make complex tasks as simple as possible, but we cannot create such an overhaul that the original task is unrecognizable.
The most extreme form of this heuristic in action can be seen in the skeuomorphic designs launched in the earliest iOS apps for the iPhone. Apple famously matched their app launcher buttons and even the app interfaces themselves to the matching real-world items. The calculator looked and worked like a physical calculator in every manner of colour, dimension, and feedback. In our progression of visual design styles, we have partially obfuscated the ease of matching systems to the real world these days. While our visual styles are now cleaner and less distracting, the principle of ensuring the interactions are consistent with the user’s expectations has not diminished.
Let us think, for example, of a system that lets a user track the food being delivered to their home. The system will likely be generating orders and prioritising them with the restaurant, helping the delivery driver to find the quickest route to the user’s home, and even speaking to the user’s bank. While all of these are important steps of the process they are all peripheral and complications that have nothing to do with the status of the food’s relation to the users’ home. This has great potential to overlap with another heuristic of ensuring there is adequate visibility of the system status.
Why do we care? The more we can accommodate these principles the more comfortable we make the user using our system, new or old. A user’s anxiety about using a new system can be born at any point in their user journey. One of the quickest ways to spark this fire is to show the user something that is hard to decipher and has no connection to their expectations of what the system is for. If we think of the example before, a user who is met with complex strings of text that can be decoded for what order their food is in to be made by the kitchen may immediately experience a sense of delayed satisfaction with our food tracking system because it is now even farther away. By comparison, if we let the user know it is at the restaurant being prepared, much like Deliveroo, we have bought the kitchen some time and kept the user informed without overloading or challenging their expectations.
User control and freedom
In the truest sense, freedom cannot be bestowed; it must be achieved
- Franklin D. Roosevelt
Ensuring someone feels in control is the second facet of diminishing anxiety for our users we must be aware of. It is one thing to tell our users “this does everything you need to do”. It is something entirely different for them to discover this for themselves. Especially in the internal product design environment, a user has a job to do. If your designed experience distracts them from this task in any way their trust begins to whittle away. This is why we have to constantly manage a balance between feature-itis and a perceived feature-rich environment. If we truly give the user every possible feature then we will ultimately be left with a busy crowded product. If we by contrast restrict their actions to only one task then accessing the product might feel like a hassle and result in falling adoption & engagement rates.
There are a few tactics we can use to strike this balance. The first is to know when to show the user that something exists and when to hide something. This is a decision that is often decided for you by whether it is physically buildable by your development partners or not, but we as designers have to treat what is not there with the same reverence as what is there. In the same way that music is framed by the rest notes, design is framed by what we choose to not distract our users with. This is an issue however if we hide completely something that will impact the illusion of control for the user. This is where I want to share a powerful tool taught to me at the very beginning of my UX career.
What must be obvious? What must be Easy? What must be possible?
If we combine the notion of using strategic hierarchy to rank our tasks in the way above, we can manage a user’s perception of how in control they are. By making their primary actions obvious we meet expectations immediately. By making it easy to find our auxiliary tasks we manage most of our users’ need for flexibility. By making it at least in some way possible to perform fringe tasks but not making them the most important thing on the page we satiate the most curious of our user base. In this way by dropping the visual affordance of something we can actually heighten its impact strategically.
Consistency and standards
Change is not popular; we are creatures of habit as human beings. 'I want it to be the way it was.' But if you continue the way it was there will be no 'is.'
- Robin Williams
We have to trust our users. If we don’t let our users drive the changes we make we might as well go home. We have to know how to listen to our users. In the same way that our users have a real-world system their tasks mimic and they intend to complete said tasks in the way they want to, they speak about that task in a particular language. This is true as far as matching the words they use as it is for the digital patterns and practices they are used to. A videographer is not used to the same interfaces as an accountant. If we want to bring innovation to the way a user interacts with our product we cannot ignore the things that they find comfortable, no matter how poorly they were initially built. If our users are used to a process that is extremely manual and we immediately automate it they will likely have a strong distrust for the accuracy of the automation. Change must be handled carefully, even slowly at times.
I say the above only to remind us that as designers we see a world of opportunities. We have trained our minds to approach a blank slate with excitement. This may not be the case for the users of our product. If we are optimising a process for a group of users comfortable with spreadsheets then a snazzy whiteboard UI is not the right choice for them. We have to match the standards they are used to. Over time we have the opportunity to craft their expectations into ones that can abstract their task into another format but day one is not the moment to introduce new patterns.
When it does come time to introduce something groundbreaking and new, we can use gamification to ease into these new patterns. If we reward the thing that a user knows and then present the reward in a new way of representing the data, we have the power to instil a sense of growth in our users.
We can look at several of the heuristics for inspiration on how to manage a user’s anxiety. ‘Visibility of system status’ ensures a well-informed experience. ‘Error prevention’ works hand in hand with ‘recognition over recall’ to ensure a user is not led down the wrong path. Once you approach your product’s change through the lens of how opening the product one day to be faced with sudden change, you begin to strategize how you can implement those needed necessary changes on a gradual path forwards.
Thanks for reading! Subscribe for free to receive new posts and support our work.
