my roles: Interaction Design, Visual Design
Empowering business users to develop applications without code
In this project, I designed an experience for business users to create integrations between their low-code application and external systems.
DESIGN PROBLEMHelp business users create outbound integrations with external systems using a generic HTTP protocol. The user must be able to discover the possible inputs the service can accept and easily navigate its complex structure and select data from their app to pass into each input. Allow users to transform their data when the service expects it in a different format. And of course, testing the integration is a must.
|
My design explorations started broad in order to creatively come up with ideas as well as test the team's appetite for innovation. My design goal was to remain a familiar experience within the ecosystem already in place while pushing the boundaries towards a modern, more visual experience. I explored how to create reusable configuration (a system connection) for connecting and authenticating to external systems. I explored how to to test that connection, configure the parameters of the call, map data to inputs, map data outputs back to variables within the app, and test that entire web call.
I user tested two very different visions for the experience. Namely, a highly visual experience the team was very interested in trying against a simpler form-like experience. The visual idea provided two mapping experiences, one for the inputs and one for the outputs where users can visually link data sources and targets.
Below is a montage of mockups for the visual mapping experience, showing how I enabled users to make links with single clicks that are more accessible and less tedious than traditional drag-and-drop experiences.
Below is a montage of mockups for the visual mapping experience, showing how I enabled users to make links with single clicks that are more accessible and less tedious than traditional drag-and-drop experiences.
After several reviews, light user testing, and estimates from engineering, it became clear that a "simple" form was a more pragmatic and more usable experience - a win win.
Configuring an outbound integration can be broken into three steps: connecting to the system, mapping the inputs, and mapping the outputs. Within the first step, the user may save the connections information for reuse and test that connection. Once complete, the user should also be able to test the entire integration.
As such, I continued to detail out the form-like experience using the platform's typical editor structure and the three step flow.
Configuring an outbound integration can be broken into three steps: connecting to the system, mapping the inputs, and mapping the outputs. Within the first step, the user may save the connections information for reuse and test that connection. Once complete, the user should also be able to test the entire integration.
As such, I continued to detail out the form-like experience using the platform's typical editor structure and the three step flow.
For the first increment, I used interactions consistent with the rest of the platform, such as the table for Integration Inputs. For an MVP, we required the user to enter the input name from the service and then pass a hard coded value or a variable carrying the value.
Common to integration scenarios, we had to allow users the ability to apply at least simple "transformations" on the data in the first release. A transformation is when you need to modify the format of the data for it to meet the expected format of the target system. For example, we may have first name stored in one field, last name in another, and yet the system expects a single String with the first name and last name combined.
We knew that an in-line experience for data transformations would be ideal, but to deliver value to the market sooner we opted to start by reusing an existing concept in the product - a Rule. Users define the transformation in the rule (like a function in a programming language) and then call that rule from within this mapping experience.
We knew that an in-line experience for data transformations would be ideal, but to deliver value to the market sooner we opted to start by reusing an existing concept in the product - a Rule. Users define the transformation in the rule (like a function in a programming language) and then call that rule from within this mapping experience.
Lastly, the user needs a way to map the outputs of the call back into variables known to the application. This was an opportunity to add variables as smart defaults, variables we know the app should always use. As such, we added variables for capturing the success or error messages from the web call.
While the form-like experience can be less exciting than the visual experience, it turned out to be a great success with existing customers who found it more intuitive.
In a second iteration, I updated the mapping experience to no longer require the user to lookup and enter the input name, but rather have the system pull the inputs known by the service and present them to the user. Now the user need not reference the documentation for the service - they can simply navigate the hierarchical structure of the data inputs and start mapping data into them.
I presented the data in a condensed yet clear manner while maintaining its hierarchical structure and showing meta-data such within the hierarchy. I then covered every use case for every data type and possible mappings in order to ensure a dynamic, smart experience that could present options that make sense for the user's selections and provide user assistance for non-obvious expectations in context.
I presented the data in a condensed yet clear manner while maintaining its hierarchical structure and showing meta-data such within the hierarchy. I then covered every use case for every data type and possible mappings in order to ensure a dynamic, smart experience that could present options that make sense for the user's selections and provide user assistance for non-obvious expectations in context.