Ryan Scott
Product Designer
AWS Account Management
Designing a self-serve way for organizations to add and manage their own AWS accounts, without routing
every request through DevOps.
Mission Cloud
Quick read
3 min
Full story
8+ min
DURATION
6 Months -> Nov 2022 - Apr 2023
ROLE
Product Designer
TEAM
8 Engineers, Engineering Lead, 1 PM
STATUS
Shipped and live
00 – PROJECT OVERVIEW
Turning a DevOps favor into a self-serve feature
AWS Account Management lets organizations add and sync their own AWS accounts into Mission Control's account library, without needing anything from Mission's DevOps team. It's a companion to Scorecards and Scorecard Email Updates, part of the same push to make AWS management self-serve.
02 – PROBLEMS + GOALS
A manual process with no self-serve path
Users had no way to add or manage their own AWS accounts. Every request routed through a team member, so customers waited on someone else's availability just to view their own environment.
Project Goal
Increase independence when adding AWS accounts · Create an always up-to-date AWS account library
03 – OPPORTUNITY
Simple for the user didn't mean simple underneath
The instinct at kickoff was to make this feel as close to "just add your account and go" as possible. But AWS account syncing depends on IAM roles and backend verification that Mission's engineers dealt with directly and customers never had to think about.
The real design problem wasn't hiding that complexity — it was deciding how much of it actually needed a visible step in the flow versus happening invisibly behind one.
04 – PROCESS + KEY DECISIONS
The moments that shaped it
Starting from the simplest possible flow, on purpose
The first flow was intentionally straightforward: log into AWS, confirm the account ID, grant IAM roles, pass verification, done. It gave us a clear baseline to test against before we had real user feedback.
Letting usability testing tell us where the flow was too thin
Testing and an engineering review showed the first version under-scoped the process: it needed more IAM roles and backend steps, and users couldn't tell whether their actions had registered.
Explaining complexity instead of hiding it
I removed the raw IAM role code and replaced it with a plain-language description of what each role is for, added a progress bar, and moved the bootstrap step to the end, after account information is confirmed.
Turning research into a handoff engineering could act on
I used a dedicated "Ready for Engineering" page at the top of the Figma file and joined Pre-Refinement and Refinement with the team. It translated into 11 engineering tasks aligned to Jira tickets.
The flow doubled in complexity between v1 and v2 — usability testing is what surfaced the gap.
07 – FINAL DESIGN
A guided path from account ID to verified access
AWS Account Management ships as a self-serve flow inside Mission Control's account library: confirm an account ID, review plain-language IAM role descriptions, watch backend verification with a progress indicator, and land in an always up-to-date library, with no DevOps ticket.
08 – OUTCOMES + IMPACT
Independence, without losing DevOps's trust in the process
AWS Account Management shipped as a self-serve feature inside Mission Control, giving organizations the ability to add and manage their own AWS accounts without routing through Mission's DevOps team for every request.
DEVOPS TIME RECLAIMED
Account syncing that used to require a team member's manual attention became something customers could do themselves.
ACCOUNT LIBRARY ACCURACY
An always up-to-date library replaced ad hoc manual entries, alongside Scorecards and Scorecard Email Updates.
NOTE
I no longer have access to Mission's internal metrics following the layoff, so these outcomes are directional rather than measured. Mission Cloud was later acquired by CDW.
09 – TAKEAWAYS
What I'm taking forward
Simple can be a starting hypothesis, not a finished flow.
Hiding complexity and explaining it are different design moves.
A repeatable handoff process compounds across projects.
AWS Account Management
Designing a self-serve way for organizations to add and manage their own AWS accounts, without routing every request through DevOps.
Mission Cloud
Quick read
3 min
Full story
8+ min
DURATION
6 Months -> Nov 2022 - Apr 2023
ROLE
Product Designer
TEAM
8 Engineers, Engineering Lead, 1 PM
STATUS
Shipped and live
00 – PROJECT OVERVIEW
Turning a DevOps favor into a self-serve feature
AWS Account Management lets organizations add and sync their own AWS accounts into Mission Control's account library, without needing anything from Mission's DevOps team. It's a companion to Scorecards and Scorecard Email Updates, part of the same push to make AWS management self-serve.
02 – PROBLEMS + GOALS
A manual process with no self-serve path
Users had no way to add or manage their own AWS accounts. Every request routed through a team member, so customers waited on someone else's availability just to view their own environment.
Project Goal
Increase independence when adding AWS accounts · Create an always up-to-date AWS account library
03 – OPPORTUNITY
Simple for the user didn't mean simple underneath
The instinct at kickoff was to make this feel as close to "just add your account and go" as possible. But AWS account syncing depends on IAM roles and backend verification that Mission's engineers dealt with directly and customers never had to think about.
The real design problem wasn't hiding that complexity — it was deciding how much of it actually needed a visible step in the flow versus happening invisibly behind one.
04 – PROCESS + KEY DECISIONS
The moments that
shaped it
Running the same design sprint structure as Scorecards
Story mapping, sketching, deciding on a route, user flows, prototyping, and testing — the same sprint shape we used across Mission Control's self-serve features, which kept this project moving at a familiar pace for the team.
Starting from the simplest possible flow, on purpose
Early on, the flow was intentionally straightforward: log into AWS, confirm the account ID, grant IAM roles, pass backend verification, done. Starting simple gave us a clear baseline to test against, rather than trying to anticipate every edge case before we had real user feedback.
Letting usability testing tell us where the flow was too thin
Testing with real users and reviewing the flow with engineering surfaced that the initial version under-scoped the process: it needed more IAM roles and more backend components than the first pass accounted for, and users had no way to confirm their actions had actually registered.
Turning research into a handoff engineering could act on
Same handoff structure as Scorecards — a dedicated "Ready for Engineering" / "Jira Handoff" page at the top of the Figma file, tickets broken down against it, and joining Pre-Refinement and Refinement directly with the team. This project translated into 11 engineering tasks aligned to Jira tickets.
The flow doubled in complexity between v1 and v2 — usability testing is what surfaced the gap.
07 – FINAL DESIGN
A guided path from account ID to verified access
AWS Account Management ships as a self-serve flow inside Mission Control's account library: confirm an account ID, review plain-language IAM role descriptions, watch backend verification with a progress indicator, and land in an always up-to-date library, with no DevOps ticket.
08 – OUTCOMES + IMPACT
Independence, without losing DevOps's trust in the process
AWS Account Management shipped as a self-serve feature, letting organizations add and manage their own AWS accounts without routing through DevOps.
DEVOPS TIME RECLAIMED
Account syncing that used to require a team member's manual attention became something customers could do themselves.
ACCOUNT LIBRARY ACCURACY
An always up-to-date library replaced ad hoc manual entries, alongside Scorecards and Scorecard Email Updates.
NOTE
I no longer have access to Mission's internal metrics following the layoff, so these outcomes are directional rather than measured. Mission Cloud was later acquired by CDW.