OMS Projects: 3 key ways to reduce risk and ensure success

Learn more

Enterprise Order Management UX: 4 points to consider

Focus on the users in “User Experience”

Enterprise Order Management UX: 4 points to consider

By Toya Lazarevic

Dec 7, 2020

As a UX professional, my goal is to create the best possible experiences for the people who operate enterprise software like Order Management Systems (OMS). The bulk of what I do is to improve the actual software screen interface to make it as easy as possible to use. After many years in designing experiences for banking, marketing and now order management internal business applications, you learn that the most important UX principal is to focus on the people who operate the software day in and day out: the users. But not all users are alike.

Users of B2B software are very different from B2C users. In this article we’ll explore some of the unique challenges we face when designing B2B experiences. By keeping the end B2B user in mind, businesses that purchase enterprise software will be more successful with the entire project—from choosing the right software to ensuring its best implementation. Before you select your next enterprise software, you should consider how the process will be improved leveraging your internal experts.

1. Choosing the right software: Buyers aren’t the users

One of the challenges of enterprise software is that people who use the software are rarely the people who make purchasing decisions. This can cause all kinds of problems if not addressed directly.

Sometimes this is a conflict between how leadership wants its processes run and how the actual users prefer to use an application. A recent example happened while we were conducting Discovery for a store fulfillment application used by retail assistants to pick, pack and ship orders. According to leadership, staff should process only one order at a time. They believed this would reduce potential errors. The store associates, however, wanted the ability to pick and pack more than one order at a time. This would save them time and effort by reducing the amount of screen time they’d spend on each transaction.

If you were running this project, which choice would you make? Here’s how we approached it.

  • Provide flexibility. Give only certain users the flexibility to choose how they want to use the application. You can do this through providing them with advanced user permissions. The business can then select the users they trust to create a wave or oversee a staff member pick multiple orders at a time.
  • Conduct user research. Many businesses do not do user research with their employees so it’s hard for them to know what exactly they need or want. That’s where businesses like Fluent can add value through time-tested approaches to testing. Taking the pulse of the B2B users is as important in the product selections stage as it is during Discovery.
  • Include your users in the purchase decision. Before investing in an application, invite your users to participate in the sales pitches so that they can provide feedback around whether the application fits their actual use cases.

2. Discovery: Ask the right questions—from the right people

The Discovery process for onboarding an enterprise software is where the rubber hits the road. Not only do you need to address complex issues like feature parity between new and old products, you also need to ensure that you’re getting the right answers to each of your questions. Here are a few pointers on how to ensure a successful discovery process.

  • Extend client relations throughout the organization. As a B2B UX designer, I find it is often difficult to get quick access to the right users because most of the time account manager and sales own the client relationship. It is recommended that once a project kicks off, get the account manager or sales person to introduce you to their clients so that you can start to build that relationship with them. In the B2B space it takes a bit of time to establish a relationship with the client in order to feel comfortable enough so that you can go to them directly when you need to interview or conduct user testing with their employees.
  • Achieve feature parity. No one understands the features of your legacy software better than the actual users. If you want to develop systems iteratively and in an agile way, users will need to use old and new applications in parallel for some time. There simply can’t be a period of time where the users don’t have the features they need. Another approach is to build a new UI on top of the existing software. However, there will be a period of time where the new screens will look different to the old screens so consistency in UI and UX may be a challenge for a period of time. We typically conduct this phase with a small subset of the business to work out any kinks without impacting the larger ecosystem.
  • Design with simplicity in mind. As experience designers, we tend to create the simplest interfaces possible. With complex systems, however, too much simplification can cause major efficiency problems. Sometimes aesthetics needs to suffer in order for UX to succeed.

This happened recently when conducting user testing on the designs for Fluent’s new Order Management app against a legacy system. In the old UI, all the user actions were visible at the top of the page. It looked clunky and confusing. And as all good designers know, in general clean, simple interfaces reduce cognitive load and let users focus on the task at hand. But in this case, there were limits.

After the design was updated and all user actions placed under a “more” button, nearly every user tested was unable to find the necessary actions. They preferred to see all the user actions so they could quickly scan for the one they needed in order to answer customer queries. Lesson learned. Although it is always important to stay on top of new UI trends, make sure to always ask yourself whether these trends are suitable to your business users and for the tasks they are trying to accomplish. In some cases, a focus on simplicity and beautifying the UI can actually harm the UX for the end users.

3. Designing the experience: how to balance flexibility and custom configurations

When designing B2B applications like an OMS, flexibility and customization are two sides of an important coin. Flexibility is needed to support multiple user journeys. Customization supports use cases unique to the business. Emphasize one more than the other at your company’s peril. Here are some ways to ensure a balance between the two. And, yes, it means engaging with the actual users of the software.

  • Not all users are created equal. In B2B environments, unlike B2C, there can be many types of users. Store associates who occasionally use the software will have different needs than supervisors who are power users. To support this, we create a flexible front end that has multiple entry and exit points to allow users to do their specific jobs. In a B2C application, you don’t want to expose features that aren’t used by all consumers. In B2B, there may be a lot of settings most users will never use but they need to be there for the power users.
  • Not all businesses are created equal. Depending on your industry, company size, business model or sales volume, you might need very different features from an enterprise software than other purchasers of the same program. As a result, you’ll probably want to customize the software to meet your unique business needs. Customization is a wonderful thing, but too much of it can cause unforeseen problems. With a SaaS product in particular, customization means that you’re abandoning feature sets that have been validated by other customers. The Fluent solution is to provide a configurable flexible framework where any business can add or remove whatever features they want. We call this “constrained flexibility.” With a strong, guided UX you shouldn’t need to reinvent the wheel unless you have really unique use cases.

4. Measuring success: Be sure to capture accurate data

Capturing accurate data about a new enterprise software is more complicated than it sounds, for a couple of reasons.

  • Heatmaps don’t work well for SaaS applications. Because Fluent offers a flexible framework, every client uses it differently. With so many instances of the platform among different clients there is no one source of truth that can be illustrated by a single heat map. You can still gain insights based on your own company’s usage patterns. For instance, we found that the most clicked on user action for one client was the “add comments to the order detail page.” That influenced our designs to make “add comments” more discoverable in a tab.
  • Data isn’t “real” during the prototype phase. Prototypes are great for testing out usage patterns, but since they’re not connected to the back-end, they don’t collect meaningful data. That doesn’t mean that prototypes don’t provide value. The value is in observing how users interact with the prototype and the questions they ask as you observe them. When people are faced with a new design after an old one they have lots of questions. Even if they’re looking for a feature that’s not available, you can still capture that desire.

As I said at the beginning, the most important UX principle is to focus on the people who operate the software day in and day out. When you’re considering an enterprise software purchase, be sure to identify the people in your organization who will use the system. Invite them to the table during sales presentations, when you’re evaluating feature sets, and most importantly, as you design the experience.

7 Reasons to use a Best-in-Class Order Management System eBook

Get the Guide


Learn how a best-in-class Distributed Order Management System can help you overcome inventory visibility challenges and provide a delivery experience your customers will love.

This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.