Alation Offline Usage Data Uploader
Read the full portfolio piece here: http://cheungcindy.com/project/oudu/
Challenge
How can we increase usage data upload from customer admins into Alation?
Context
Since only about 30-40% of customers upload usage data, Alation is imposing a contractual obligation to upload usage data to Alation every 30 days. At the time, Alation lacked processes that easily allowed admins to complete this obligation, especially those who used offline servers.
User: Server Admin attempting to upload usage data onto Alation. This is what I would imagine their workflow would look like.
Automatic Reporting
This establishes a connection between the customer’s Alation instance and the Customer Portal server to continually upload data every 24 hours, without the Server Admin having to do anything additional.
As the simplest, most no-fuss option, Automatic Reporting is the way every customer should ideally be utilizing. However, we can’t expect it to work 100% of the time, so multiple states needed to be built out.
Should Automatic Reporting fail, however, the upload alternatives would appear.
Upload alternatives
I was able to reuse a timeline graphic element I originally built for the brand design department to develop a progress bar component for the data upload options.
On the left are the timeline graphics I built out. On the left is the adapted version for the product, such that there was consistency in Alation's branding and messaging.
For these first iterations, the main confusion lied in that there were inconsistencies with the way that the different methods of uploading were portrayed. Additionally, the 10 steps looked quite overwhelming.
I set out to address the feedback I got from the team, as well as trying to further enforce the workflow we wanted the users to go through. To achieve this, I utilized the segmented controller to house the two upload alternatives, with the Upload in Web Browser option as the default.
Upload in web browser
Upload manually
The upload manually alternative requires the Server Admin to use the Alation Customer Portal as well, which I thought definitely needed a face lift. The styling didn’t match with the Alation product, and the steps needed to be presented in a way that doesn’t overwhelm the user.
Wrap-up
As we neared the code freeze, the engineer and I worked to smooth out the kinks during the quality assurance and testing stage. I documented JIRA sub-tasks for the engineer to fix, as well as producing other relevant documentation: the meeting notes, design spec, copy doc, and design debt document. The design spec details the goals, all relevant information to understand the design decisions, and explicit instructions on the implementation of the design, while the copy doc is the source of truth for all copy in the product as well as for the email notifications to Server Admins.
Working at a mid-sized startup in a groundbreaking space gave me the opportunity to truly be an integral part of a design team, even as an intern. I was able to learn so much from my peers – from experience design while creating Invision interactive mocks to writing well-formed notes and design-related documentation.
