User Experience Customization
How enterprise discovery shaped a new AWS service, and why I launched account colours before the broader customisation experience.
I led customer discovery, feature prioritisation, and the phased launch of AWS User Experience Customization, working with engineering on the product experience and programmatic configuration.
Enterprise governance was shaping everyday workflows
Across conversations with 30+ Fortune 500 enterprise customers, a recurring theme emerged: their organisations had clear requirements and preferences that the Console experience did not reflect.
Regulatory obligations shaped where they could store data. Central teams also standardised on particular AWS services. Yet the Region selector and service navigation showed the available options without a way to communicate those organisational choices.
Some customers told me this contributed to their reluctance to give more employees Console access. I prioritised account-level Region and service visibility so administrators could tailor what users saw. These controls shaped the interface; permissions remained responsible for enforcing access.
I launched one useful capability first
The broader UXC offering would take more time. Account colours were ready, and multi-session support had created an immediate reason to ship them: people could now keep several AWS accounts open in one browser and needed to distinguish production, testing, and development environments at a glance.
I chose to launch the new service with that single capability. The alternative was to make customers wait roughly another six months for the broader offering, even though something useful was already built.
We introduced account colours as a feature release. This let customers benefit immediately, while we continued working on Region and service visibility. The initial account-colour launch reached 100K+ accounts in 12 weeks.
Time-zone customisation did not make the cut
Time-zone customisation was another recurring request, but its value was less clear after discovery. Should the Console use the person’s local time, the resource’s time, or the AWS Region’s time?
Teams had already developed working conventions around UTC. Changing that mental model risked introducing ambiguity without a clear enough improvement to their workflows. I deprioritised the feature in favour of the enterprise visibility needs and account-identification problem we understood more clearly.
Each release needed to stand on its own
An incremental rollout still needed a complete experience at each step. We paired each release with programmatic configuration and documentation, so administrators could use the capability in their existing workflows.
Account colours launched first; Region and service visibility followed. The sequence let us deliver immediate value while building toward the enterprise customisation needs that had shaped the roadmap.