In-Depth
Has the Usability Revolution Left Enterprise Software Behind?
Three steps every product manager can take right now to overcome roadblocks to user-friendly software design.
By Scott Plewes and Didier Thizy
Like the rest of the industry, many enterprise software companies invested in product management and design teams over a decade ago. Although most other applications have evolved to be more user-centric, enterprise software -- including enterprise resource planning (ERP), supply chain management, and specialized information management software in fields such as accounting, HR, and legal -- have mainly stayed rooted in the design principles and esthetics the rest of us left behind.
Why do intelligent, experienced, and educated designers and product managers produce software that frustrates their user base?
This is an important question, especially as the focus in enterprise software shifts from features to usability, and the routine of the Enterprise user evolves from "in the office, 9-5" to "anywhere, anytime." Vendors must adapt the user experience (UX) of their products to deliver value in new user contexts.
Why Are Enterprise Systems Notoriously Hard to Use?
To get some answers, I canvassed three different groups in my social network: product managers, designers, and ERP professionals. Many of these people actually work for ERP and enterprise software organizations. Their feedback identified six major roadblocks that enterprise software teams face when making significant updates to their software.
Roadblock #1: Enterprise buyers aren't users
With ERP, the people who buy the software often aren't the people who use it. This divorces users from decision makers, so often usability isn't a factor in the buying decision. Senior management's criteria might include features, cost, and the vendor relationship. The only thing on the list that the user cares about is features, but what good are features a user can't find, understand, or use?
Roadblock #2: Architecture constraints
If enterprise solutions look like something out of the 1990s, it's often because that's exactly what they are. These applications started as programs designed by software developers, not UI designers, and focused on the power of computing, not end users' needs. It's not a software developer's job to investigate the environment, constraints, and psychology of the people on the other side of the mouse. The programmers did their jobs and did them well, creating the features that give enterprise software the power it has today. However, that doesn't mean the design of the application holds up to today's standards, not to mention the environmental changes that have happened in computing since enterprise software came on the scene.
Roadblock #3: The risk of alienating the established user base
Having an established customer base pays the bills, but it discourages change. Any improvement you make is likely to affect someone who pays for your current product. Long-time users become so engrossed in the processes they know that they feel any change disrupts their way of doing business. They're likely to be irritated and very vocal about things they feel affect their bottom line, even if it benefits them in the long term. There are proven techniques for updating, and even overhauling, a major portion of an existing software system, but many organizations still view this as a risk and put it off as long as possible.
Roadblock #4: Incomplete/understaffed design/product management teams
Enterprise software has traditionally been sold by features, so ERP, BI, and other information management companies have generally allotted the majority of resources to the development checklist and ignored design. The unfortunate side effect is that companies increase investment in feature development and focus less on ease of use. The result is project management and user experience teams that are chronically understaffed, under-funded, and siloed from the development process.
Roadblock #5: Too many user groups, too many features
One of the people I spoke with said that some ERP systems reminded him of the guy in the office who tries to please everybody. He runs around trying to accomplish every request, leaving a trail of apologies in his wake. Information management systems and ERP applications in particular often try to be all things to all people instead of focusing on a specific set of primary users and a select number of usage scenarios. The result is the Microsoft Word phenomenon; feature-heavy applications in which 90 percent of the users utilize 10 percent of the features -- multiplied several times over.
Roadblock #6: Designing solutions to be customizable from the outset is a huge challenge
Traditionally, enterprise software companies, particularly ERP vendors, have designed their products to be as customizable as possible -- making them as generic as possible, and inherently less usable than software designed around a specific target user group. When you can configure everything, the level of abstraction becomes very high. From a technical standpoint, enterprise systems are basically platforms on which to build solutions. The interface is based on patterns in the data, regardless of what the data represents. For example, in the data, a "customer" entity cannot be distinguished from any other entity. The result is generic edit screens, generic flows, and generic interactions that are often far removed from a billing specialist, lawyer, or accountant's actual context of use.
Three Steps Every Product Manager Can Take Right Now
Now that we've explained the common roadblocks, we offer three recommendations that product managers can act on immediately to bring enterprise software into the now.
Step 1: Define your evolution path based on rigorous user research
Do you know what specific aspects of your user interface would yield the highest return on investment (ROI) if you updated them? Often it's the usability and flow of screens such as dashboards and main pages that users interact with on a daily basis to accomplish their primary tasks. The issue could lie in the overall "wow factor" of the application that will attract new clients.
The only surefire way to discover this information is to conduct the appropriate user research, such as a series of usability tests, contextual interviews, or ethnographic studies. Proven research should guide the evolution path, not just internal stakeholders, user forums, or large-scale surveys.
Who are the primary personas for the evolution of the product? As we discussed, Enterprise Software systems are often large and complex because they serve too many types of users -- sometimes 20-30 different groups -- without prioritization. As a first step, we recommend clearly defining user personas and then using this information to select the main targets to guide the product line. Don't forget the mobile and SaaS versions.
Make part of your research observation-based: Talking to end users is necessary to glean true customer insight, but it's not enough by itself. You need to put the ideas you get from talking to customers into a wider context. You do this using data from other research techniques, particularly observational research -- watching users work with the product in their real-world environment and understanding their unspoken needs. Often, what users say they want and what they actually need are different. Proven user observation techniques are the key to discovering the latter.
Don't reinvent the design wheel: Current industry leaders have shared many standard design and interaction patterns. Although this is no substitute for user experience professionals and won't help you innovate beyond the competition, they are a fundamental starting point.
Consider what will happen if you don't change: Examine the risks of updating your product, and factor in the risks of not making improvements into the equation. Staying with the status quo might look like the safe option, but if you want to grow your user base when potential customers increasingly expect good design, not updating might be the bigger gamble.
Step 2: Get a technical analysis to determine your options
As we have discussed, one of the biggest constraints product teams face is the existing code base and software architecture. The code base is often a tangled mess of legacy "spaghetti" code, silos (separate tables that can only be retrieved independently), and most recently stateless protocols that are not aware of what is happening in different parts of the screen.
All of these architectural structures served a technical purpose as the product evolved, but all are now hampering improvements to design and usability.
The plan you put together to evolve this code base is critical. It will affect timelines and costs for feature or design updates as well as and migration to new platforms (such as SaaS and mobile).
Assess your ability to develop an API
One of the first things your team should examine is the ability to put all the system's business logic into a separate code layer and wrap it with a clear API. In a legacy system, the business logic is often the biggest opportunity for code encapsulation and re-use because it contains rules and exceptions that have evolved over the history of the product.
Once you have a well-formed API, it can power new features, design changes, and extensions of the product onto new platforms.
This is easier said than done. Frequently, the UI code is intertwined with the business logic. Plus, if the code structure doesn't use proper relational database design practices, data manipulation code may also be intertwined with the business logic -- and that's assuming it's a relational database in the first place.
Your unit test or automated test framework is where your investment will pay off as you update the code to a more structured format with an API.
The new system should be designed with most of the code placed in a common API. This allows you to keep your desktop, Web, and mobile clients as thin as possible, minimizing the investment per platform.
Step 3: Get your product managers, designers, and developers working together as one team
For any software organization serious about competing in the shifting enterprise market, the biggest key to success is getting the right design, product management, and development competencies working together as one team with a common goal -- amazing software that doesn't just aim to be first-to-market but best-to-market.
Poor software execution is often the result of structural and process-oriented problems. How many times have you heard "The product manager presented a great-looking product concept, but the final product just didn't live up" or "Our developers are really frustrated with the designers. Their designs are blue-sky dreams. They just aren't realistic."
If you have a major redesign or new product release in the making, these struggles will cost your organization time, re-work, and missed opportunities.
The Bottom Line
In the end, when we consider whether the usability revolution left enterprise software behind, it's clear that enterprise might be a bit behind -- but the revolution is far from over.
Market analysts agree that the demand for modern enterprise software is snowballing, particularly on new platforms such as tablets and in new contexts such as domain-specific software. Vendors who adapt fastest to the changing market will gain ground over their competitors.
Moreover, enterprise software development companies will no longer be able to sell their products solely on the back-end power of how they manipulate data. Usability isn't optional anymore. The people who buy their software will increasingly recognize good design as a necessary feature that saves huge amounts of money in training costs and lost productivity.
Scott Plewes, vice president of user experience design at Macadamian, is an expert in user experience design, user research, and incorporating the voice of the customer into product design. He has almost 20 years of experience in user interface design, working in both the public and private sectors. Scott's design skills cover the spectrum from desktop, Web, and mobile user interface design to command-line and telephony interface design. Scott can be reached at scott@macadamian.com.
Didier Thizy is the director of marketing at Macadamian. A software professional for over 12 years, he holds a variety of positions in software R&D, product management and marketing. Didier is responsible for new market strategy, development, and channel/partner development. His focus areas include healthcare software, modern enterprise/ERP systems, and mobile applications. Didier can be reached at didier@macadamian.com.