One of the first questions I ask when meeting with a company is “Why are you looking to integrate UX into your organization?” The responses I get vary, but one common sentiment I hear from development managers, project managers, product specialists and business analysts is the most telling statement when attempting to identify the maturity of an organization as it relates to UX. So what is the statement you ask? You may have said it yourself, or have known of others in your organization who have said the same thing.
“We need to make our products more usable, because our users are not tech savvy.”
So why is this such a worrisome statement? Well, it does an amazing job of wrapping just about everything that goes against everything that a UX professional learns into one neat little package. Let’s break this sentence down into it’s parts and dig a little deeper beginning with the label companies often put on their users when talking about usability: “Tech Savvy”.
Unless we can document across the company a set of skills or behaviors, using the term “tech savvy” in our user community becomes a dangerous sliding scale based on what each individual in your company feels is the bare minimum of computer skills needed to be “tech savvy”. My mother would describe me as Tech Savvy. A network administrator on the other hand may not agree. Part of the label is going to be frame of reference, and without a common baseline that label may or may not be fairly placed on your user.
I’ve met many individuals over the years that believe that a users ability to quickly learn the application, tool or website they helped provide to the user makes that individual a tech novice. If your frame of reference as to the tech savvy of your user is based solely on their ability to use your product, then it leads into the next problem apparent in the statement… a lack of understanding of who your users are.
The second take away from the statement above actually implies that you did a great job with usability to start with. But for some reason, there are these users out there who kinda don’t get it and that’s why we need a user experience professional. So what’s the problem with that?
We shouldn’t be looking to make our products usable only for individuals who we feel are less than “tech savvy” because usability is for everyone. All of our users are users. It’s important that you understand all of your users, and through observational study and research you can document profiles/personas, tasks/scenarios, tools and environments to really understand who it is you are building for. Users have a lot more in common than businesses often give them credit for. If you are reducing your users down to their ability to use a computer (or even worse, their ability to use your product) you are ignoring all the domain level knowledge, experience, decision making processes and best practices they already know. It’s that information that software should be designed around.
Another big, but subtle take away from this statement is that just because you have a product and you have users who were able to figure it out, doesn’t mean it was usable. It just means they were able to figure it out. But more than likely, they were only able to figure out just enough to enable them to continue their tasks.
It is well known in usability circles that users will often times blame themselves when they are unable to figure out a task while using a computer. Why? Because it’s a computer. “It’s Smart” they will often think, and it’s programed to do really complicated things that as a human they can’t do. So for every user that speaks up to contact your organizations technical support for assistance many, many more just continue to struggle away quietly while your business neatly assumes their lack of support calls qualifies them as being “tech savvy”.
So how do companies do a better job of designing their products to make sure it is usable for all users and not just the ones who were patient enough for figure it out it’s complexities? You make sure you utilize the user experience role at the beginning of the project life cycle and not at the end. Mental models, task flows and observational data help to tell the story of your users and how they go about their day. This is the information that gets turned around into story boards, wire frames, mockups and prototypes that can be used to validate against. All before a single line of code is written.
Think about it this way. If your product and business didn’t exist in the world would your users still have to complete the same task? If the answer is yes, you should know exactly how they would go about it. What steps do they complete, why do they complete those steps. What situations would arise that would cause them to deviate from those steps? If you can understand the processes a user would make to complete a task, you can start to build a user interface around those concepts that will match their expectations, and work for the vast majority of your users… not just the minority “tech savvy” users.
The final takeaway from the above statement, is that you felt that just by making a product that was “functionally complete” you have by default made a usable product because your users now have a tool or service they didn’t have before. But now that there are some users out there who just “don’t get it” you have to make some adjustments. I’m sure you’ve heard the key statements in the past, such as “we need to make this really simple to use” or “we need to dumb this down”.
This is the hardest notion to move past, because this really requires a cultural change in an organization. You can put process changes into place for everything else, but if your staff truly believes that just by providing a piece of software that successfully completes a task that you have made the world a better place you won’t even be able to make headway in making the product more usable for the less than “tech savvy” users you have, even if that were a valid approach to take (it’s not.)
If you are an executive that believes this, then you really need to evaluate whether or not you are committed to usability. As an executive, you’ll need to be the champion of UX. You’ll need to make sure all your management is in alignment as to what that means, and identify and help train those who will want to continue using old methodologies. If not, your organization will end up in a cycle of putting bandages on your solutions, trying to fix superficial issues while ignoring the underlying problems with your products design, often times unknowingly adding new complexities to the problem which create new usability issues.
More often than not, you will also end up building a culture where everyone is trying to rally around “usability” without a firm grasp of what that is. A project managers definition of usability ends up conflicting with a developers definition of what is usable, which causes conflict with a business owners definition of what is. All of their notions of usability are based in whatever previous experiences they have had instead of research and instruction. The end result ends up being a consensus through the same process you probably came up with when building the flawed product the first time around. The only thing that has changed is the intent to make the product more usable.
Meanwhile, a UX professional was brought in to make tweaks to what was viewed as a usable tool for all but the less than “tech savvy”. They can never make the real impact they should be making because they are mostly sitting on the shelf during the process, or acting as an in-house tie breaker, or conducting A/B tests at the end of a process trying to prove to stakeholders which of two designs is the lesser of two evils. None of these are a great use of a UX professional.
Your users are more capable than you think. They know their industry, their tasks and their goals. They will probably go about their business with or without you. Because all of your users are, in fact “users” you should know your users; who they are, how they perform their tasks, what information is important to them to make a decision, what obstacles may prevent them from completing a task and design around that knowledge from the start. If you are basing your users competence around generalizations or the number of support calls you get, you don’t really know your users.
If you feel your products work well enough for power users, but you are finding the rest of your user base requires additional support, training or “hand holding” then the overall strategy of your approach to UX has been flawed from the start. UX should be part of the whole process, from conception to completion and beyond. It should help your teams better identify who your organization is building products for and help guide your teams through that process.
Your UX professional should document and communicate this knowledge to the whole organization, not just stakeholders. Along with executive leadership they should be working build a culture of respect for your users in your organization. UX should build an appreciation for your users knowledge, and a desire to help make those users more effective at their tasks.
A proper user experience shouldn’t be one that just gets the bare minimum of users “over the hump” to productivity, it should be a strategy that looks to make all users as effective and efficient as possible.