You show up to your local bakery before your party to find a three-tiered coconut cake flanked with pineapple rings and "Happy Birthday" smeared into coconut cream icing. "What do you think," the baker eagerly asks?
You reluctantly look at coconut flakes—keeping a straight face—as the baker continues, "It's just perfect for your luau party, right?"
Except you hate coconut.
End of story, this entire cake is in the trash. Party-goers are settling for a generic, store-bought cake.
When it comes to enterprise software, many companies often build their product first, and then present it to their team for testing later, much like our well-intentioned, over-eager baker.
But why? Enterprise software is not a piece of cake. There are no simple, "coconut versus red velvet" decisions. There are hundreds of features and attributes to consider. And there are millions of employees who don't have the option of kindly declining software they don't like.
Often, in the face of pressure for profits from executives and stakeholders, companies quickly develop software aimed at increasing output and efficiency without really understanding how every employee and customer will use the products. And often the software is trashed even before it is completed. For some companies, the rate of wasted software can be as high as 15 percent of the time. As the IEEE article, Why Software Fails points out, this is not a small figure: it could mean hundreds of millions of dollars and spell bankruptcy for less established ventures.
Fortunately, enterprise software is less likely to be trashed or half-baked with the help of user research.
Regardless of the approach to user research—whether it's ethnography, user interviews, focus groups, prototype testing, or a combination thereof— there is a common goal: to produce the insights that get a software project moving in the direction of success.
Here are four reasons for user research in enterprise software.
We get it. You're busy. Quotas have to be met. And increasing output with better software is a top priority.
It's tempting to go straight to the development team with a list of priorities developed alongside stakeholders during a meeting. While you all have brilliant ideas to throw into the mix, any unvalidated assumptions can become kryptonite for the project if they turn out to be incorrect. What if a baker made a walnut cake without knowing the client had a nut allergy? To say that the resulting anaphylactic shock was a bad experience would be an understatement.
Fixing software problems based on incorrect assumptions is expensive and time-consuming. Developers returning to the code again—and again—to fix these problems drives up project costs and moves deadline dates further out of reach.
|User research catches incorrect assumptions before they enter into the design strategy and into the code.|
Talking to and observing your target audience beforehand through user research goes a long way to catching incorrect assumptions before they enter into the design strategy and into the code.
"But we avoid incorrect assumptions by using a design firm," you may be thinking. "They're the experts on understanding people and users."
Thanks for believing in us, but at the end of the day we as designers have to be humble. Without taking the time to get to know your team and the people who will be using your products, we're just cooking up assumptions too.
Much like a recipe for baking a cake, every single person has a certain formula they follow in accomplishing their workday tasks.
User research yields insights into your team members' recipes for success at work, as well their stumbling blocks as they try to accomplish tasks. Identifying the ingredients that make up the workplace experience—goals, pain points, primary tasks and secondary tasks—is essential to delivering a product that is intuitive and efficient.
See how we got a new product validation by implementing the product roadmap centered around effortless customer experience.
|The recipe for great enterprise UX: know all the ingredients of the workplace experience-goals, pains & tasks.|
And, let's face it. Your design team and developers are responsible for various line items in your software project. Discovering these essential ingredients from the start saves time and money.
According to the same IEEE article, the cost of fixing a software error after a project is complete is 100 times more expensive than if it's addressed beforehand. A baker would have to present you with every cake option to even approach this kind of waste.
It's not just the costs that can topple a company... Fixing errors after the fact often yields software that looks and functions like a baker's attempt at turning one type of cake into another: the Leaning Tower of Red Velvet with pineapple slices still hidden behind buttercream icing.
User research yields actionable insights into the actual features that your team members need, so the developers build the right features from the start. So, there's no wasted time devoted to developing useless features like an expensive wedding topper for a birthday cake.
In addition to uncovering the ingredients, good user research yields the insights needed to craft the recipe that will be perfect for users and satisfy the taste buds of even the harshest critics (and your stakeholders).
User research helps us to separate the ingredients that are essential for accomplishing tasks from the ones that are helpful or just nice to have. For example, if we know 70 percent of people will spend their time eating away at the bottom layer of a three-tiered cake, and only 2 percent of those people will lick the icing, we know we need to give more prominence to designing the cake layer.
Similarly, people may want expensive gold flakes on the icing. User research gives us the data to know that the flakes are a bad use of resources, since only 2 percent care about the icing anyway.
In the early stages of our design process, we create user stories to paint a detailed picture of the people who will use your software. We look at everyone, including your stakeholders, your employees and their varying roles. Here, user research acts as the artist guiding the paintbrush to create realistic pictures of your spectrum of users, and why they use your software.
When companies opt to skip the user research stage, designers are left with a superficial understanding of why their users need a product. This superficial understanding is often what leads to products that over-rely on tiny, useless features to create the appearance of "meaning." The delivered software becomes the equivalent of a baker fulfilling a request for a 50th birthday cake by drawing black balloons on a ready-made cake. Product redesigns are labeled a success with the addition of superficial UI features, even though the user flows are still no more efficient or better aligned with how employees feel as they go about their work.
Understanding why everyone on your team uses the software results in design direction that not only complements the context, but is all-around meaningful.
|Meaningful enterprise UX comes from understanding why each person on a team uses the software. UX design|
In closing, skipping or skimping on user research can have a negative impact long-term. A luau party with a birthday cake is only a few hours for a few people. If you get a bad cake, you can move on to the next party and hope for a better cake. But imagine thousands of workers feeling stuck with the same bad cake that gets more stale with each passing day... That's what a bad experience with enterprise software feels like.
It's not hard to believe that an office kitchen with cake that people actually like to eat improves workplace culture. Similarly, consistent user research can change the culture for the better. It lets employees know that you care, you listen, and that each person's success is what translates into the company's collective success.
So, don't just let them eat cake.