Background
AWS Batch is a cloud computing service that enables users to efficiently run and monitor thousands of batch computing jobs. These jobs are tasks executed by users—such as engineers, developers, or scientists—to accomplish specific goals related to their roles.
Problem
The AWS Batch Console had a very low CSAT (Customer Satisfaction) score. While conducting research to uncover core user pain-points, we came across a common theme. AWS Batch users utilize the Job Details Page to monitor and troubleshoot their jobs, but this page does not adequately display the key information users need to efficiently access and analyze these details.
RESEARCH, SYNTHESIZE, IDEATE
In order to get a grasp on the scope of this project, initial research started off with simply reviewing the current Jobs Details Page in the console to better understand its contents.
Based on prior research of the AWS Batch Console as a whole, we already had a good chunk of user insights relating to the Jobs Details Page. This prior research included digging into our customer feedback forums and interviewing Batch Console users. Using direct user quotes from our research, I pulled out several pain-points and synthesized the findings into User Stories.
With these User Stories, I was able to have a solid idea of the pain-points that needed to be addressed within the Jobs Details Page. With the plethora of information we now had, I documented a Research Report to further synthesize and organize all of my findings concisely. This report served as a point of information for stakeholders or anyone needing to know why this project is necessary.
Now that we have the complete scope of the pain-points we need to tackle within this project, we can now start ideating different ways to address our users needs. To do this, I facilitated a brainstorming workshop with the design and dev team to come up with ideas of how we can solve for each of the user stories.
It was important to include the dev team early on in the process because we knew that there would be pain-points that we could not solve due to technical constraints. The dev team would be able to call this out more adequately than designers would.
With a bunch of different ideas to consider, we narrowed them down and voted on which ones to prioritize for mockups.
And finally, design
After thorough research, synthesizing and ideating, I can finally design some mockups! With the pain-points we voted on as a team to prioritize, I started iterating on my wireframes. Based on the level of difficulty and contraints to consider, I separated the designs into three sections, near-term improvements, tablestakes (low hanging fruit) improvements, and long-term improvements. After feedback from the dev team I went into a second round of iterations.
I shared the final iterations with the dev team, made a few tweaks based on feedback that I received, and placed these designs in the dev backlog.
A CLOSER LOOK
I developed a total of 8 wireframe concepts, 3 of which were simple prototypes. For this specific project, research took up the bulk of the work whilst the designing phase was fairly straight-forward.
Although these solutions seem pretty simple, if it wasn't for thorough research and conversations with customers, we would not have known to solve for these specific pain-points. This is why user-centric design is important.
Let's take a closer look at some of the pain-points I solved for.
1. Log stream name link
Context: AWS Batch jobs go through 7 job statuses- SUBMITTED, PENDING, RUNNABLE, STARTING, RUNNING, SUCCEEDED/FAILED. When Batch users create a job, they are provided with a Log Stream Name which is a link that takes them to a separate AWS console called Cloudwatch Logs. Within this link, a user can view information about their job. This helps users monitor, analyze and troubleshoot their jobs to ensure everything is running smoothly as desired.
Problem: In the Job Details Page, a user is not provided with their Log Stream Name link until their job has reached the RUNNING status. Users did not understand why this was the case, which was frustrating as they were unable to get information about their jobs.
Solution: Provide an info link and further documentation to explain to users why their Log Stream Name link is not available yet. Initially, my solution was to make the Log Stream Name link available through all states of the jobs creation. However, upon discussing with the dev team we realized that this solution was not technically feasible. Our mvp (minimum viable product) solution was to provide information to users in hopes that it clears up confusion and frustration. Our long-term goal is to figure out a way to get around the technical constraints. Sometimes we cannot give the user what they need within the allotted project scope, we have to make trade-offs.
2. Job Details Customization
Context: On the Job Details page, users can view basic information about their job. Within the "Job details" box, this section contains the general need-to-know information, whilst the lower tabs contain more specific information.
Problem: The general consensus of the Jobs Details page is that it does not provide enough information that users need. More specifically in this case, users want the ability to customize the information displayed in the "Job Details" box to their liking, as this is the first place they look to for information.
Solution: Display more information about a users job in the Job Details box, and give users the ability to toggle on/off the information they want displayed. Users can also customize the order the information is shown.
3. EC2 Autoscaling Group
Context: When Batch users create a job, they must first assign that job to a compute environment. A compute environment is a group of compute resources (think of this like a virtual office with software and machines that support the computers) that include something called an EC2 autoscaling group.
Problem: Users wanted easy access to the EC2 Autoscaling Group that their job is linked to without having to go through the long tedious path outside of the Batch console, into the EC2 console to retrieve this information.
Solution: Directly link the corresponding EC2 autoscaling group within the jobs Compute Environment Details page. Initially, I wanted to provide this link in the Job Details page (as this is what the project is focused on). However, upon discussing with the dev team, we decided that it made the most sense to provide this link within the compute environment details since this is what the EC2 group lies in. The compute environment details page is still within the Batch console, therefore users wouldn't have to go through as many clicks to get to this information.
4. Related Services Tab
Context: AWS Batch works in tandem with other AWS cloud services such as EC2, ECS, CloudWatch, etc. When troubleshooting jobs, users often travel outside of the Batch console, into these other consoles, to get the information they need.
Problem: Users wanted easy access to the related services links that are associated with the job they created. As of then, it took too many tedious clicks to access the information they needed.
Solution: Provide a dedicated related services tab which hosts all of the links to outside consoles associated with the job. Therefore users wouldn't have to go through as many clicks to get to this information.
What would i do differently?
After creating the final prototype iterations, I would have hosted moderated usability tests with the same Batch users that we interviewed for initial research.
-If qualitative: I would ask the users to complete a variety of tasks and take note of their behaviors while interacting with the prototypes. I would ask follow-up questions afterwards to get a better understanding of the users emotions.
-If quantitative: I would ask the users to complete a variety of tasks and take note of how long it took to complete each task, and what percentage of tasks were able to be completed by each user. I would also take note on the amount of clicks a user does within a task.
Due to time constraints and project prioritizations, we weren't able to delve deeper into this.
Thanks for reading!