T-Mobile Enterprise Communication Application
Timeline: Jan 2018 - Present
Roles: UX Designer, UX Research
Deliverables: Detailed screens of personas,
Note: Due to NDA, some final designs are not shown.
Communication across companies is a hard thing do me later. wheeee
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.
Azuqua’s main ask for this project was to figure out which features and solutions would best aid users in gaining more insight into their automated workflows (FLO). Gaining more insight into a FLO is defined 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 the technical requirements would be needed so that the backend could work with the new features. During the project, I was working with backend developers to make sure that the technical asks were feasible in a reasonable timeframe. This constraint required me to change many parts of the ideal design, reducing some functionality, but still managing to deliver a large amount of value to our users.
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.
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 that with grouping and categorizing similar errors, it would be possible to resolve multiple errors at once.
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.
Crafting an ideal workflow:
Because of the multiple entry points related to the user’s needs in Azuqua, I needed to balance efficiency of the different workflows with consistency across the different experiences. I storyboarded the ideal workflow for each of the scenarios. From those storyboards, I created multiple variations of the ui to help users accomplish their goals. While creating the UI, I mocked up multiple different visualizations and tools that could be used to help users accomplish their goals and scoped them down to the most useful showing their information on the landing screen, while more specific and less common use cases required more 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 version that could be implemented easily in the coming months and a longer-term product once Azuqua has more functionality that it can deliver to its users. The long-term designs take into account Azuqua’s long-term goal to show more 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, I can only share designs Azuqua has allowed me to. I can talk through user scenarios over the phone or show full user scenarios and the designs in-person.
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 understanding & fixing the 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.