Appian Low-code Data

Data is core to any application. However, Appian low-code developers had to clean and transform their data outside of Appian before they brought it to the platform. Even after they brought data to the Appian platform, it required extensive database and SQL knowledge to work with data.

The goal is to low-codify the experience of connecting external data to the platform, and remove the barrier of advanced database knowledge to enable low-code developers to easily prepare their data in Appian for their application development.

A majority of Appian applications are built to present data to end users, so the platform needs to enable low-code developers to shape their data in a way that matches their information structure of the application interfaces.

The above image shows an example of a data structure with a Professor entity in the center, and it has many-to-one relationships with Office and Department, and one-to-many relationships with Publication and Class.

In order to build an interface like the one on the right, a low-code developer needs to, first, set up data relationships, and then calculate new field values using raw data, for example, concatenate first name and last name to show a full name, or aggregate class ratings to show an average score.

The above image shows major design iterations of Appian low-code data hub, Record Type Designer, made in Sketch. The goal is to enable low-code developers to set up data relationship right in the Appian platform, without writing SQL in an external database console.

Iteration 1: Start with an idea of showing fields on the base data and indicate relationship types (1 to 1, 1 to many, many to 1, or many to many) and joining fields. However, the screen is not easy to scan.

Iteration 2: Reorganize the layout to make the main view more structured by putting metadata on the side and add 3 view modes on the main view: Field list view, Data preview, and Relationship view. Also use a section for each of the relationship types. However, it’s hard to understand data relationships without any visual aid.

Iteration 3: To address the feedback that the relationship view was too hidden and visually disconnected from the overall data model, surface the relationship information to the metadata section and remove the relationship tab.

Iteration 4: Balance the layout by putting the “meat” of this view as the first thing after the navigation pane when users read from left to right. The layout automatically flips in RTL (Right to Left) languages.

The image above shows major iterations of relationship configuration experience made with Appian SAIL interface builder.

Iteration 1: Add visual aids to explain definitions of different data relationship types. However, this card design is not scalable when text labels are long.

Iteration 2: Balance the layout and add a data preview to help low-code developers be confident of their configuration.

Iteration 3: Try to add indicators to make it clear which fields are from which record type.

Iteration 4: Add a “Relationship Name” property so a relationship can be leveraged in other parts of the platform, for example, querying data from related record types on an interface. (The many-to-many option was removed to reflect the MVP scope)

To address the problem of extensive database work required outside of Appian platform, I started with ideas that enable low-code developers to take actions right where they see data in Appian platform.

After researching other common tools, including Excel spreadsheets, Business Intelligence tools, for example, Tableau, and ETL (Extract, Transform, Load) tools, I found it’s key to preserve context of raw data throughout the process of data transformation, and distinguish new transformation from the original data.

The above images shows the redesign of Appian low-code data hub, Record Type Designer. The field view on the left lets a low-code developer see all fields in their data; the data preview on the right lets them see their raw data.

In the top toolbar section, the New Custom Field button lets low-code developers create new values from their source data.

The product manager and I analyzed our customers’ use cases, and narrow down to a small set of complex transformation that are commonly used.

I experimented with an idea of providing templates. After conducting user testing, we found users couldn’t identify quickly which template to use due to the amount of options and lack of clarity in templates’ descriptions.

In the following iteration, I worked closely with our writer to iterate on UI copies, and changed to a guided step-by-step approach to help users focus on one action at a time and make a better use of the screen real estate.

We have consistently found users have doubt to new features, especially power users who prefer to see and take control of underlying expressions in code than “a black box” user interface.

This Custom Field feature is no exception. To help users build trust with the product, I worked closely with engineers on my team to experiment behaviors of a test section on the configuration screen to give users immediate interaction feedback.

With the addition of a test section, it became apparent that a narrow modal dialog hurt usability where users had to constantly scroll to compare their configuration on the top and test results at the bottom, so I changed the layout to use a wide modal dialog instead. As a result, the first screen where users select a template also had to be adjusted.

In the scenario of the image above, a low-code developer is working on data of all Engineering team members. To build a report on the age distribution of the members, they need a custom field to represent which age group a member is in. In the test section, they can confirm their logic of age grouping configured on the left hand side to spot any missing groups or errors.

I got positive feedback from user testing sessions that they love how the test section helps them ensure their configuration is set up correctly, and help them account for edge cases in their data.

Note: The design of the pop-up modal above was made with Appian’s interface builder, which serves as a prototyping tool for UX designers to deliver designs to engineers.

After shipping our first release of the guided configuration experience, we continued to enhance it. One of my other ideas inspired from other common tools is to provide contextual controls.

We found from user testing that it was not apparent to all participants to go to the top toolbar for the New Custom Field button to transform their raw data.

The most common user flow is that users decide what transformation they need after looking at the data, so a context menu on the column header comes handy without interrupting or leading users outside of their current context.

I worked with engineers on my team to demo a one-click experience required no code to create a formatted date field as a starting point. We got extremely positive feedback that this experience saved low-code developers’ hours working with date fields.

I’m proud of this cross-functional squad (UX designer, product manager, engineers, quality engineer, writer) to navigate a new way of working during the pandemic.

We shipped the feature in Appian 21.2 release and continue releasing new enhancements. Low-code developers now don’t need to rely on external database operations. They have an integrated experience right in the Appian platform.

When working with this team, I encouraged all of our engineers to take turn sitting in user testing sessions to watch users use what they built and listen to user feedback first hand. They found it very rewarding and they’ve built stronger empathy towards users when they are doing development work, so as a UX designer, I’m not alone advocating for users when we prioritize work.

Teamwork makes the dream work.