Impacts of the B2B Business Model on User Experience
The shortcomings of enterprise-software user experiences begin with the way companies sell such products. In business-to-business (B2B) purchasing decisions, a salesperson or team generally makes a sale to a customer. Typically, the buyer is not the actual user of the product in question.
An organization, or enterprise, identifies an important business need and allots a substantial budget to address it. The organization spends a good deal of time and effort qualifying business needs, identifying possible vendors, creating RFPs (Requests for Proposals), vetting vendors’ responses, scheduling and sitting through vendor pitches, driving consensus toward the ultimate solution, and, ultimately, purchasing a product. They also spend significant time and resources drafting a vendor contract, paying the vendor, implementing—and perhaps customizing—the product, and training users.
While the software user experience may be a contributing factor in choosing a vendor, organizations rarely involve the users who will be impacted by the decision to purchase the software. In stark contrast to the business-to-consumer (B2C) model, the concerns of actual users are not really a priority when purchasing enterprise solutions.
As a consequence, the UX teams that support enterprise products are usually small—if they exist at all—and many lack power. Typically, there is an Engineering-led development process, in which developers often make UX-design decisions—acting as designers in addition to their other responsibilities.
But, if a design change affects how the user interacts with the product, a UX professional should at least review that change. Preferably, a UX professional should design the entire user experience. Changing settings, deciding what rows of data should appear in a table, and the creation of labels for buttons or links should all be viewed through a UX-design lens.
However, most of these developers are familiar with neither the user’s goals nor UX best practices. They are even less likely to consider individual design changes within the context of a larger design system. Developers have different problems to solve that are not necessarily complementary. With or without the direction of UX designers or design documentation, they need to build a solution. The lack of such direction typically results in explicit or implicit UX-design decisions that are less than optimal.
This situation can also lead to misguided technology and software-architecture decisions. For example, if developers do not know how a particularly complicated task should scale, they may build a system that becomes very difficult to change or even manage. Plus, when no one is really responsible for UX design, the need for a lot of costly rework may result. Questions that remain unaddressed up front often reveal themselves as gaps during the build process—sometimes very large gaps.
The issues don’t end here. Poor, confusing designs lead to extended communications with quality assurance, additional documentation to explain how to use unconventional interactions, training to teach users how to use the software, and support calls when those users inevitably get stuck. The costs of a bad user experience are both incremental and cumulative. So an unempowered or nonexistent UX team can add significant overheads in time and money.
Simply put, it costs more money if a company underfunds or ignores User Experience. From development to testing to training to support, inconsistencies and incongruities gather mass—like a snowball rolling downhill—as the company wastes costly person hours and adds both technical and UX debt—which soon becomes real financial debt—at each stage in a development cycle.
In the end, the customers who purchase enterprise software bear the burden of such costs. Regardless of whether they are aware of it, they must pay for their employees to learn how to navigate unnecessarily complex, nonstandard design solutions. Their employees may also waste countless hours as they try to navigate such flawed solutions. Ultimately, they may need to request help from Support to accomplish their tasks.
