%20Created%20Equal.png)
%20Created%20Equal_mobile.png)
When companies invest in a new enterprise application, especially one that overhauls a critical organization-wide process such as their product management, the ultimate KPI is user adoption.
This massive investment doesn’t just encompass cost, but also the considerable time, energy, and resources spent in making it successful for their business needs. This includes training business users, continuously pushing user engagement, and not to mention enduring a typically lengthy implementation cycle.
Of course, all of this effort is spent in anticipation of a significant ROI in not only the company’s profitability but in the improved experience for its users.
So why does user adoption so often fall short? Most enterprise applications are designed for a power-user experience. While this is important, a vast majority of the users only need a subset of functionality. Inevitably, you’ll lose these users if the application is too complex for their needs.
What is deep work versus quick work?
Simply put, deep work refers to all-day, everyday projects, while quick work refers to brief, less frequent actions within the same application—but both are equally required to move forward in the product cycle.
If you think of your enterprise application as a cave system, it is easy to understand what we mean by “deep” work. Take a miner spending his entire day excavating a complex tunnel system he’s become very familiar with. The “quick” work might typically be done by his foreman who primarily stays outside, only going in for occasional inspections.
A more familiar example would be with regard to an enterprise HR system such as Workday or Rippling. HR and finance folks are on this tool daily for many hours (deep work).
However, the rest of the employees may need to access the tool only occasionally, such as to file PTO, download their tax documents, or complete required training (quick work).
Finally, if we move our analogy to the realm of product development, let’s consider a mechanical engineer named Tony.
For Tony, deep work would typically happen in a computer-aided design (CAD) system because that's where he spends his time designing; it’s the tool he is using day in and day out.
Tony is designing a complex sub-assembly that contains many other component parts using CAD software. He needs to provide part numbers for each component, and in order to reserve those part numbers for his components, he needs to log in to the PLM system and generate them.
In this use case, part number generation is the quick work that supports the CAD design—the deep work.
All of this is vital to understand because they impact those two key things: user adoption and engagement.
And for critical enterprise software that serves as a system of record, it is imperative for the system to be the single source of truth for the product throughout the entire development process, end-to-end.
When you’re covering that big of a process, you’ll have many different types of users along the way, and it is critical to cater to as many as possible.
Some may be doing deep work in the system, and others may be touching it every now and then, but all of it is still essential. Quick work users play an essential part, even if they're not in it on a daily basis.
Designing for the few leaves out the many
Now that you have an understanding of deep work and quick work, let’s dive into why it’s so important to know the difference between the two.
When product companies are shopping for a new enterprise application and considering a hefty investment, they have to be wary of whether that tool is just as easy for quick-work users to adopt as it is for deep-work users.
Too many of the common product management tools on the market are intrinsically designed for for deep-work users—sometimes called power users, or those who will be in it on a daily basis.
Let’s say for argument’s sake, it’s an 80/20 split between quick work and deep work use cases. If developers are solely focused on making a system work well for the 20% of power users, that means that system’s user experience ignores 80% of the business users.
If it's not intuitive for somebody who's in the system every few months because it’s been designed with a different type of user profile in mind, the training that's required to use the system is likely to be untenable.
Let’s look at some of the consequences when the barrier for use is too high.
1. User overboard! (or, more likely, many users…)
What happens? The quick-work user might circumvent the system. They might find a workaround because they can’t figure it out, or they feel it takes too long to complete their task.
So instead, they create a separate spreadsheet, save documents in Google Drive, or send emails to perform a task they were meant to perform in the application.
In other words, you've lost that user.
And because that person’s contributions do not get included in the system—along with those of likely many others—the overall effectiveness of that system degrades as people find other point solutions and workarounds to avoid using it.
2. Your single source of truth? Not so truthful.
Your system is supposed to be a system of record. By circumventing and going around the system, the users who jumped ship end up creating silos of information.
The system of record gets less and less accurate—and eventually, your application isn’t as effective as the promise of the initial investment. Because the whole point, after all, was to keep the data stored in one place.
So, instead of a complete system of record, you have multiple, disparate places where important information is stored that needs to be visible to the organization but isn’t.
For instance, let’s take an example using sales and marketing teams. Imagine account executives (AEs) using an enterprise platform as their system of record for sales opportunities and leads.
Lisa, the manager of the AE team, is reliant on the information in the system record to make decisions about which opportunities to chase down and where certain prospects are in the pipeline.
But if the AEs feel ostracized by the complexity of the system or bad UX design—and choose to make notes in their own separate documents—that information never makes it into the record.
It follows that Lisa might be making the wrong decisions because the record didn’t give her the full picture, while all the critical data was scattered in spreadsheets and emails just because it was easier for those users.
In this case, not only did the team lose time and energy, the business itself lost out on important revenue opportunities.
This is why user experience is key, not just to make jobs easier, but for the make-or-break effectiveness of crucial business practices.
3. How much training is too much training?
We’re bringing a lot of heat on the developers, but most new tools—regardless of how intuitive the UX may be—often require adequate and robust training.
It’s important the company trains all their users, not just those who will be in the application daily for deep work. Especially, if they have users starting to jump ship, it’s clear the training hasn’t been done effectively.
But the thing is: if the tool itself is not adaptable for the different types of users, then everybody needs to be trained on the more complex user experience.
And that's a big ask. Complex training consumes a lot of time and money.
So what happens when the training required becomes far too much? And how can you solve this?
The Answer: Go Where The Users Are
When developers find a way to allow quick-work users to add to the system of record from their day-to-day tools such as Slack, they can continue the flow of business unimpeded. And they can do so without touching the platform.
With Slack integration—offered by modern cloud-based providers such as Propel— users can learn to use the new functionality very quickly as it's simply an extension of what they already know. Then they’re more inclined to use the system versus circumventing and finding a workaround.
By integrating the function of the enterprise system within common tools, we sidestep the user adoption training issue completely and just meet them where they already live.
They don't have to learn a different tool, thereby lowering the barrier for adoption.
Benefits of a familiar tool
For the application developers, the “Slack Apps” infrastructure is ideal because it’s already primed for developing a functional integration. The other side is the Application Programming Interfaces (APIs) needed to support the data that needs to be displayed within Slack.
The data we’re referring to here can include anything from change order requests, component information, risk management notifications, and more.
Here are some benefits for a quick-work user who is perhaps more familiar with Slack as a tool than the PLM application:
1. View actionable information. For example, if training is due this week or changes that are pending approval.
2. Perform quick actions, such as approving a change, viewing a training document, or requesting a part number.
3. Get notified about anything that requires attention from within the PLM application.
Let’s say a product designer who is collaborating with her supply chain team needs feedback regarding a design.
Instead of asking them to stop what they’re doing and navigate the PLM application to get to her design, she can send a request for feedback by posting a link to Slack. She knows her collaborators are in Slack all day each day, so she knows they will see it quickly.
Once the approving team sees the note and any context she included (such as relevant links and any questions), they'll be able to view the documents shared in Slack without logging into the PLM platform at all. They can just quickly review the question in context, and click a button to approve.
The magic of this integration is that it benefits both quick-work and deep-work users because those who are in the application all day long would also be using that integration all day long, while quick workers can access it faster without having to learn something new.
In this way, Slack helps favor the quick worker because it brings the work to where they already are.
By extension, this helps the business expand user adoption. Productivity is much higher and the barrier is lowered.
Avoiding a Slow Failure
As previously mentioned, data quality in your system of record depends on people adopting. And if people have to learn new tools in order to adopt, they’re less likely to actually do so, and that's a slow failure.
Slow failure shows up as “dirty data,” or poor data quality. And because it’s so insidious and occurring behind siloed walls, you don't find out about it until you've already built a product.
You realize perhaps that components weren’t scrubbed for supply chain risk, or you didn't get approval from the quality team because they never had complete information.
So once again, you’re risking more than just slower processes—you’re risking real revenue loss and decreased customer satisfaction.
Applications built with composable technology (such as Salesforce’s Lightning Web Components) allow the users to construct simple individual flows with only the information required and to present that either inside the PLM or inside Slack (whichever they prefer to use). Either way, it becomes a part of the system of record.
Similarly, when the so-called infrequent users of the system find it easier to learn and adapt by themselves—and it feels intuitive for them—they will continue to stay in the system. They won't circumvent it.
All this amounts to higher user adoption and user engagement, leading to an overall more reliable source of data, and a stronger ROI on the system itself.
To learn more about Propel’s Slack integration, contact someone on the team, or hear more about how to increase user adoption in the Converged Live webinar, How to Build Composable User Experiences Using Clicks, Not Code.
