Building AWS Config: navigating cloud changes through time.

AWS Config was the first product in a new line of AWS cloud computing tools designed to assess, audit, and evaluate the configurations of your AWS resources.

Imagine this…

Once upon a time, there was a kid named Alex who had a big toy room. Every day, Alex played with toys, moved them around, and sometimes gave some away or got new ones. But Alex's mom wanted to keep track of what toys were in the room and what changed every day — so she got a magic notebook called AWS Config.

Every time Alex took a toy out, put a new toy in, gave a toy to a friend, or changed where a toy was, the magic notebook wrote it down with the date and time. So if one day a toy went missing, Alex's mom could look at the notebook and say: "Aha! On Tuesday at 3 PM, Alex moved the red fire truck under the bed!"

In the real world, people use AWS Config to track changes to their resources in the cloud — servers, databases, and more. Just like Alex's toy room, they want to know: what changed, when did it change, and who changed it? The timeline helps them see the story of those changes so they can fix problems or understand what happened.

Based on a series of interviews and user surveys with AWS customers, there was strong demand for a monitoring and evaluation service that continuously tracks AWS resource configurations and automates the assessment of those configurations against desired standards.

My goal was to design the entire new AWS Config console from beginning to end, ahead of its release at re:Invent. Some of the qualitative data from the interviews revealed that AWS customers wanted to:

• Discover the AWS resources that exist within their account at any point in time.
• See how changes occurred in the past, visually.
• Keep track of and localize resource changes over time — a common difficulty.
• Troubleshoot why a resource may have stopped working properly.

• Conduct research: understand potential users' goals and needs to determine product value.
• Collaborate across disciplines: lead one-hour Design Studio workshops to sketch solutions around a focused scenario and a prioritized set of features, uncovering use cases and ideas.
• Deliver design decisions: guide the team through incremental decisions, delivered as conversations, sketches, whiteboard sessions, wireframes, mockups, or prototypes.
• Seek feedback: constantly share work with users, stakeholders, and design peers to gather feedback.
• Communicate early and often: as part of a balanced Agile team, act as leader, facilitator, and educator on how the product should act and look.

We began by exploring our assumptions about how users discover the AWS resources in an account at any point in time. Our first reaction was to provide a date-picker control to navigate through time — but after speaking to users, we found a better approach.

Next, we wrote questions to prompt interviewees to tell their story in their own words, to learn what mattered to them when looking for configuration across different AWS resource types. The first round of interviews produced clear trends:

• A simple way to navigate through time to see changes.
• The date picker was the wrong UI for looking for dates.
• A relationship between configuration details for each resource and time.
• Visuals to give users a clear view of changes.
• A provisional persona, based on PM knowledge and my understanding of the user, that I returned to throughout the project to guide decisions and priorities.

It was challenging to design a tool for navigating through time without breaking some UXDG patterns. The first unsuccessful attempt used only UXDG components.

I built the prototype in Axure RP. To get more accurate feedback, I uploaded the Axure files to my personal server so participants could access the prototype from a mobile device — a very realistic testing experience.

Before jumping into design, it was important to define success and understand the requirements. Given the complexity of the system, creating a task flow helped me represent the logical sequence of the user's journey from the starting point to accomplishing a task.

Prototyping was the most effective way to gain meaningful feedback from the team, consensus from stakeholders, and approval from senior leadership. I could easily distribute prototypes as videos and reuse them for usability testing.

For the first prototype I used Axure RP, mostly because of the limited time I had to turn the idea into a playable artifact. One problem, though, was Axure's animation limitations — it was hard to match the effect we wanted when navigating between pages using the direction controls.

The different iterations, based on user feedback, all centered on one of the most critical UI pieces of AWS Config: the timeline.

1. Just request and we do the rest

We had to make sure users would understand the time-navigation concept. I was surprised by the issues we found testing the first concept — the main problem was locating the "change point" indicators on the timeline. We wanted users to understand that changes happen at the beginning of a period of time; when the change point sat in the middle of the time block, it confused people about when the change occurred.

Solution: we justified the change-point marker to the left. Even though it seems like a complex concept, users did understand it with the change indicator in the left position on the time block.

We tested the new AWS Config timeline UI for usability problems, and talked to participants about what they'd use the tool for — looking for the functionality needed to solve users' real problems.

We had seven participants: four were already recruited as beta users of AWS Config, and the remaining three came from our usability panel. Five of the seven managed large AWS installations, while two had fewer than ten instances.

• All participants liked having a visual timeline to navigate the data.
• All participants navigated the timeline well.
• The tool was seen as particularly useful for reverse lookups — such as seeing which instances were associated with which security group or autoscaling group.

1. Challenge conventions. Date pickers are standard, but they were wrong for this use case. User research revealed a better pattern.
2. Iterate fast. Four major iterations in four months each solved specific problems uncovered through testing.
3. Use the right tool for the job. Axure provided speed and HTML provided fidelity, so each supported a different phase.