Key Takeaways
- Consumer-grade UX is a game changer for enterprise SaaS.
- Starting at the team-level means starting today, not someday.
- Don’t work in a vacuum. Understand the business, the product and what customers and end-users like and don’t like about it today.
- Turn end-users into advocates. Connect with them early in the process, check in with them regularly and track their satisfaction.
- Keep iterations short and build momentum as data starts coming in.
Modern enterprise applications need to care about the end-user if they wish to thrive in 2022 and beyond. Many enterprise application companies are now using the same UX concepts once reserved for their consumer cousins - and for a good reason. Companies that implement this concept, commonly called “consumer-grade UX”, have consistently outperformed their more drab competitors in end-user adoption rates, end-user advocacy, workflow efficiency, market share, and revenue.
Why
In the distant past (i.e., early 2000’s), the UX of enterprise applications was not considered a significant adoption or sales driver. Managers looked at feature sheets, compared the cost of different services, carefully weighed the pros and cons, and, finally, made purchasing decisions based on which salesperson responded the fastest. Users would adopt because their boss told them to, and that was that.
But something changed around 2010. Slack launched and, fast forward to 2014, overtook the then incumbent Hipchat by Atlassian (yes, the JIRA folks). Many other companies - Dropbox, Asana, Google, etc. - started making a similar decision to Slack’s: applying the same principles used to provide consumers with a great user experience to their enterprise applications.
The user became the decision-maker. The brilliance of those companies in exchanging the UX equivalent of a gas station for something people like to use was twofold. First, because users are more efficient and effective when using systems that are well designed; second, because end-users become advocates within their companies to adopt solutions that they like, especially if they used them before. These factors, combined, transformed those brands into professional household names. In Slack’s case, they became a verb.
There are two cases where these UX overhaul projects tend to be required. First, established companies who wish to serve their customers better, have new leadership with new ideas or have modern, nimbler alternatives eating their market share. Second, fast-growing startups that have optimized for implementation speed at first to prove their product-market fit, but now have mounting design debt and increasingly less forgiving users as they move past the early adopter category.
How
Implementing consumer-grade UX in an existing product is resource-intensive, time-consuming, and presents considerable risk (“why change a winning team?”). Decision-makers may see such investments as a waste of time since they take time away from developing new features, improving software quality, and fixing bugs.
It is possible to execute a full scale UX overhaul top-down, with extensive redesigns and long term plans involving multiple teams. These projects, however, require a lot of organizational will, support from upper management, upfront investment and other luxuries. We are not going to focus on those.
Instead, let’s focus on something that any team can start today: kickstarting a UX revolution, one iteration at a time. There are four main phases to making that happen:
- Understand the status quo.
- Design a workable solution and get buy-in.
- Execute a pilot test.
- Iterate and build upon the momentum.
Learn & Understand
The first step is to understand the business, the application, the current limitations, and the end-user before going to the drawing board. You need to answer who your customer is, your end-user, what you are selling them, their key objectives and critical tasks, how much they are paying you, and what contributes to your cost.
Many good consumer-grade UX overhaul projects never get past the initial concept phase. As tragic as that may be, decision-makers are not necessarily wrong. I have seen many engineers, product managers, and designers develop idealistic proposals that get fast-tracked to the “maybe” pile and, then, into oblivion. The two major problems of such proposals are that they either don’t solve real problems or fail to speak the language of business.
Competent decision-makers are always thinking about serving their customers better - and getting more value from them in the process. If you want to grab their attention and obtain their buy-in, you need to show that you understand the status quo and discuss changes in terms of OKRs, KPIs, ROIs, roadmaps, and more.
Start by learning about the business, the product, the customers, the end-users, and their pain points. One way to do that is by talking with product managers, senior engineers, customer support managers, and, in startups, the founders. As questions like what are you selling? Who is buying? Why are they buying it? What is the price structure? How much does it cost for you to provide those services? Who is the user? What are the major tasks that they need to do?
Another valuable source of information is your data. You want to analyze two types of key performance indicators (KPIs): lagging or output KPIs and leading or input KPIs. The first type tells you if the users got what they needed, and the second tells you if they are having difficulties getting there.
Examples of output KPIs are the Net Promoter Scores (NPS), the System Usability Score (SUS), how many key tasks are completed in a given time, and the cost per key task. Examples of leading KPIs are the time it takes for users to accomplish key tasks (and their error/rejection rate). You need both types of KPIs. If you lack some (or all) of them, start by working with teams to begin implement tracking them.
Pro-tip: put a lot of thought into capturing human KPIs associated with how much users like using the application. Don't underestimate the power of joy. One of the core differentiating factors in early Slack vs. Hipchat was how easy they made it for users to find and send animated GIFs.
Here’s a real-world example: I led the engineering team at a fast-growing AdTech company in the US that operated a DSP (Demand Side Platform). Our customers were marketing agencies and major brands with in-house ad teams. Our end-users were their ad operators and campaign managers, who used our product to set up digital campaigns, track their progress, make adjustments, and report on their outcomes. Main KPIs were the time to set up campaigns, the freshness of our analytics, time to generate reports, and on-target delivery rate.
The folks driving the frontend part of the project did such a phenomenal job and cared so much about great UX that we won the 2015 UX People’s Choice Award.
Design & Sell
The next step is to design a workable solution and get the buy-in of the necessary decision-makers. Start by using your business knowledge to identify the most significant challenges with the highest potential for impact. Those are usually connected with your lagging and leading KPIs and aligned with the main tasks the end-users have to perform.
Pick the highest ROI challenge you deliver and focus on it. Impact defines the return on investment (ROI), and the implementation cost defines the investment. It’s essential to pick a meaningful problem so that fixing it matters and pick something manageable so that you can deliver. If this first iteration fails, the whole process could fizzle out. Choosing a specific problem to focus on allows you to start now and not after a lengthy planning and review process. Finally, make sure that this is a two-way door decision - i.e., one you can reverse without significant impact to the business in case things go awry.
Once you have chosen a challenge, identify its end-users, their pain points, the KPIs you need to improve and work backward from them to design a minimum lovable solution. The key to moving fast and adapting is the Build-Measure-Learn iterative cycle - build something, see how it works in the real world, learn from the experience, rinse and repeat. At the same time, since you are explicitly addressing UX, go the extra mile between viable and lovable.
At this point, you should have a workable design based on a concrete understanding of the underlying business mechanics and end-user needs. It should also have measurable targets on meaningful KPIs. The final step is to get the buy-in from stakeholders.
To successfully pitch the project to whoever you need to get the buy-in from - a product manager, engineering manager, teammates, etc. - you need to tell a good story. Start with the why: show what problems you are solving and why they matter in the business context and current objectives. Then follow on to the expected impact, what the solution will look like, and, finally, how much time/money/people it will take to make it happen. Many of the same rules of pitching a new business apply here.
Pro-tip: consider the timing of your change. Pitching a UX-centric change at the wrong time - for instance, while the team is dealing with a major technical problem or going through a security audit - can come across as tone-deaf and likely won’t get you the full attention of the people you need. Use your best judgment, but examples of good times to pitch are right after a successful release, during quarterly planning, or while having a coffee with a product manager (never underestimate the power of a 1o1 coffee).
In my previous example, we found that our initial approach to the setup of ads by operators, which was on par with the rest of the industry, was cumbersome, repetitive, and error-prone. Operators have to set up dozens - sometimes hundreds - of ads in a short time, and even minor mistakes at this stage can lead to a lot of time and money wasted. I’m pretty sure an LA restaurant doesn’t want to run their ads in Australia.
We overhauled this process by improving the UX of the forms involved and adding lots of automation. We made some sections optional, implemented a multi-stage process, and added features like restricting the search of cities based on the selected country/state and support for importing bulk ad configurations directly from customers. These changes resulted in a significantly lower time to set up ads and campaigns, fewer setup mistakes, less wasted marketing budget, and happier, less stressed operators.
Pilot Test
You have understood the business, designed an awesome solution, and gotten the buy-in you needed. The next step is to execute it.
Think of the first consumer-grade UX change as a pilot program. Ensure that you have all the necessary tracking in place, especially for the core metrics you are trying to improve. Automate as much tracking as possible using tools like Google Analytics, Hotjar, Kissmetrics, Data Dog, and others. However, if automation is not possible, don’t let that stop you - find ways to manually track the numbers you need, even if you need to flex your Excel skills. Don’t run blind.
Pro-tip: get regular feedback from willing end-users to get their qualitative perspective. Numbers alone tell you only part of the story. You need quantitative and qualitative information to understand what’s going on.
If possible, run your pilot as an A/B test using the old version as a baseline. A/B tests ensure that you compare apples to apples and that any improvements - or problems - are coming from the new design.
Prepare to iterate fast as data and end-user feedback starts coming in, and don’t let your biases cloud your analysis. Understand what the data is telling you and plan your next changes accordingly. These changes could be minor or significant, depending on your results. Either way, plan according to your time budget, keep stakeholders informed, act fast and keep a changelog of what you are doing and why you are doing it.
In my example, we had not originally planned on introducing bulk ad imports so early on. We had to move that feature up the schedule during the overhaul project once it became clear from operator feedback that improving the input process was great, but it was not enough. Operators had crunch times (ex: when first setting up large campaigns), and, as it turned out, they already had a semi-standard file format for describing ads in use.
Iterate & Keep Going!
Consolidate your learnings once the pilot is over. Interview customers and end-users to get their holistic perspective on what you implemented. Collate the information from your changelog and understand what worked (and what didn’t), why it worked and why it failed. The full picture will help you determine if this change was successful and going in the right direction.
Independently of whether the pilot worked and you achieved your objectives, present the results, learnings, and conclusions to the team and key stakeholders. This will build credibility and establish a solid shared knowledge foundation to build upon.
Look at the big picture and think about more systemic changes. Your knowledge from the pilot taught you more than just how to do better in the next iteration - it showed you a glimpse of patterns that can scale-out throughout the application. Start creating an overarching vision and toolset that can tie everything together and create consistency across your future iterations. This can include a common design language, consistent form elements, use of shortcuts, when to sync wait or run a background job, etc.
The pilot is not the end - it’s the first step in your revolution. Capitalize upon the momentum of this first iteration, factor in what you learned from it, and pick one or more high ROI challenges to tackle next. It will be easier to pitch them this time as there are fewer unknowns. Don’t stop now!
Conclusion
You can start a consumer-grade UX revolution at your company today. You don’t have to make a big deal out of it or let analysis paralysis shackle your team. Kick that off by understanding your business, designing a solution for a high-impact-but-still-deliverable case, pitching and getting the buy-in you need, running a data-driven pilot program, and, finally, using the momentum to build a vision and tackle the next challenge.
We were at a very technically focused moment in our DSP when we ran our first UX overhaul iteration. We had to process 100K+ transactions per second, run complex planning and ML algorithms in milliseconds, and create analytics data pipelines that processed multiple terabytes of data per day—all with a startup budget and a small (but plucky) team. UX was not our focus, and we were content with following the competition in that regard. Our first pilot test changed that for engineers and executives alike.
It was, quite literally, the spark that ignited a revolution.