Enterprise solutions often depend on integrations between multiple applications.
Few of these applications were built with the intent of integrating them into a system that supports a cohesive user experience.
In cases where an enterprise is integrating two or more applications that have disparate, back-end data sources, UX research should guide efforts to align those data sources to achieve a seamless user experience.
There is a profound lack of information on UX-research approaches that are suitable for exploring integration issues for enterprise software.
This article is Part 1 of a series in which I'll examine several critical software-integration considerations from a UX perspective. In Part 1, I'll focus on how to characterize users' mental models of the data that underlie enterprise systems. In cases where an enterprise is integrating two or more applications that have disparate, back-end data sources, UX research should guide efforts to align those data sources to achieve a seamless user experience. This article outlines specific approaches for characterizing both the current and ideal workflows for viewing, adding, or modifying data across multiple applications. It also identifies success criteria for use when evaluating integrated user experiences.
Think about the painpoints that emerge when the user must enter, update, and view customer information across several applications.
To understand how users might expect to interact with data across multiple applications, you must first know about the different types of data models that describe the relationships between the information that resides in the different applications.
Maintain separate applications that interact with one another.
Meaningfully combine applications into a single platform over time.
Figures 1–4 depict four primary ways in which the applications within a user's ecosystem can share data. In these figures, all of the applications are necessary components of a user's workflow. Therefore, the user must use these applications in conjunction with each other to accomplish a series of steps in a larger overall task—for example, updating a customer's address across multiple applications after the customer has moved.
The user manually enters data in one application—the originating application—then must remember to push, or propagate, the data to one or more peripheral applications manually.
In the push model, which is depicted in Figure 1, the user manually enters data in one application—the originating application—then must remember to push, or propagate, the data to one or more peripheral applications manually. Only then can the user view the data in the peripheral applications. Similarly, if the user changes data in a peripheral application, the originating application won't reflect those changes unless the user explicitly pushes the data back to that application. Thus, the data are not truly shared; they're actually two different instances of the data from two distinct, underlying databases. To maintain the data's consistency, the user must continually update, then manually propagate the revised data to all connected applications. Therefore, the data's consistency depends on user-initiated behaviors such as sending or pushing rather than on automatic updates.
Fantastic article! Thank you so much for sharing these insights. I especially liked the connection you drew between the concepts of effort and perceived risk correlating similarly to how effort and perceived control correlate. It made me want to include assessment questions in your "How to Measure Outcomes" column about perceived control along with the question about perceived risk/confidence and time/effort.
That's a great point, Henry! Perceived control would certainly be an interesting dimension to track, in addition to the ones outlined. Thanks for reading and commenting!