These are exciting times for the digital and UX design domains. Over the last few years, providing great UX has not only helped digital focused companies become market leaders but also survive in turbulent times. This is a big win for UX practitioners and the discipline at large. UX is now mainstream and ROI of UX is well known. However, (and here comes the rub) we also see some UX projects fail spectacularly. This is a perplexing problem for companies and they struggle to understand why despite executive sponsorship and substantial investment, UX interventions sometimes fail to deliver on the desired outcomes. So, what does the success or failure of a UX intervention really boil down to? Here are 5 things companies unknowingly do to sabotage UX projects...
Let's say you are embarking on the UX redesign of a passenger check-in application for an airline to be used by check-in executives and the product owner (John) sets the design brief as “create a minimal, google-like interface which is easy, engaging and cool”. The UX team (internal/external) works wholeheartedly to achieve this objective. The technology and implementation teams break their backs in deploying the new design. The airline excitedly waits for this to go live. And it does…but instead of getting compliments and hearing praise, they are flooded with complaints from users (check-in executives) and customers (passengers) on how slow the check-in process has suddenly become. Instead of making things better, the new design has resulted in making the queues at the airline check-in counters longer, the check-in executives frustrated and the passengers unhappy. John is stunned.
What went wrong? Everything was done by the book…why did the UX revamp fail?
John made the classic mistake of assuming that UX is always about ease of use, engagement and delight. UX objectives are context dependent and vary significantly depending on the domain, users, business goals, etc. For example, the key UX goal for an ATM would be ease of use whereas the design of an aircraft cockpit would focus on safety. In the case of the passenger check-in application, the core UX objective needed to be efficiency instead of ease of use. Getting the objective wrong proved disastrous because, designing for efficiency vs. ease requires completely different approaches. Designing for efficiency usually requires the interface to be denser and tuned to power-users which is the opposite of the minimal, wizard-based approach you would typically need to design for ease.
Study by IEEE (2005) found that one of the top 12 reasons that an IT project fails is because of “Unrealistic or unarticulated project goals”. The bottom line is…if you get the UX objective wrong, no matter how great the team is or how much time and money you spend, you will not only fail to achieve the desired business outcome, but also do more harm than good.
User input is typically required in two different ways as part of a UX project. One to conduct research before the design phase and the other to test the design. The objectives, methodology and outcomes of each type of data gathering is very different. Enough has been said about the importance of direct user involvement in UX literature over the years. Despite that, we still come across companies, UX teams & consultants who fail to include the crucial user research and validation steps in UX projects. (Sadly, we also come across so called “UX designers” who have never done user research or testing. They do not qualify to be called UX designers. Just thinking about users does not make the design user-centered. The UX field is in real danger from this type of “fake” UX work. But that’s a topic for a different article).
Why is there a tendency to design in a vacuum and avoid user involvement? Here are three things business executives are likely to say to skip getting direct user input on a UX project...
It’s very easy to fall into the trap of thinking that we understand our users because the human brain has an inherent tendency to generalize. Generalization is one of the ways our brain keeps us safe and helps us learn, whereby we often take the information we have and draw broad conclusions about the world based on our experiences. But when we make assumptions about user behavior and expectations, our ability to generalize works against us. Without direct user involvement, we can’t help but give in to our personal biases and end up designing for ourselves rather than the users.
Users often say one thing and do another. Unlike surveys, qualitative user research and user testing are primarily based on open-ended discussions and observation rather than close-ended questioning. Have you heard about the $1.85 Billion Mistake by Walmart? They decluttered Walmart stores based on survey findings that users prefer clutter-free aisles. Not only was the survey design poor, this data gathering method did not allow them to observe the actual user behavior and probe. The result? Sales dropped massively because what customers really valued at Walmart was a vast inventory of cheap items and increasing aisle space had the opposite effect.
It is a myth that user studies require adding huge amounts of time and money to a UX project. According to the Nielsen Norman Group: Elaborate usability tests are a waste of resources. The best results come from testing no more than 5 users and running as many small tests as you can afford.
(https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/). Eric Ries in his book “The Lean Startup: How Constant Innovation Creates Radically Successful Businesses” attributes the success of startups primarily to user involvement in the design and development lifecycle. Through direct user input and feedback is how they solve the most critical decisions in terms of content, features, functionalities and work flows. So, it’s true that direct user involvement does add some extra effort and time but the benefits far outweigh the cost of rework and the failure.
Many large UX transformation programs are inherently risky. The stakes are especially high if you are creating a completely new experience from the ground up with many new features and functionality. Without an early feasibility check, you risk spending months on your breakthrough designs only to realize late in the process that the solution is not implementable or requires impractical amounts of time and money. A proof of concept (POC) allows the technology / implementation team to better understand the capabilities and limitations of their development environment and raise flags early. A POC also allows the stakeholders and project teams to arrive at a more precise estimation of the time and resources required to design and deploy the desired solution. But just creating a POC is not enough, once the full project kicks-off, it’s vital to seek a sign off periodically from business and the technology team on the design as it takes shape. The ultimate goal of any UX project should be to find the sweet spot between what business wants, what users need and what technology can enable.
It is a natural tendency to want to pack in as many new features and functionalities into an interface. After all, your intention is to give the best value to your customers. But usually, adding more features and functionality is inversely proportional to simplicity and ease of use. In most cases, great UX is an outcome of asking “what should we remove?” instead of “What more can we add?”. Great user experiences are built on a relentless focus on what’s core to the user needs. Most users tend to use only 10% of the features 90% of the time. Think about it. How many features do you really use on your cellphone, TV remote, word processor, etc.
Also, your interface may have more features, but if nothing stands out as exceptional, your users won't be hooked. So, focus your design effort on perfecting the 10% that people use regularly. Make sure the user's everyday experiences are as smooth as possible, and if they have to climb over hurdles every now and then, most users will be willing to do that.
Every good design has an expiry date. To add to that, a rapidly evolving technology landscape continues to shrink innovation cycles. Agility and speed are hygiene factors for success. Yet, we have seen many large institutions spending years to get a new design live. The delay not only wrecks any chances of gaining a competitive advantage but also ensures that by the time a new/improved version of a digital interface gets launched, it is already outdated.
There are several reasons why this happens. Improper project planning, hurried requirements gathering, stakeholder politics, skill gaps, outdated methodologies and not knowing when to stop iterating. There is no silver bullet to address all these issues but as a start, here are three things you can do...
Creating anything good requires a robust process & outcome orientation and the design of digital interfaces is no different. It’s time to move UX beyond its buzzword status and adopt it as a true discipline.