You might have created the first version of your product very quickly, and, at that time, you might not have been concerned with how it looked; you just wanted it to work. You have previously shown it works, but that might have been a few years ago. Since your initial launch, you have probably added features in different places. You have been putting links and forms and maybe a few flags that show everyone what’s new, wherever there was room, and you weren’t focusing on what would be the best content layout for your customers.
Your pride over your initial launch has faded, and you might wonder how your product got so messy. You might have read a little about user experience design and now believe adding a UX designer will be the panacea for your messy product. You might have even seen the statistic that every $1 invested in UX can return up to $100 in revenue, and you wanted that $100 return yesterday. More and better-designed competitors are popping up everywhere, and you want your product to compete right now.
So now you believe that the only thing that you can do right now is to hire a UX designer — one outstanding UX designer because that’s all you can afford — and let them do what they do and, in a month or so, fix everything that went wrong with your product over the last few years.
Not so fast.
Common misconceptions with UX and product development
UX is a powerful and valuable tool, but misconceptions abound about what UX can do and how long it can take to reap the benefits. In engineering-driven organizations, product management can be very feature-focused. Engineering teams likely have a history of delivering features and delivering them very fast. Now bring in one solo UX designer. They will tell you that you need to slow down, take a step back to interview your users, and analyze what the users say so the designer can start designing — a recommendation to a company whose culture is already geared toward feature releases quarterly or monthly.
UX is a powerful and valuable tool, but misconceptions abound about what UX can do and how long it takes to reap the benefits.
Be honest: how do you think that kind of business proposal, coming from one person new to the company, would be received? That UX proposal is guaranteed to be poorly received, the UX designer will be unable to do their job effectively, and your new designer’s time and money will be wasted.
This scenario, unfortunately, plays out in businesses all the time. But it doesn’t have to play out that way for your business. How?
UX practices and people are investments; you must do your due diligence like any investment. Part of that due diligence is truly understanding what UX designers and researchers do daily. With that understanding, you can build a strategy to add user experience to your organization’s culture, minimize conflicts, and keep your product cycles running smoothly.
So here are some common misconceptions about what UX people do vs. what UX people actually do. Do any of these sound familiar to you?
False: “UX designers just make things pretty.”
Although, on the surface, this appears to be true, once you peel back that onion, you will see that “pretty” is the result of a process and a lot of effort. UX designers base their work on user inputs, and to get that input, UX designers and researchers need to interview actual users. In engineering-forward organizations, this is a significant source of conflict. Only people with specific job titles can talk to clients in many organizations. This mentality prevents UX people from doing their jobs, leading to rapid frustration and burnout.
Before making things pretty, UX people need to understand the problems your users have in order to come up with a solution to make them, and by extension, you, happy. They are not looking for flaws in your product. They are looking specifically for the problems users have. Preventing UX designers from finding those user problems will only create another big problem — for you, when your users leave for competitors.
True: UX designers do often make things pretty — but that’s just a side result of intensive work finding the problems your users are experiencing.
Before making things pretty, UX people need to understand the problems your users have in order to come up with a solution.
False: “We don’t need UX research. We already know our user.”
If you know your users, where is it documented? For example, does everyone in your organization know why users stop using your product? Do you have any data to support certain features being built? Or is everything you know about users trapped in someone’s head? If what you know about users isn’t documented anywhere, it is impossible to come in as a new UX designer and figure out what to prioritize.
For UX processes and people to thrive, you need to start measuring things to have a baseline and evaluate future progress. Specific metrics depend on your business and its goals. This is an excellent example of how bringing in UX experts for an objective assessment can benefit your organization.
True: A solid UX design cannot be built based on undocumented assumptions at your organization.
False: “We don’t need to user test. We already do testing.”
Testing means different things to different people. Additionally, there are different types of testing. One person on your team might assume that testing is Quality Assurance, and someone else might assume that testing is User Acceptance Testing.
For UX people, testing usually means user testing. User testing is not testing code to see if it works as intended; it tests a design with actual users (no more than five per test). Those designs can be any fidelity, and some UX people test with paper prototypes. And just because a design is being tested doesn’t mean there won’t be data behind the results. User testing often means measuring the time it takes to complete a task, rating a design using a 1-5 scale, or many other metrics.
Another notable thing about user testing is that it is not just a “one-and-done” type of test. User testing is an integral part of the UX iterative process. The more tests you do, the better your product will be upon release, AND the fewer fixes will need to be made post-launch.
By measuring results such as fewer post-launch fixes, you will see the benefits of your UX investment over time.
True: User testing goes beyond just testing if the code works; it tests the design with your actual users. It helps ensure your product will need fewer post-launch fixes.
The more tests you do, the better your product will be upon release.
The truth: How to get the most out of your UX
UX expertise is necessary for product development, but as mentioned above, it can be a wasted investment if everyone in your organization is not aligned. Before making a significant investment, consider the following:
Take a baseline of your metrics. You will need ways to measure UX design success. Think about which metrics could be moved if your design was better. Here are some examples to get you started:
- Fewer calls to your help desk
- More renewals
- Higher product adoption
- Higher deal win rate
Don’t treat designers like special snowflakes. Many designers started as developers. Integrate them with your product and development teams as much as you can, as early as you can. Products move faster and smoother when designers, product owners, and developers are on the same page instead of throwing work at one another over an imaginary wall.
Think about how your product got here in the first place. Do you want to continue with the practices that got your product to a place filled with stagnation and “we’ve always done it this way?” Hiring a designer may initially sound simple, but doing so commits your organization to doing things differently. Designers are there to ask hard questions and to get to the root of changing an organization to become more user-focused in place of feature-focused. Is your leadership ready? Are you ready?
