The integration of enterprise applications is a complex, long-term process that requires careful consideration of business goals, user input, and technical constraints. Enterprises often apply the word integration broadly to describe different types of integration scenarios. In some cases, integration refers to connecting separate applications in ways that enable those applications to function together more seamlessly, while maintaining their independence. In other cases, integration refers to connecting separate applications with the ultimate goal of consolidating them into a single cohesive platform.
Deep linking between applications provides continuity for users throughout the execution of their work tasks. In instances where the ultimate goal is to consolidate applications, deep links provide an intermediate path to integration. This article outlines some techniques for exploring deep-link candidates with your users and characterizing the ways in which those deep links should operate. It also describes several deep-linking patterns for which users commonly perceive a need.
Champion Advertisement
Continue Reading…
Identifying Deep-Link Candidates
It is critical that you facilitate smooth transitions between software applications in situations where users must engage with separate applications that together support the completion of a single task. To identify deep-link candidates for your applications, you need to discover four key things:
The inflection points in your users’ workflows where they must transition from one application to another
The mechanisms of users’ transitions
The reasons—or the whys—behind these transitions
Whether transitions are unidirectional or must be bidirectional, allowing the user to transition back to the originating application
Regarding directionality, in the remainder of this article, I’ll refer to the first application in a deep-linking sequence as the originating application; the second, as the destination application, as depicted in Figure 1.
It is essential that you identify both the originating application and the destination application in your users’ workflow. The relationship between these two applications could be either unidirectional or bidirectional. If the relationship is unidirectional, a deep link takes the user from Application A to Application B, but not from Application B to Application A. If the relationship is bidirectional, a deep link can take the user either from Application A to Application B or from Application B to Application A.
The best way to discover users’ needs relating to these transitions is to conduct one-on-one interviews with them. These interviews should include observations of users completing cross-application workflows. Contextual inquiry is a research method that is well suited for this purpose. While supplementing your qualitative user data with quantitative data that speaks to the pervasiveness of these deep-linking patterns could be quite powerful, a lack of cross-domain tagging or consistent identification of individual users across domains often precludes the discovery of user needs through Google Analytics.
Table 1 shows the types of research questions you might want to explore during individual user interviews, as well as the types of architectural decisions you might make based on the answers.
Table 1—Deep-linking research questions and associated decisions
Research Questions
Decisions They Support
Must users leave one digital tool and go to another tool to complete a task? What tasks require such a cross-application workflow?
Identifying applications and associated workflows that might require deep linking
Is a transition’s sequence always the same? For example, do users always go from Application A to Application B, not B to A?
Identifying the originating application and the destination application and determining whether deep links must be bidirectional or unidirectional.
What are the reasons users must transition from one application to another?
Evaluating whether a deep link is the most appropriate solution
When users leave one tool and go to another tool, do they close the originating application or keep it open to return to it later? If users have both applications open at once, are they on different monitors, in different windows, on different tabs, or in different Web browsers? Do users need to view the applications side by side?
Determining whether the destination application should open in the same tab or a new tab
If users view applications side by side, what is the purpose of doing so? What kind of work is the user doing? Copying and pasting data from one application to another? Verifying data entry? Looking up information in the destination application to evaluate or contextualize the information in the originating application?
Evaluating whether a deep link is the most appropriate solution
You should gather most of this information by having users walk through their process so you can directly observe their behaviors rather than merely relying on their verbal accounts of how they accomplish their tasks.
Once you’ve observed users going through their cross-application workflows and asked the appropriate follow-up questions to understand their needs in greater detail, you’ll be ready to review your data to determine whether patterns exist that tend to describe the reasons users require cross-application links.
Deep-Linking Patterns
When conducting user interviews that focus on cross-application workflows, you’ll likely hear a variety of reasons why users might need to transition from one application to another. In conducting my own research, I have discovered that there are three primary patterns that describe users’ reasons for making transitions from one application to another. Understanding the need for a transition between applications is critical because it might reveal that a deep link is not the most appropriate solution for addressing a user need. It is important to know when a solution would not be the appropriate solution. Figure 2 illustrates the three primary deep-linking patterns I’ve observed in my research.
These three deep-linking patterns articulate distinct user needs for a deep link and, in some cases, might indicate that there is a better solution for addressing the need than a deep link. In such cases, a deep link would be an intermediate step on the path toward creating a more meaningfully integrated set of applications. Let’s dive into each of these deep-linking patterns individually.
Pattern 1
In Pattern 1, users transition bidirectionally between Application A and Application B to compare the same data in two different applications. They might simply need to verify that the data are accurate and consistent, so the directionality of such cross-application inspections might not be important to them. While a deep link would let users go directly from a section in one application to a relevant section in another application—without locating a bookmark for the destination application or laboriously typing in a Web address to view the relevant page—a deep link would be only an intermediate solution in this case.
The real issue is the distinct, underlying databases that support the two applications. Users pay the price for this lack of integration by manually inspecting, editing, and updating records in both applications. The solution should be a single backend system that supports a shared customer record. (See Platform UX, Part I for a description of the user experience of shared data.) One important benefit of exploring user needs around cross-application workflows is the ability to reveal opportunities for changing the platform or architecture of a backend system to better align with user needs. In this example, it is clear that a deep link would be a stop-gap measure on the way to true integration by sharing data on the backend.
Pattern 2
In Pattern 2, users express a need to go from information in Application A to an associated action in Application B. This need is common in situations where users rely on reports or dashboards to make decisions that result in actions. Possible actions might include increasing the budget for a particular service, launching a specific type of advertising effort, or selecting particular types of inventory for discounting.
In this case, situating the information in close proximity to the point where the user decides to take an action helps facilitate the user’s work. Users benefit enormously when their decision-making context provides the relevant information. In this case, the deep link is unidirectional because the user has expressed a need to evaluate information before going to Application B where this evaluation would culminate in an action. A truly integrated platform would dispense with the deep link completely and, instead, would provide recommendations on what actions to take based on the information in a report or on a dashboard. However, a deep link would be an acceptable intermediate strategy along the path toward integration.
Pattern 3
In Pattern 3, transitions between Application A and Application B let users more easily view two different types of data. Such transitions support their gaining a more comprehensive view of the available information by connecting two different types of data that are necessary to convey a full story to the user. While deep links would be an acceptable intermediate strategy for providing the appropriate context to users, an advanced integration strategy would more meaningfully combine those two different types of data into an integrated report or dashboard that would let users view the data in a single space.
Putting It All Together
Now that you’ve gathered user needs and identified patterns across your sample of users, construct a table similar to Table 2 to share this data with your stakeholders. Your table should describe the originating application, destination application, whether deep links should be bidirectional or unidirectional, whether the destination application should open in a new tab or the same tab, the reason users need a deep link, and how you plan to measure the success of your integration efforts. Table 2 shows the information you should give to your team to influence the architecture of deep links.
Table 2—An integration roadmap for deep linking
Originating Application
Destination Application
Directionality
Application Opens In
Deep-Link Rationale
Success Criteria
Application A
Application B
Unidirectional
New tab
Explicitly linking information to an associated action
Quantitative: X% of active users are engaging with deep linking.
Qualitative: Users no longer rely on bookmarks or typing Web addresses to make cross-application transitions.
Application C
Application D
Bidirectional
Same tab
Explicitly linking two different types of data to get a complete story
Quantitative: X% of active users are engaging with deep linking.
Qualitative: Users no longer rely on bookmarks or typing Web addresses to make cross-application transitions.
Your roadmap should explicitly articulate deep-link mechanics such as directionality, the rationale for having a deep link, and the success criteria for each deep-link candidate. Mapping these elements is necessary to ensure that you fully support user needs and the solution aligns with the problem you’re solving.
While deep links might be just an intermediate step on the path toward more meaningful integration, providing them can have a profound impact on the experience your users have with your software. Deep links communicate that your organization recognizes and responds to user needs. Deep links can be a component of your integration strategy. When you create them with the right intent, they can facilitate cross-application work by providing context and continuity to your users.
Thanks for putting this together. We’re currently in the process of trying to determine if deep linking is the right solution for us. We have a newsletter that we want to send out. We want the links in that newsletter to launch the app when the user already has the app installed. I think your information is helpful. Some case studies could take this article to the next level though. :)
There is a fundamental problem in the UI/UX space when it comes to business process, workflow, and data flow in the context of enterprise application development when based on BPM and WF. I am talking more specifically about the nexus point where the business process and workflow—choreography and orchestration—are close to an immediate to the end user.
So, if you have a handful of point solutions and the end user goes out and secures these applications, working under the guise that they can string or connect these processes together, you simply will not do anything very productive—other than create new types of problems for the end user.
We have cases where some of our users use point solutions that are browser-based Web applications; each app does something in one part of the process or task model. Two different companies wrote these apps, they have no APIs or SDKs and really don’t care about how they might seamlessly coexist with any other app. The actual user experience between the apps does not project a common experience, so effective usability is out the window.
How can deep-linking be useful?
There is a much bigger, greater superordinate problem domain to address here.
Amy has over 20 years’ experience as a professional researcher, both in the field of neuroscience and, more recently, in the UX space. She earned her PhD in Psychological & Brain Science from Dartmouth College. Amy’s training has informed her approach to understanding users. Her primary professional interests align with platform UX, a term she has coined to describe her approach to understanding the user experience from the perspective of platform-level concerns. These concerns include data sharing, data availability, permissions, and information architecture. Amy has dedicated herself to promoting the value of UX research among stakeholders and pioneering collaborative-research approaches for UX professionals, technical teams, and product managers. Read More