Case Study
Amazon Q UX Architecture
Overview
May 2023 - Present
After releasing an inaugural set of code generation features, interest in expanding and integrating with Amazon Q grew daily. Here I'll discuss my "UX Architecture" strategy, model, and guidance I've used to empower partners to accelerate innovation at quality.
Approach
Systems Thinking
Design System/UI Library
Growth Design
1. Strategy & Plan
CHALLENGE
Internal and external team members were craving a direction and vision to understand how everything we're working on fits together. My first challenge was to better understand what folks were looking for, and how best to communicate a system to audiences across teams and roles.
ACTIVITY
I first spoke with stakeholders in Product, Engineering, Science to understand their needs and perspective. From these conversations I generated a few artifacts to start brainstorming. This included wireframes, user journey maps, and messy boards in FigJam.
Then, I shared early thinking during a meeting with my UX team to gather feedback. Finally, I met with designers from partner teams who were new to the space and would be potential consumers of the resources associated with this system.
INSIGHTS
Key needs for this solution:
- Promote cohesion: different features built by different teams should feel like the same product to our end users
- Accelerate adoption: internal and external teams could quickly onboard, create prototypes, gather feedback, and make decisions
- Grow our UX culture: cross functional team members can learn more about previous UX decisions and learn how to iterate and expand thoughtfully
- Scale over time: provides structure to build upon while remaining flexible to new ideas and directions
OUTCOME
To meet these goals, my strategy was to:
1. Understand overlap and differences between internal, customer, and industry mental models for our products capabilities.
2. Gain alignment on shared elements like information architecture, interaction pattern and design system, and terminology/taxonomy.
3. Provide documentation in a wiki, visual/UI resources, and mechanisms to apply and expand this system over time.
2. Organization
CHALLENGE
Once I had a sense of what this system needed to solve for and result in, I dove into answering the question: how can we easily describe how different capabilities of Q fit together into a larger story?
ACTIVITY
I synthesized existing foundational research on expectations around AI software development, then ran a study on mental models for our features. I created an unmoderated study to run on a large number of users, having them answer open ended questions and complete card sorting tasks.
INSIGHT
Customers are seeking discrete and tangible applications of AI to accelerate or automate existing tasks, rather than an end-to-end solution.
OUTCOME
I proposed an architecture that organizes these concepts and gains alignment on where we should seek conformity and where we can remain flexible to the context and user endpoint. In other words, where should we take the time to align and where can we enable teams to make decisions quickly.
Immediately this architecture as an artifact drove valuable conversations around their implication on long-term planning.
3. Guidance, Resources, and Mechanisms
CHALLENGE
Once the high-level architecture was agreed upon by stakeholders, it needed support to ensure it's communicated out, usable, and can grow over time.
ACTIVITY
First, I created a Figma Library with reusable components, and worked with a front-end engineer to create a demo site for those components. The UI components serves as an example of how to translate an interaction pattern to a specific endpoint, but can also be directly used. The demo site shows designers who may not be familiar with developer tools what the interactions feel like, while the associated UI components can be adopted by other engineers to ensure pixel-perfect adoption.
Then, I outlined a UX Guidelines wiki to complement the Figma Library and demo site. This included additional information to consider, but focuses on directing readers to helpful artifacts that serve as a source of truth rather than summarizing everything.
Finally, I worked on how to make sure this architecture and it's related resources can grow over time. I started hosting weekly office hours, worked with managers to include links in onboarding documentation, and scheduled a recurring review of shared interaction patterns.
INSIGHT & OUTCOME
While adding new capabilities, this architecture has provided stability and guardrails to make decisions quickly while ensuring teams align on developing a single product. Maintaining and growing this system will be an ongoing effort.