Azuqua execution history design

Timeline: 10 weeks
My Roles: Solo UX Designer, UX Research, PM
Team: Solo Designer, Head PM, CTO, Backend Engineer, Head of Engineering
Tools: Sketch, Framer, InVision
Deliverables:  Hi-Fi mocks of short-term and long-term solutions. Spec write-up for backend requirements

Note: Due to NDA, some final designs have been omitted.

Problem:

Azuqua is a cloud software workflow automation platform that connects many cloud services together and runs the workflows (FLOs) without requiring any user input. FLOs can run from once a week, to tens of thousands of times every hour. Because of the unstable & ever-changing nature of cloud software, FLOs sometimes fail to finish correctly and errors occur. When these errors occur, users need to be notified so that they can quickly resolve the error. Additionally, users want to be able to view the data that has run through their FLOs to find a specific execution. Currently, the user can only find this information in Azuqua by manually checking every single execution.

Solution:

As a solo designer owning the product space, I created two different solutions: one for the short term and another as a longer term goal. The feature solves the users problems by sending information about how the FLOs have been running and surfacing error information into the natural workflow of the users. Because Azuqua usually runs behind the scenes, users are alerted about errors through email. Further development will involve integrating with other communication platforms like Slack. Daily summary e-mails are also sent out informing users about how their FLOs are running. When users were on Azuqua, I designed additional features to alert users of errors, view content created through Azuqua FLOs, and gain insight into the operations of their workflows. By improving the error resolution process, users spent 60% less time fixing the errors in their FLOs and gained considerably improved ability to be able to find executions that they are looking for. 

Long-term design for individual workflow (FLO) dashboard 


Gaining Insight:

Azuqua’s main ask was to figure out which features and solutions would best aid users in gaining more insight into their automated workflows (FLO). Insight was gathered by three main points:

1) examining data passing through the FLO

2) Understanding why a FLO had an error and how to resolve that error

3) Knowing which Services and accounts are utilized by a FLO.

An important element that needed to be figured out early was figuring out what technical requirements would be needed so that the backend could work with the new features. I worked with backend developers to make sure that the technical asks were feasible in a reasonable timeframe. This constraint required me to reduce some functionality of the ideal long-term design, but still made sure that the product delivered value to our users.  

Prioritizing Features:

Azuqua FLOs are complex with important data moving through each execution. Due to the massive amount of data, I needed to prioritize which data would be the most valuable to users to be able to accomplish their goals as quickly as possible. To do this, I worked with Customer Success Managers to create a list of all the activities users performed using a FLO’s execution history and grouped them in relation to each other. I created and sent a survey to users asking them to list which of these problems were the most critical for them to solve. From the results of the survey: I learned that the primary task people used the execution history for was to understand and resolve errors their FLOs. Additionally, users value being able to easily examine data that moves through their data. I made these two problem areas the core focus of the design solutions to ensure that we achieved both of these goals effectively and efficiently for the user.

Understanding errors:

To create an ideal system to resolve errors, I had to understand the different types of errors that can occur in a FLO and how to resolve them. Errors can occur for a variety of reasons including API changes, cloud service outages, FLO logic errors, connection issues, unauthorized accounts, and more. These errors required different user actions to resolve them. Additionally, some of these errors resolved themselves, while others occurred until the user took action. Once users solved the issue in their FLO, they want to ensure that their FLO is not suffering any other errors. From this research, It became clear that there was no simple “one-size-fits-all” solution but with grouping and categorizing similar errors, it would be possible to resolve multiple errors at once.

Finding Data:

Users tended to look through their FLO's executions for two primary use cases:

1) Users want to know what data is contained within a specific FLO.

2) Users want to know if a specific FLO ran or did not run.

Because of the large amount of data in a FLO, users needs to have powerful filter and search commands that help them find the data they are looking for. Users desired the option to be able to see customized data sets, as many of them only cared about executions that met certain criteria. A major constraint to consider was account security, as the operator of the FLO may not have access to the accounts of the services the FLO is utilizing. Other companies did not want any data to be seen by their employees to keep certain that the data that runs in the FLOs remains confidential.

Crafting an ideal workflow:

Because of the multiple entry points into Azuqua, I needed to balance efficiency of different workflows with consistency across the different experiences. I storyboarded the ideal workflow for each of the scenarios, keeping in mind the different goals the user could be trying to accomplish.  While creating the UI, I mocked up multiple different visualizations and tools that could be used to help users accomplish their goals and narrowed down the tools and info shown the highest level to give users the most needed information. I pushed down more specific and less useful data deeper into the categories, but still allowing the user easy access to this data by drilling down.

Speed & Scalability:

Azuqua is a fast moving startup with changes and features shipping rapidly and often. When re-designing the execution history feature, I created a short-term solution that could be implemented easily in the coming months and a longer-term solution once Azuqua has more functionality that it can deliver to its users. The long-term designs take into account Azuqua’s goal of showing large amounts of data for users to analyze and operationalize upon. Another design consideration for the long-term was that the design needed to be able to scale from showing data for an individual FLO to showing the entire account information, keeping the experience across the different levels consistent.

Note: Due to NDA, some designs have been omitted.

The FLO Dashboard:

The FLO Dashboard was designed to allow users to answer the main questions they have when they go into a FLO:

1) How is my FLO doing?

2) Is there anything wrong with my FLO?

3) How has my FLO been running recently?

4) What has my FLO modified?

By surfacing high level information, users have the ability to be quickly informed of their FLOs status. 

Is there anything wrong with my FLO?

The left tile allows users to quickly grasp if the FLO is having any issues. By grouping similar issues, we allow users to quickly find the issue causing the errors quickly, reducing the time spent debugging FLOs. Warnings are also displayed here.  Warnings are not errors in an execution, but there may be issues later if not addressed.

 

How has my FLO been running recently?

The middle tile allows users to know how their FLO has been doing. FLO duration times depend on the complexity of the FLO. By looking at the avg. duration time of single FLO, we can alert users of time periods when a FLO had errors, as well as showing periods when services utilized by the FLO are down. 

 

What actions has my FLO been doing?

FLOs typically modify something on another service, whether it be re-naming, moving, or creating content. Because of this, its important to know which FLOs are doing what, and where, and to be able to examine these activities in a meaningful way.

 

Did a certain execution run?

FLOs can execute potentially thousands of times a day. To alleviate the pain of having massive amounts of data running through a FLO, Users have the ability to search and filter by data fields, that they care about, giving them access quickly and easily to find the executions they are looking for.

Conclusion:

Through ten weeks of research, design, prototyping, & user testing, I worked with CSMs and Engineers to create features that allow users to easily understand the data that runs through their workflows in Azuqua. Additionally, by improving the error resolution process, users spent 60% less time fixing errors in their FLOs and gained considerably improved ability to be able to find executions that they are looking for. This feature is the first step in giving users more access to the data in their FLOs so they can operationalize it and use it to improve their own business.