See full case study below
For confidentiality reasons some content has been intentionally rebranded, modified, or omitted.
AWS Glue is Amazon Web Service’s fifth most visited console, providing a serverless ETL service that allows users to extract, transform, and load their data in a cost-effective and simple way. Combining both visual and code- based interfaces, users can prepare for data analytics, machine learning, and application development in far less time. Because of the range of features Glue provides, it serves a diverse range of users in both skill set, technical background, and usage goals.
Glue does not currently have a walk-through onboarding experience
meaning that a first-time user does not gain robust time-to-value returns getting started with the platform because each task is complex and convoluted. Users want to execute tasks without too much overhead, but current setup requirements extend first task completion. This long runway to productivity leads to lost users who would have benefitted from the usage of Glue.
Shorten the runway to productivity for AWS Glue’s core personas?
I began by creating a large-format product map that detailed every step, decision point, and piece of required information a user would encounter—tailored to both their skill level and goals within the platform. From this system-level view, I developed two sub-journey maps to dive deeper into specific workflows, which led me to identify a critical pain point: IAM (Identity and Access Management) setup.
After aligning with stakeholders, I led a redesign of the IAM flow, addressing one of the platform’s most significant usability barriers.
Over the course of 10 weeks, I evolved the experience from low-fidelity exploration to high-fidelity prototypes—with a major pivot along the way.
The Design Process
When I initially learned I would need to improve the onboarding experience, I began by dogfooding the AWS Glue platform –– approaching it as a first-time user and taking notes on my experience.
I didn’t know much about cloud computing so I was starting from scratch, and found the experience extremely confusing. I began to think that the ideal solution was an onboarding wizard that would explain the process to users, similar to how TurboTax offers continuous support throughout the tax process.
Initial Perspective on the Problem
THE PROBLEM
New users lacked Glue skills
Thus, we should give people skills to make the confusing areas less confusing (via tutorials/exercises).
THE SOLUTION
Skills-based onboarding
The process of moving data from one place to another while cleaning, reformatting, or enriching it along the way for analytics or storage
UX Plan
Based on this hypothesis, I created a 5-page UX plan from discover to define to internally test this plan.
I began speaking to different internal users, storyboarding and sketching ideas related to this process, eventually making low-fi and then mid-fi screens using internal design-system components.
I presented my initial findings to key stakeholders—the Principal PM, PM, and Solutions Architect—expecting feedback on how to improve onboarding. While they agreed that I had correctly identified points of user confusion, they challenged the assumption that onboarding was the true problem.
Instead, they surfaced a deeper insight: the issue wasn’t how the product was communicated—it was how it was built. Fixing onboarding would be a surface-level solution for a fundamentally misaligned product architecture.
This feedback was a turning point. It dramatically expanded the scope of what I thought I could influence as a designer. Up until then, I had been working under the assumption that I needed to improve the experience within the existing constraints. I hadn’t considered that the best solution might require challenging the constraints themselves.
This moment completely reframed my approach
THE OLD PROBLEM
New users lacked Glue skills
THE OLD SOLUTION
Skills-based onboarding
THE REFRAMED PROBLEM
Glue is overly confusing
There is opportunity to make the experience less confusing overall, for all users.
THE REFRAMED SOLUTION
Simplify and streamline Glue
Done by addressing issues with IAM permissions that affect the majority of users
To redesign the system from the ground up, I first needed to fully understand how it worked—not just technically, but from the perspective of different types of users interacting with it.
Fortunately, because a large portion of AWS users are also internal AWS employees, I was able to conduct interviews with Solutions Architects, Software Engineers, and PMs to understand how they each used the tool differently. Through these conversations, I identified three core user types, each with distinct technical skill sets and entry points into the product.
I also discovered that users operated primarily across two functional areas within AWS Glue:
To make sense of the complexity, I began creating a comprehensive map of the product experience, outlining what information was needed, when, and by whom.
After the first 3 conversations, the map was still conceptual and exploratory—a tangle of possibilities more than a clear system.
However, after 10+ interviews with users and stakeholders, I was able to synthesize what I had learned into a structured and systematized view of the end-to-end experience, laying the groundwork for a meaningful redesign.
This map became my design foundation, aligning the needs of different users across multiple workflows—and ensuring the redesign wouldn’t just be simpler, but smarter.
To validate my updated system map, I ran a design review session with my internal design team. I presented the current state of the experience using FigJam, inviting the team to leave sticky notes wherever they felt confused or needed more clarity.
The feedback pointed to a clear gap: mid-level users—those with some AWS experience but not advanced—faced the most confusion. While I had captured the high-level steps, I was missing detail around sub-steps, friction points, and the emotional journey for this user group.
In response, I created two focused user journey maps to capture the experience in more depth. These mapped not just the steps, but also:
Sub-steps required for task completion
User thoughts and feelings
Pain points, satisfaction levels, and opportunity areas
To address this, I designed an IAM Creation Wizard for admins that:
✅ Walks admins through step-by-step role setup
✅ Allows admin to set default roles across teams
✅ Enables predictive sorting of IAM roles for end users
✅ Surfaces configuration issues before runtime, reducing failure rates
With the new IAM setup flow defined, I began creating low- and mid-fidelity wireframes, mapping each screen directly to the ideal user journey. This ensured that every screen had a clear purpose and that we were removing unnecessary friction at every step.
After validating early versions with internal users, I presented my designs in design reviews and stakeholder sessions, which led to three key design decisions –– These refinements brought us closer to a final product experience that was not only technically sound, but truly aligned with the needs of the broad and varied user base of AWS Glue.
When selected and unselected users were shown on the same screen, users felt confused and like the interaction model was blurred.
I updated the pattern to use a popup selection flow, where users choose in a modal and then view results separately. This added clarity and reduced cognitive load.
The wizard flow forced users to complete steps sequentially, even if thy were coming in mid-task (e.g., editing an existing user) making the process tedious.
I moved service roles after user selection, allowing users to enter the flow from different points without being forced into an irrelevant sequence—saving time and reducing unnecessary repetition.
Decision #3: Elevating Onboarding for First-Time Users
Unlike other AWS services like SageMaker, AWS Glue had minimal onboarding visibility, making it unclear to users that any support or orientation existed at all.
I prominently highlighted onboarding entry points to make them more discoverable, ensuring new users knew there was guidance available.
I finalized a high-fidelity prototype of the redesigned IAM flow and presented it to stakeholders as well as at Friday Design Share, a cross-AWS initiative where designers showcase work across teams and platforms.
The designs were well received, and I was even contacted by a designer from AWS Athena who wanted to discuss my work further—an exciting moment of cross-platform recognition that reinforced the broader impact and relevance of the solution.
This project taught me one of the most important lessons in UX design: band-aid solutions don’t work. Pivoting away from my original direction felt like starting over—but that difficult shift was what ultimately allowed us to solve the real problem at the root.
That deep dive didn’t just lead to a better solution—it resulted in a product I was genuinely proud of, and helped me earn trust and alignment from both designers and stakeholders.
This project pushed me to think bigger, dig deeper, and design more boldly—and it left me with a deep appreciation for how UX can simplify the most complex systems when you take the time to truly understand them.