Domain-Driven Design Concepts in Enterprise UX :: UXmatters

Upstream Applications Determine Downstream Applications’ Output

Let’s take a closer look at how the design of the upstream application can affect the various types of data that populate the downstream application. Figure 3 illustrates how the structure of the upstream supplier user interface—that is, the configuration application—could permit users to input data into open fields. 

Figure 3—Upstream configuration app dictates data quality
Upstream configuration application dictates data quality

In Figure 3, the Lead Source field is an open field in which users can type whatever name they want to use to identify the lead source. While it might seem generous to allow users the flexibility to type whatever data they want, this has a number of negative consequences. First, there is no ability to standardize lead-source names. In this example, unwanted variability has gotten introduced into the system by spelling home page in two different ways: home page and homepage. Because these source names are different in the upstream application, they get propagated to the downstream application as two distinct data points—even if they refer to the same thing. The result is that data does not roll up appropriately in the downstream application, so the analytics reporting won’t be accurate.

Users should have the option of viewing all home-page data in aggregate—irrespective of whether the data is for the customer-service number or the retail-sales number—without having to export the data from the downstream reporting application and manipulate it manually. Thus, the configuration application’s design has a profound impact on the accuracy and value of the reporting application. As you can see in Figure 4, the impact on the analytics reporting is such that some data points are broken out into separate rows rather than their being rolled up into the same category to show all home-page metrics in aggregate.

Figure 4—Incomplete data in downstream analytics-reporting app
Incomplete data in downstream analytics-reporting application

The reporting application provides data on how many phone calls originated from each of the listed lead sources. Users who want to know the total number of phone calls originating from the home page—regardless of whether they came in on the customer-service line or the retail-sales line—must add up the home-page data manually to get these numbers.

Therefore, allowing users to introduce unwanted variability in upstream applications has the potential to introduce inaccuracies in downstream reports.

Understanding Downstream Application Needs

First understanding user needs at the level of the downstream application helps inform the design of the upstream application. It’s important to keep in mind that users of the configuration application might not also use the downstream reporting application. In this case, prioritize interviewing users who rely on the reporting application because that is where the downstream impacts of the configuration application’s design manifest most directly.

The best way to assess these impacts is by interviewing users to find out how they utilize the analytics reporting, what views of the data are critical, and whether they are able to interpret the data in the reports with no additional data manipulation. Questions you should consider asking include the following:

  • Does the analytics data in the reporting application give you the information you want with no need for further manipulation?
  • Do you ever need to export the data into Excel to aggregate any of the data points?
  • Do ever need to export the data into Excel to segment any of the data points?
  • What is the value of doing this?
  • What are the different ways in which you need to be able to view the data?
  • Do you ever need to go into a different application to obtain additional data to make sense of the information in a report?
  • How do you combine the information from this application and other applications to get the data you need?

Users might tell you, for example, that they need to segment by lead source so they can differentiate between leads that come in through the home page versus the contact page. Alternatively, they might tell you they want to combine all leads that come in through the home page, regardless of whether the leads came from the customer-service number or the retail-sales number. The way in which users can interact with the upstream configuration application determines how users can view their data in the downstream reporting application.

Analytics reporting exists, in part, to prevent users from having to do unnecessary work. If users must export and manipulate data from reports, they are not realizing the application’s full value. Never penalize users for trying to consume data. Unfortunately, that is what many applications do to users.

Let’s consider how we might structure the upstream configuration application to accommodate the needs of users of the downstream analytics-reporting application. This requires re-examining the design of the configuration application. Allowing users to input whatever information they want into open fields in the configuration application increases the risk of introducing unwanted variance into downstream reports. Standardization of field inputs would mitigate this risk. Research into user needs for the downstream reporting application would enable identification of the ways in which they need data to be presented in reports. This research could also inform the types of standardized, prepopulated drop-down list items to use in the configuration application.

In Summary

As this article has shown, domain-driven design concepts such as the customer-supplier relationship can give UX professionals, technical teams, and product management a framework through which to conceptualize how independent, but connected applications interact with and influence each other. This approach to software modeling can help facilitate the type of systems thinking that is so crucial to user-centered software development at the enterprise level. It also shows the need for teams to communicate generously with each other to ensure they anticipate and tackle the challenges that emerge when users must navigate complex product ecosystems. 

Reference

Vaughn, Vernon. Domain-Driven Design Distilled. Boston: Addison-Wesley, 2016.

Source link