Amazon's promotion process was opaque. We built a career development LMS that gave employees, managers, and HR a shared source of truth, for the first time.
The difference between L4 and L5, or L5 and L6, is a real jump in compensation, scope, and career trajectory. But for most employees, the path to promotion was opaque. Managers described expectations differently. Required competencies weren't standardized. Employees didn't know what "ready" actually looked like until they were told they weren't there yet.
Employees had no visibility into what specific competencies they needed to demonstrate to reach the next level.
Managers described promotion criteria inconsistently across teams, creating inequity in the process.
HR had no aggregate view of promotion pipeline health. Calibration sessions were manual and time-consuming.
There was no single platform connecting learning, feedback, assessments, and promotion readiness in one place.
Both of those are true at the same time, and leaving either one out misrepresents the job. Internal Creative Services was a studio: several designers and artists in one group, serving the business. Inside it I was an L5 who owned projects end to end, this platform included, which meant arguing for design decisions in rooms full of PMs and engineers rather than being handed a spec.
The most critical early insight was that each user type had a fundamentally different relationship with the same data. We designed three distinct experiences on one unified platform.
Four screens spanning employee, manager, and HR experiences, designed across three distinct user flows.
The production work is under NDA, so these are rebuilds of my own designs, remade in Amazon's retail identity for this case study rather than exported from the shipped product. The structure, hierarchy and flows are the ones I designed. There is no live prototype to click through for the same reason: the platform is internal to Amazon.
The hardest parts of this project were not screens. They were arguments about who the product was for and what it was allowed to show.
Options Ship manager and HR views first, which is what the business was asking for, or hold the launch until the employee view was ready alongside them.
Chose Employee first. The person being assessed sees their readiness before anyone reviews them.
Why A readiness score an employee cannot see is a performance review they are not in the room for. On compensation-affecting data that is not a UI preference, it is the product's ethics.
Trade-off It delayed what stakeholders wanted most and cost me the project's longest argument. The reflection on this page calls it the most important conversation I had, and it was not about UI.
Options Build one platform with role-based permissions, which is faster and cheaper, or design three distinct experiences over one source of truth.
Chose Three experiences, framed that way before any UI existed.
Why Each user type had a fundamentally different relationship to the same data. An employee needs guidance, a manager needs to scan many people quickly, leadership needs aggregate equity signals. Permissions hide fields; they do not change what a screen is for.
Trade-off Three times the design surface and three flows to keep coherent as the model changed underneath them.
Options Iterate visibly on screens, which is the legible portfolio story, or take findings back into how readiness was represented at all.
Chose The model. What changed on this project was the underlying structure, not visible screen versions.
Why The competency language and the readiness model were where the confusion actually lived. Reskinning a dashboard built on the wrong model would have looked like progress and fixed nothing.
Trade-off It leaves a thinner visual process story than a before-and-after strip would. That is the honest shape of this project and I would rather say so than manufacture versions.
Results measured at 90 days post-launch against pre-launch baseline across Amazon Creative Services. These are internal Amazon figures and are not publicly verifiable, which is why no source is linked; they are the numbers reported to me at the time and the ones that appear on my résumé.
"The most important conversation I had on this project wasn't about UI. It was convincing stakeholders that employees needed to see their own data before managers did."
Designing for high-stakes decisions requires extra care around information hierarchy. When data directly affects someone's promotion and compensation, every label carries weight. The manager/employee visibility boundary was the hardest UX problem on the project. Getting it wrong would have destroyed trust in the entire system.
Internal Creative Services was a studio, several designers and artists in one group, so I spent a lot of time advocating for decisions in rooms full of PMs and engineers who moved fast. Inside that studio I also ran solo projects, this one included, where the calls were mine from framing through to build. The two modes teach different things. Alignment turns out to be a design artifact in its own right, and you only really learn that in the first mode.