Enterprise software plays a critical role in helping organizations track and execute the work they do. While you may be familiar with Salesforce or Workday as tools companies use to handle internal functions, those are only a couple of the vast range of tools companies use to execute specialized functions such as engineering, translation, and the like. Custom internal tools and enterprise software platforms present unique requirements and challenges for product teams and users. In these situations, a deep understanding of the needs and pain points of enterprise software users is a clear differentiator and value add when it comes to UX research and design. Good research and design can make the difference in whether enterprise software enables a team to do great things or struggle to get the job done.
Unlike with broad-based customer-facing functions such as search, e-commerce, or social media, enterprise software users often have jobs to be done (JTBD) that are very specific, very complex, highly technical, or all of the above. This is especially true for highly specialized fields and industries such as telecommunications, scientific research, health data, or construction project management. Because of these unique needs, enterprise software must balance technical capability and special features with usability in a distinctly different way than customer-facing applications and platforms. With platforms and tools that cater to different roles within a company or team, it can be even more challenging to account for diverse stakeholder needs.
In addition to the specific complexities and requirements of enterprise platforms themselves, users of enterprise software and internal tools are often lower on a company’s priority list than customer-facing applications. Internal tools rarely generate profits or revenue directly. While the usability of internal tools can have a profound indirect impact on the bottom line, that impact is usually more difficult to visualize in comparison to revenue-driving apps and platforms. If a platform or application is deemed “good enough” it may sit on the back burner while customer-facing apps take priority. These factors can make task and project completion frustrating due to bottlenecks, glitches, and other inefficiencies. UX research can play a critical role in showing stakeholders the value of good internal tools for business health.
In one of my prior UXR roles, we worked with a large telecommunications company on a unified platform to track and perform a wide variety of functions to meet customer needs. As is often the case, the current tools some work groups were using were difficult to learn, challenging to use, and had not been updated for a decade or more. For instance, focus groups with one group of engineers yielded these (paraphrased) gems.
This UI is straight out of 1995. (in the 2020s)
It took me six months to learn the platform well enough to be able to use it without someone else being available to guide me.
While the UX and UI of the new platform was a marked improvement over existing tools, the platform itself had some growing pains and was not equally suited to all of the various working groups. On the other hand, the work these engineers performed was highly specialized and complex. Their workflows frequently required switching back and forth between internal tools and external platforms. Research revealed a need for more customization and specific capabilities per role for the internal tools platform to really be optimal for the organization.
At AnswerLab, I have conducted several studies for a big-tech client around localization, the process of translating and fitting web content to different markets around the world. The goal of the project was to build a unified platform with a cleaner UI that supported more streamlined and straightforward workflows. I discovered that not only did the participants face challenges and pain points, but that doing the research presented unique challenges in and of itself. From the outset, it was evident that each of the myriad of internal enterprise software tools had been designed and built ad hoc for very specific parts of the localization work stream and that the apps didn’t talk to each other very well. Due to the complexity of the JTBDs and the tooling, conducting UXR studies in this space was itself challenging. Being successful took a great deal of extra learning, adaptability, and patience. AnswerLab was able to provide impactful insights and recommendations to the client by understanding and accounting for these challenges.
UX research can make a big impact when it comes to building better enterprise software tools. But the special challenges require a particular skill set and approach. Some considerations UX researchers should account for include:
In many cases, changes to enterprise software take more work than comparable customer-facing tools due to the longer time between iterations and re-designs. A key factor in this disparity is the idea that the internal tools are “good enough” for workers to accomplish JTBDs and that it is better to spend more money, time, and energy on profit-generating customer-facing products. This mentality is certainly understandable in a competitive marketplace but it often leads to tools reaching a breaking point before being updated or replaced. What that means for UX teams is that research and design need more iterations to get to a toolkit that really boosts productivity and reduces team-member stress. It takes patience and good persuasion to assure users and stakeholders that the project is on track.
With many enterprise software UXR projects, the company may not offer its employees or contractors any incentive to participate in research. Participants may have been “voluntold” by a supervisor or other high-ranking stakeholder to participate in research for the good of the company. Participants may be unclear on the reason for the study, and could even resent the requirement to participate. It is important for UXRs to discern at the beginning of an interview if a participant needs an explanation of the purpose of the study and to provide it where necessary. Research ethics also dictate that the UXR state that participation is voluntary and the participant may opt out if he, she, or they choose to do so. In that vein it is also important to be flexible in scheduling sessions and respectful of a participant’s time; chances are that participant is on the clock during session times.
Conducting a study and presenting findings does not guarantee those recommendations will be implemented, or even well-received. Sometimes it is important to do some detective work to ensure all relevant stakeholders have had a say in the research plan, objectives, or even the decision to improve the tool. An important group may have been omitted from the kickoff by mistake. Factors that detract from stakeholder buy-in include:
Navigating these challenges takes not only fundamental UXR knowledge and skills but also the ability to navigate complex social landscapes, the instinct to be in conversation with a range of stakeholders, and a great deal of equanimity and patience.
Enterprise software users may tolerate a higher information density than typical customer-facing software users because they often have a need for more details and specificity to get the job done. A successful localization project or cell tower build takes a great deal more information and expertise to accomplish than a search for a good restaurant nearby. In enterprise software, clean and pretty are good, but functionality is key.
A successful enterprise software UXR project report needs to balance concision with sufficient detail to address questions and concerns of a highly technical nature. It also may take more than one share out with a design or product team to successfully implement.
The optimal balance of detail and concision in reports and share outs varies by work stream and stakeholder, more so than in customer-facing software. Stakeholders often want more detailed information about functions and features than with customer-facing apps and platforms due to the technical needs of the user-base and the fact that team members with different roles have at times divergent needs. A UXR can hone reports to the right level of density by being flexible and attuned to communication with stakeholders about what level of detail they need.
Getting buy-in and action on recommendations may involve work beyond the report, e.g., detective work to discover key stakeholders, research on the solution architects and business decision makers as well as end users, etc. It is important to remember that users are an important stakeholder but that their needs may have to be balanced with technical constraints or larger business needs. A UXR can tackle these challenges by going the extra mile to see what impacts the process beyond the current software tools.
Discovering and designing for user needs in enterprise software is a complex and highly contextualized undertaking. Differentiators in this space include deep research expertise, prior experience with enterprise software, and a high level of adaptability.
Want to learn more about optimizing enterprise software? Get in touch with our enterprise software UXR experts.