AWS Profitability Tool - v.1

The original business problem we wanted to solve centered around the lack of automation associated with the day-to-day financial analysis / forecasting processes relied on by the AWS Finance organization. The most important process amongst these is the creation of customer Profit & Loss (P&L) statements.

The customer P&L is a common output that AWS Finance generates to analyze the company’s financial performance in relation to a specific customer (or a group of customers). As important as these analyses are - which rely heavily on the customer P&Ls - they had always been conducted via manual and time-consuming procedures. Everything was manually done using Excel and SQL, and sometimes it could take up days to create a full P&L for  a large customer such as Netflix. Given that there was no automation involved, the gathered financial data was never guaranteed to be 100% accurate:

As big as the AWS business is, it truly was a surprise to learn that there were no easy ways to quickly calculate how much money the company was making on specific customers. AWS Finance teams were spending a big chunk of their time on the creation of manual Excel-based customer P&Ls instead of focusing on the most important element of their function: building financial processes and services that will assist AWS in running a financially healthy business, as well as winning new customers / markets:

There were easily accessible business metrics which clearly illustrated the major business problems that came with a lack of an automated customer P&L generation tool (metrics which unfortunately I'm not able to share) - especially for a rapid scaling business that is AWS. What did not exist was an understanding of our primary users' contexts, underlying needs, jobs-to-be-done, and pain points. As such, I began the project with the discovery user research phase.
‍

Based on a set of proto-personas previously defined, my PM and I recruited participants for a total of 9 user interviews. Following these sessions, I led a series of workshops with the entire team to synthesize these collected data. The main output from these workshops was an affinity map that illustrates high-level patterns of insights which we kept hearing over and over again from the user interviews. Patterns that could speak to both the WHAT (what users were doing) and the WHY (why they were doing it) of the users' contexts:

Based on these insights revealed by the affinity map, my next step was to re-define our primary personas with an emphasis on their general needs, goals, jobs-to-be-done, pain points, and tools. These personas proved to be very helpful to the team, as they helped us really empathize with our users and the problems we were solving for them:

To support the PM in his MVP features definition process, I went on to define individual user stories in the form of "As a [persona title], I need to [carry out an action], in order to [achieve a goal / address a need / get a job done]." Each user story relates back specifically to each of the defined personas:

At this point, we understood that what our users and business were asking for was a dynamic P&L solution. Essentially, a solution that would allow users to select a customer, input a variety of filter dimensions, generate a customer P&L based on these filters, dynamically modify these filters, and accordingly extract the relevant financial insights necessary for their analysis / forecasting works. A solution that would allow our users to truly slide and dice into all of AWS' financial data in association with its customers. A solution that did not (yet) exist, and one which we were tasked to design and build.

As the PM got to work on his product roadmap, I started creating a high-level user flow to envision what the end to end experience could be like for our users. I began by thinking big and long-term. Unrestrained by near-term boundaries and timelines, I asked myself what a successful experience would be like in the ideal world? What would be the ideal user flow? And, gradually, as I got more clarity around the MVP (or v.1) features requirements / technical constraints, I worked with my team to zone-in on specific flows and scenarios that would be prioritized for the v.1 release:

As always, I went through a very iterative process. I conducted design exploration workshops with my team to seek for early inspirations. Competitive analyses were commonly conducted at this stage:

And gradually, the early lo-fi wireframes came into picture. These were regularly shared with my team and stakeholders for early feedbacks and inputs. As a team, we advanced through multiple iterations of the lo-fi state as we got more and more clarity around feature requirements / technical constraints:

As I started to have a clearer vision of the  final product, I began coming up with more hi-fi mockups using design patterns and components from the AWS Design System. I also took these mockups out for usability testing to obtain important feedbacks from our users. During these sessions, It was common for me to typically prepare 2 different design approaches and tested both with users in order to get a sense of what would work and what wouldn't:

Ultimately, after 4 months of joining the team, I was able to deliver the final v.1 design specifications to my product and dev team for implementation. The product was conveniently named AWS Profitability Tool (APT), and below are a few sample screens.
‍

For the v.1 release, we wanted to provide users with a simple seamless experience that would allow them to address most of the basic important use cases. Fortunately, these use cases all shared a mutual simple ask: Generate an end-to-end P&L for a single customer.

Given this requirement, the landing page was designed to offer users the ability to quickly generate a P&L through a few simple clicks. Starting with the single customer selection (where each customer is known as a Global Ultimate Company):

The following selection, the P&L view selection, gives users the option to pick between 2 possible views of the P&L: 1) Summary, or 2) Services breakdown. As the names suggest, while the former offers an aggregated bird-eye view, the latter provides essentially the exact same data but broken down by the individual AWS services consumed by the customer in question:

