AWS Learning Platform
Turning a complex training ecosystem into a strategic priority
A unified learning platform for AWS's global field organization. I was the sole designer, working with a senior UX researcher and PM to consolidate a fragmented training ecosystem into a single coherent experience.
Screens shown are recreated to illustrate the design decisions and are not representative of actual AWS UI.
Client
Amazon Web Services
Role
Product Designer
Team
Sr. UX researcher/PM
Industries
Enterprise
Timeline
2023-2024
AWS Learning Platform
Turning a complex training ecosystem into a strategic priority
A unified learning platform for AWS's global field organization. I was the sole designer, working with a senior UX researcher and PM to consolidate a fragmented training ecosystem into a single coherent experience.
Client
Amazon Web Services
Role
Product Designer
Team
Sr. UX researcher/PM
Industries
Enterprise
Timeline
2023-2024
Screens shown are recreated to illustrate the design decisions and are not representative of actual AWS UI.
AWS Learning Platform
Enter password to view case study
Enter password to view case study
Enter password to view case study
The problem
AWS Worldwide Field Enablement supports training for tens of thousands of learners globally, across regions, roles, and levels of seniority.
Over time, the training landscape grew organically across multiple tools, each one making sense on its own terms even as the whole stopped making sense as a system.
Learners had no reliable signal of where they stood or what to do next:
❌ No shared starting point
❌ No clear progression path
❌ No single place to even understand what the training ecosystem contained
From the outside, it looked like a system. From the inside, it felt like guesswork. The challenge was not to rebuild everything: it was to find what a unifying product layer could look like, and make the case for it.
Making sense of a complex system
I was the sole designer on this initiative, working closely with a UX researcher who led stakeholder management and learner interviews. He shared qualitative research with me, and before defining any design direction I worked through extensive internal documentation myself, rather than approach a problem this layered with assumptions:
🔹 Platform overviews
🔹 Tooling inventories
🔹 Team ownership maps
What emerged from that grounding was not a single problem so much as a cluster of related ones:
❌ Fragmented entry points
❌ No shared proficiency baseline
❌ No personalised direction once learners were already inside the system
Understanding how those pieces connected to each other was the real work of the discovery phase. I reframed them into two foundational problems that could anchor a focused product approach: learners did not know where they stood, and they did not know what to do next. Everything I designed afterward came back to answering those two things.
An exercise in restraint
Before getting to the solution, it’s worth naming what the constraints actually were, because they shaped every design decision that followed.
🔹 Scope. Proposing a full platform replacement wasn’t a realistic starting point, given how many existing tools the new layer would need to account for and how disruptive a rebuild would have been to learners already mid-course. The only viable path was an additive layer sitting above the existing tools, one that improved the experience without requiring anything already built to change underneath it.
🔹 The design system itself. Tight and opinionated enough that visual expression could not do the work of solving problems here. Clarity had to come from structure and logic, not styling, and that constraint shaped some of the paths I designed later: the components available set the terms, so the interaction had to be built from what the system offered rather than a blank-canvas ideal. Working inside a system that refuses to flex meant every decision had to be defensible on logic alone, a different discipline than designing with more room to move.
The solution
My first instinct was to build all of it into one consolidated dashboard, a single screen that tried to resolve proficiency, recommendations, and guidance at once.
It felt efficient on paper. In practice it asked a learner to absorb three different kinds of decisions in one glance, which worked against the clarity I was trying to create.
I split it into three distinct flows instead:
✅ An assessment to establish a baseline
✅ A recommendation surface tied to that baseline
✅ A conversational guide for on demand direction
What I kept from that first instinct was a lightweight home view: not a place to resolve any of the three, but a place to see where you stood and get pointed toward whichever flow mattered that day.
Three-part learning model
📝 Skills assessment. To establish a shared baseline. Before a learner could be directed anywhere, the system needed to know where they were actually starting from, and the assessment gave both the learner and the platform that shared understanding of current proficiency.
🎯 Personalised training recommendations. Tied directly to that baseline. Once the system knew where a learner stood, it could stop showing them the full catalogue and start showing them the handful of things that actually mattered for their role and level, not a generic onboarding path.
💬 Conversational chatbot. For on-demand guidance. Recommendations could point a learner in a direction, but the ecosystem was too complex to navigate from a list alone, so the chatbot let people ask questions in natural language and get contextual suggestions without first needing to understand how the platform was structured underneath. It met them where they were.
I designed high-fidelity wireframes and interactive prototypes for all three flows, working within the constraints of the existing design system throughout. The limited component set meant some interactions took more steps than they should have,
since the simplest version of a path wasn’t always one the system could build.
Designing for engagement
Most of this training was also mandatory, which meant the platform was competing with low motivation by default. Knowing where you stood and what to do next doesn't automatically make either feel worth acting on, not when the thing you're being asked to act on is something you have to do rather than something you chose.
The researcher and I made a deliberate decision to design for that directly:
🔹 An expertise score that moved as a learner progressed
🔹 A streak that rewarded consistency rather than one-off effort
🔹 A sense of where someone stood relative to their peers
None of it replaced the core product logic, it sat on top of it, so that correct direction also felt worth showing up for. The home view carries this most directly, since it's the first thing a learner sees on opening the platform, before they've chosen which flow to enter.
Designing for engagement
That sense of momentum needed somewhere to live beyond a single glance at the home screen.
My Learning became the place where it accumulated:
✅ Active courses picked up where a learner left off
✅ Certification paths marked how far there was left to go
✅ A completed history turned the streak and the score into something that was clearly adding up rather than resetting every time someone logged back in
Designing for engagement
The AI assistant followed the same principle. It started as a floating action button, something you summoned when needed and dismissed when not. That framed it as a tool separate from the learning, external to the journey rather than part of it. Making it collapsible changed what it was. Present throughout but never forced into view, it became less of a chat bot and more of a guide that stayed with you as you moved through the platform, there when you needed it, out of the way when you didn't.
Evolution of AI entrypoint
Impact
The work was presented to a VP, and the initiative was elevated from exploratory design work to a funded strategic priority.
From there, it transitioned to a dedicated product team in Seattle, who continued development from the foundation I handed over. I documented the end-to-end journey, the design rationale, and the product direction in enough detail that the incoming team could move forward without re-framing the problem or repeating the discovery I'd already done.
A first version of the platform launched in 2025, the first phase of a staged rollout. The work I designed, the assessment, the recommendations, the chatbot, was slated for a later phase, and I moved on to other projects before that phase went live. What I can speak to with confidence is the handover: the thinking held up well enough to be carried forward without anyone needing to start over.
The signal I trust most isn't the funding decision. It's that the Seattle team never had to reach out and ask what a decision meant, they built past where I left off without reopening discovery I had already done.
What I took away
I came into this project thinking my job was to design a platform. I left realising my job was to make a complex problem legible enough that other people could act on it, and the screens themselves were almost incidental to that.
What I was really building was shared understanding, of the problem, the constraints, and what was worth doing first. The handover is what proved that to me: understanding either transfers cleanly to someone else or it doesn't, and there's no partial credit for having it only in your own head.
Working without a dedicated team also meant holding the strategic and the tactical at the same time. The researcher was doing double duty as the de facto PM, which meant there was no separate product function to hand decisions off to, no design lead to check my reasoning against. Knowing when to go deep on craft and when to step back and question the brief is something I had to figure out without anyone else's judgment to lean on. That's the skill I keep reaching for.
Impact
The work was presented to a VP, and the initiative was elevated from exploratory design work to a funded strategic priority.
From there, it transitioned to a dedicated product team in Seattle, who continued development from the foundation I handed over. I documented the end-to-end journey, the design rationale, and the product direction in enough detail that the incoming team could move forward without re-framing the problem or repeating the discovery I'd already done.
A first version of the platform launched in 2025, the first phase of a staged rollout. The work I designed, the assessment, the recommendations, the chatbot, was slated for a later phase, and I moved on to other projects before that phase went live. What I can speak to with confidence is the handover: the thinking held up well enough to be carried forward without anyone needing to start over.
The signal I trust most isn't the funding decision. It's that the Seattle team never had to reach out and ask what a decision meant, they built past where I left off without reopening discovery I had already done.
What I took away
I came into this project thinking my job was to design a platform. I left realising my job was to make a complex problem legible enough that other people could act on it, and the screens themselves were almost incidental to that.
What I was really building was shared understanding, of the problem, the constraints, and what was worth doing first. The handover is what proved that to me: understanding either transfers cleanly to someone else or it doesn't, and there's no partial credit for having it only in your own head.
Working without a dedicated team also meant holding the strategic and the tactical at the same time. The researcher was doing double duty as the de facto PM, which meant there was no separate product function to hand decisions off to, no design lead to check my reasoning against. Knowing when to go deep on craft and when to step back and question the brief is something I had to figure out without anyone else's judgment to lean on. That's the skill I keep reaching for.
Turning a complex training ecosystem into a strtategic priority
A relocation app built for the chaos of moving to a new country. I led the product design and handled a large part of the development too. Rails, real-time chat, an AI powered document scanner, and the full design system.
Client
Independent project
Role
Design and Dev Lead
Team
3 fullstack engineers
Industries
Govtech
Timeline
April 2026
Turning a complex training ecosystem into a strtategic priority
A relocation app built for the chaos of moving to a new country. I led the product design and handled a large part of the development too. Rails, real-time chat, an AI powered document scanner, and the full design system.
Client
Independent project
Role
Design and Dev Lead
Team
3 fullstack engineers
Industries
Govtech
Timeline
April 2026
The problem
AWS Worldwide Field Enablement supports training for tens of thousands of learners globally, across regions, roles, and levels of seniority.
Over time, the training landscape grew organically across multiple tools, each one making sense on its own terms even as the whole stopped making sense as a system.
Learners had no reliable signal of where they stood or what to do next:
❌ No shared starting point
❌ No clear progression path
❌ No single place to even understand what the training ecosystem contained
From the outside, it looked like a system. From the inside, it felt like guesswork. The challenge was not to rebuild everything: it was to find what a unifying product layer could look like, and make the case for it.
Making sense of a complex system
I was the sole designer on this initiative, working closely with a UX researcher who led stakeholder management and learner interviews. He shared qualitative research with me, and before defining any design direction I worked through extensive internal documentation myself, rather than approach a problem this layered with assumptions:
🔹 Platform overviews
🔹 Tooling inventories
🔹 Team ownership maps
What emerged from that grounding was not a single problem so much as a cluster of related ones:
❌ Fragmented entry points
❌ No shared proficiency baseline
❌ No personalised direction once learners were already inside the system
Understanding how those pieces connected to each other was the real work of the discovery phase. I reframed them into two foundational problems that could anchor a focused product approach: learners did not know where they stood, and they did not know what to do next. Everything I designed afterward came back to answering those two things.
An exercise in restraint
Before getting to the solution, it’s worth naming what the constraints actually were, because they shaped every design decision that followed.
🔹 Scope. Proposing a full platform replacement wasn’t a realistic starting point, given how many existing tools the new layer would need to account for and how disruptive a rebuild would have been to learners already mid-course. The only viable path was an additive layer sitting above the existing tools, one that improved the experience without requiring anything already built to change underneath it.
🔹 The design system itself. tight and opinionated enough that visual expression could not do the work of solving problems here. Clarity had to come from structure and logic, not styling, and that constraint shaped some of the paths I designed later: the components available set the terms, so the interaction had to be built from what the system offered rather than a blank-canvas ideal. Working inside a system that refuses to flex meant every decision had to be defensible on logic alone, a different discipline than designing with more room to move.
The solution
My first instinct was to build all of it into one consolidated dashboard, a single screen that tried to resolve proficiency, recommendations, and guidance at once. It felt efficient on paper.
In practice it asked a learner to absorb three different kinds of decisions in one glance, which worked against the clarity I was trying to create.
I split it into three distinct flows instead:
✅ An assessment to establish a baseline
✅ A recommendation surface tied to that baseline
✅ A conversational guide for on demand direction
What I kept from that first instinct was a lightweight home view: not a place to resolve any of the three, but a place to see where you stood and get pointed toward whichever flow mattered that day.
Three-part learning model
📝 Skills assessment. To establish a shared baseline. Before a learner could be directed anywhere, the system needed to know where they were actually starting from, and the assessment gave both the learner and the platform that shared understanding of current proficiency.
🎯 Personalised training recommendations. Tied directly to that baseline. Once the system knew where a learner stood, it could stop showing them the full catalogue and start showing them the handful of things that actually mattered for their role and level, not a generic onboarding path.
💬 Conversational chatbot. For on-demand guidance. Recommendations could point a learner in a direction, but the ecosystem was too complex to navigate from a list alone, so the chatbot let people ask questions in natural language and get contextual suggestions without first needing to understand how the platform was structured underneath. It met them where they were.
I designed high-fidelity wireframes and interactive prototypes for all three flows, working within the constraints of the existing design system throughout. The limited component set meant some interactions took more steps than they should have, since the simplest version of a path wasn’t always one the system could build.
That sense of momentum needed somewhere to live beyond a single glance at the home screen.
My Learning became the place where it accumulated:
✅ Active courses picked up where a learner left off
✅ Certification paths marked how far there was left to go
✅ A completed history turned the streak and the score into something that was clearly adding up rather than resetting every time someone logged back in
That sense of momentum needed somewhere to live beyond a single glance at the home screen.
My Learning became the place where it accumulated:
✅ Active courses picked up where a learner left off
✅ Certification paths marked how far there was left to go
✅ A completed history turned the streak and the score into something that was clearly adding up rather than resetting every time someone logged back in
The AI assistant followed the same principle. It started as a floating action button, something you summoned when needed and dismissed when not. That framed it as a tool separate from the learning, external to the journey rather than part of it. Making it collapsible changed what it was. Present throughout but never forced into view, it became less of a chat bot and more of a guide that stayed with you as you moved through the platform, there when you needed it, out of the way when you didn't.
The AI assistant followed the same principle. It started as a floating action button, something you summoned when needed and dismissed when not. That framed it as a tool separate from the learning, external to the journey rather than part of it. Making it collapsible changed what it was. Present throughout but never forced into view, it became less of a chat bot and more of a guide that stayed with you as you moved through the platform, there when you needed it, out of the way when you didn't.
Evolution of AI entrypoint
Evolution of AI entrypoint
Impact
The work was presented to a VP, and the initiative was elevated from exploratory design work to a funded strategic priority.
From there, it transitioned to a dedicated product team in Seattle, who continued development from the foundation I handed over. I documented the end-to-end journey, the design rationale, and the product direction in enough detail that the incoming team could move forward without re-framing the problem or repeating the discovery I'd already done.
A first version of the platform launched in 2025, the first phase of a staged rollout. The work I designed, the assessment, the recommendations, the chatbot, was slated for a later phase, and I moved on to other projects before that phase went live. What I can speak to with confidence is the handover: the thinking held up well enough to be carried forward without anyone needing to start over.
The signal I trust most isn't the funding decision. It's that the Seattle team never had to reach out and ask what a decision meant, they built past where I left off without reopening discovery I had already done.
What I took away
I came into this project thinking my job was to design a platform. I left realising my job was to make a complex problem legible enough that other people could act on it, and the screens themselves were almost incidental to that.
What I was really building was shared understanding, of the problem, the constraints, and what was worth doing first. The handover is what proved that to me: understanding either transfers cleanly to someone else or it doesn't, and there's no partial credit for having it only in your own head
Working without a dedicated team also meant holding the strategic and the tactical at the same time. The researcher was doing double duty as the de facto PM, which meant there was no separate product function to hand decisions off to, no design lead to check my reasoning against. Knowing when to go deep on craft and when to step back and question the brief is something I had to figure out without anyone else's judgment to lean on. That's the skill I keep reaching for.
Designing for engagement
Most of this training was also mandatory, which meant the platform was competing with low motivation by default. Knowing where you stood and what to do next doesn't automatically make either feel worth acting on, not when the thing you're being asked to act on is something you have to do rather than something you chose.
The researcher and I made a deliberate decision to design for that directly:
🔹 An expertise score that moved as a learner progressed
🔹 A streak that rewarded consistency rather than one-off effort
🔹 A sense of where someone stood relative to their peers
None of it replaced the core product logic, it sat on top of it, so that correct direction also felt worth showing up for. The home view carries this most directly, since it's the first thing a learner sees on opening the platform, before they've chosen which flow to enter.