The majority of users would opt for the Summary view. This is the easier path to take, as the next step is simply to click on the Generate P&L button:

Accordingly, the full P&L for the selected customer will be generated and displayed right below:

Once the P&L is generated, users can execute a number of actions. One of the most important actions is to further filter out this P&L by a single AWS service. This is where they can leverage the available Service filter - an advanced filter control that allows users to find and select any single AWS service used by the selected customer:

Users can also pick a different Time view, depending on what their unique financial analysis needs are. They can opt for a choice between the (default) last 13 months, last 5 quarters, last 3 years, or define a custom time period:

After 1 short year at AWS, I made the difficult decision to leave the company in order to pursue other career and personal growth opportunities. 1 year is a short time for a UX designer to produce a truly meaningful impact. While I was able to deliver the v.1 designs to the product and dev team for implementation (and later on v.2) within this time span, it definitely wasn't long enough for me to thoroughly observe our work's potential success / failure when put in the hands of users. Even as I was able to conduct ongoing usability testing throughout the process to validate my design choices, having real feedbacks from users as they attempt to use the live product to get their jobs done would have revealed a more eye-opening and holistic picture.
‍

As such, right before leaving AWS I checked back with my team to see how the negative business metrics we have identified from the beginning were making progress. By this point, a light alpha version for APT v.1 would have been made available to our entire user base. I won't be able to share the confidential data, but there definitely were positive signals from assessing these metrics. Additionally, my PM and I conducted 5 interviews with users from different groups to obtain more qualitative feedback. The goal was for me to put together a report on the current state of the APT UX - along with recommendations to the team going forward. Without digging too deep into details, these interviews gave me an opportunity to listen to our users talk about how the tool has really made a positive difference to their day-to-day works. It was definitely a point of validation for our team and for me as a UX designer. And in that respect, I'm happy to share a high-level overview of what these positive changes are:

Amazon was an amazing career growth opportunity for me, and I definitely made it a commitment to learn as much as possible during my time there. This project was no exception. Here're 2 important learnings I personally picked up along the way.
‍

The first lesson is one of the most important lessons anybody could learn from Amazon - the Working backwards process. With this project, we literally started from zero. We had a general understanding of the business need, we had an early draft of a Press Release (this was a common practice used by Amazon's product teams to envision what the ideal product would be like in the form of a potential future press release to the public - all before they even attempt building it), but it really took a collaborative team effort to work backwards from this business need to figure out exactly what problems were we trying to solve, whom were we solving them for, and how exactly was it going to impact the business.

As a UX designer, I was given the great opportunity to take part in these early conception and strategic planning conversations.
‍

A core component of my work for this project took the form of relationship building with important stakeholders (i.e. our senior leadership). Throughout the early phases of the project, I took the initiative to lead and participate in conversations that strived to communicate the long term UX / product vision to the organization. This gave me an amazing platform to really hone in on my communication and presentation skills. Ultimately, these conversations helped me build a solid level of trust with my stakeholders - a crucial factor that empowered me to set out on a design mission and create an impactful solution for some of the most important business problems faced by the company.