Establishing a new high-performing design team at SkillsWave

Building SkillsWave's design team after its spin off from D2L as a new design leader.

My Role: Manager of Product Design

2 Designers, 45-Person Company

July 2024-present

I started as a new design manager at a new spin-off company called SkillsWave

In my first design leadership role, I helped establish SkillsWave’s design team after its spin-out from D2L. The company was ready to move faster and redefine itself outside of D2L. Design needed to prove its value in this new environment. I introduced a lightweight design process, coached two designers into broader ownership, brought design into strategic product work earlier, and built a lightweight research practice that gave the team more direct access to clients and users.


In short, I led design to become a trusted strategic partner in a new company.

Table of contents

This case study is a series of process, steps, activities and work I did to build the SkillsWave design team. It can be read in order, or you can jump to the section that interests you.

First, I created a design process that balanced speed with rigour

After the spin-off, we brought D2L's design process with us, but it quickly became clear that it had been built for a much larger enterprise product. SkillsWave needed a process that could move faster, without losing the user-centred rigour that made D2L’s approach valuable.

D2L's design process: Understanding, Empathizing, Exploring, Defining & Crafting, Testing & Iterating, Refining & Extending, Executing.

Also annotated with the left side saying "Resulted in months of upfront work to validate problems and solutions", and the right side saying "Limited opportunities to iterate, process ends at "shipped".

SkillsWave's Design Process

Lighter upfront work to accommodate shorter timelines

User validation and iteration occurs here, post-release

Hover or click on the image to see changes. Image has process stages labelled Influence, Align, Explore & Check, Make, Implement, Monitor. On hover it says "Lighter upfront work to accommodate shorter timelines" and "User Validation and iteration occurs here, post release".

Because SkillsWave was a smaller product with a different risk profile, we could release and learn in ways that would have been harder on a large, deeply embedded enterprise platform. I used that difference to create a lighter left side (similar to left diamond) that supported faster timelines while still preserving key exploration steps. This meant the team could move faster and release sooner, and then monitor post release, gather insights from users, and iterate. Iteration is baked in throughout the project, including non-linear visual (one loop of hexagons on left, one on the right). The hexagons themselves stayed as a small reminder of our origin story :).

The SkillsWave Design Process (Summarized)

The Result: The new process gave the design team and cross-functional teams a clearer way to work that aligned with SkillsWave's pace. It was lighter than D2L's process, but still grounded in user-centred rigour, iteration, and post-launch learning.

Next, I opened up more opportunities for design to contribute, starting with admin roles and permissions

Once the team had a clearer way of working, I started looking for places where design could help SkillsWave make better product decisions earlier. I did this because I wanted to showcase design's value, with our new process, as fast as possible. The original "dev-only" admin roles and permissions project became my next opportunity.

Changing roles and permissions from "a dev project" to a growth project

At first, roles and permissions looked very technical, but I saw roles and permissions as critical for future product growth. Roles and permissions would shape how SkillsWave scaled operationally and could influence future customer-facing admin experiences. I also saw this as an opportunity for one of my newer designers to learn more about the product and grow in system analysis skills.

I created an admin inventory board and gave design a meaningful space to contribute

An image of the admin inventory board I created and collaborated with my designer on. The left says "My Problem Refinement and Context setting", the middle says "My structure, an 'Admin Inventory', and the right says "My team member's exploration, each square was a different part of admin!"

I carved out time before roles and permissions for design to work on this project before development would start. I started with creating an “admin inventory” board, planned out the system analysis pieces, then told my designer to document every feature and learn how it worked.


She discovered that roles and permissions would be integral to many internal team workflows. Almost every other team outside of product used admin. If we removed important permissions, we could disrupt business. Design became integral not only to creating future-proof roles and permissions, but creating the internal permission sets themselves. My designer took on putting the permission sets together and designing the roles and permissions page that was later re-used in our customer facing self-serve offering.

The Result: Design made key contributions to a previously "dev-only" project and the work was re-used later in a customer facing feature. Design's work on admin roles and permissions resulted in smoother admin workflows, a more scalable permissions model, and a meaningful growth opportunity for a designer on my team.

Then, I jumped in with design strategy to create clarity around PLG

Then, I jumped in with design strategy to create clarity around our self serve (PLG) offering

When SkillsWave spun out, there was a clear business goal we were heading towards: introduce a self-serve (product led growth) option for mid-market employers, nicknamed PLG.

At the beginning of the project, everyone had a different definition of PLG. Product thought it was onboarding, marketing was focused on pricing and acquisition, and some teams thought it was a new feature launch.

What is Product Led Growth (PLG)?

I saw an opportunity for design to create shared understanding before the company moved too far into siloed execution

With the PLG project, I saw an opportunity to foster alignment and move forward as a group. This would prove design's value more, and show the value of design strategy in the most impactful project. My goal was to thoroughly understand PLG as a general business model, the user experience pieces related to that model, and then create a shared language, understanding, and a journey that everyone could map their activities to when thinking about PLG and SkillsWave.

A section of my PLG research Miro board, taking in inputs from across the company, secondary research, and more.

To do this, I took all of the research and inputs and created a living document called The Stages of PLG. Each stage had a part of a user's self-serve journey accounted for, from searching and browsing our marketing site through to paying for upgrades. This gave us a simple way to bucket all of the work, user goals, business metrics, KPIs, and more into tangible stages of what our product would look like in a PLG model.

The first draft of the high-level stages of PLG for SkillsWave. These stages have been updated since this initial draft, but further details have been omitted due to confidentiality.

I also mapped SkillsWave’s existing product experience to those stages, highlighting where users already experienced value, where the journey broke down, and where new product work would be needed. This helped turn a broad business strategy into some actionable next steps.

A product journey map of SkillsWave, key moments of existing value, gaps, and opportunities, all mapped to the PLG stages.

After this research, I presented it to all of the senior leadership team, starting with the stages of PLG and then talking specifically to the CEO and product team about the customer journey map. After seeing the stages of PLG, leaders understood where their work fit in our PLG initiative. People started using the language and stages outlined in the presentation, and people moved forward with clarity, framing their work in the stage of PLG they were focused on.

With that in hand, the product team began confidently working on the Setup and Showcase phase. The stages of PLG and the customer value journey map allowed us to move forward with confidence that "Set up and Showcase" would unlock the ability to test our PLG offering in the market. It also helped us stay aware that more work needed to be done after this stage to provide value within our product during the PLG workflow.

A designer on my team owned the detailed design, while I helped set the PLG direction through critique and working sessions. I pushed for the experience to feel simple, encouraging, and celebrate moments of success, while also being measurable enough for us to monitor and iterate after launch.

Result: My design strategy and framing gave the company shared language for framing their work in the context of the whole PLG journey. The first phase of our self-serve offering launched in June 2025 and has helped support new pilot clients, enabled sales to give their prospects a free offering to try, and is in the process of helping open a door to a large confidential client opportunity.

From there, I made user research a repeatable team practice

SkillsWave didn’t have a dedicated research team, so once I had a couple of instances proving the value of the design team, I knew I needed to focus on research. Research could no longer on D2L's solid user research team or longer timelines. We needed practical, quicker ways to learn continously from our users.

To solve this, I started building research into the team’s rhythm through lightweight studies, client partnerships, and quick but structured synthesis. Additionally, I wanted to build the team's confidence planning and facilitating research and get us all in the rhythm of regularly looking for opportunities to learn from users with our available resources.

SkillsWave Guide Focus Group and 1:1 Interviews (our first study)

SkillsWave didn’t have a dedicated research team, so research could not depend on good conditions, a user research team, or long timelines like we had at D2L. I knew the design team needed practical ways to learn continuously from users.

I started building research into the team’s rhythm through lightweight studies, client partnerships, and quick but structured synthesis. Additionally, I wanted to build the team's confidence planning and facilitating research and get us all in the rhythm of regularly looking for opportunities to learn from users with the resources we had.

I partnered with Client Success to reach a large existing client to run ran a series of focus groups and interviews, and helped translate the findings into product improvements. I also looped one of my designers into facilitating the 1:1 interviews and analyzing the results of this study.

To start, I partnered with Client Success to reach a large existing client and run a study to understand how they were using SkillsWave Guide. After some discussions, they agreed to a series of focus groups and 1:1 interviews on the condition that we would share back some of the findings. We ran 5 focus groups and 7 1:1 interviews asking people about their experience using SkillsWave Guide and walking through their current set up of it.

This study was completed by myself and another designer on my team. I set up the logistics, organized the sessions, and came up with most of the activities for the focus groups, and my designer focused on the 1:1 interviews and the post-study analysis.

SkillsWave Guide Study Results: A very successful study that led to practical SkillsWave Guide and other improvements including better skill searching, better search in our catalog, and better priority of recommendations

This is a Miro board we used for the SkillsWave Guide research. It includes background questions and ice breakers, and a Rose, Bud, Thorn activity where users could mark different parts of SkillsWave Guide with what they liked and what they struggled with.

SkillsWave Guide Study Results: A very successful study that led to practical SkillsWave Guide and other improvements including better skill searching, better search in our catalog, and better priority of recommendations

SkillsWave Guide Study Results: A very successful study that led to practical SkillsWave Guide improvements and general product improvements including better skill searching, better search in our catalog, and better priority of recommendations. The designer in my team also learned a lot about facilitating sessions and session analysis that they have brought into other studies since then.

After the study, we improved search on our skill set page by adding skills to the search context and highlighted those skills within the skill sets after search. Before this study, only skill set names could be searched.

Second Example: L&D "System Implementation" Research

I recruited through internal networks and ran journey-mapping sessions with L&D leaders to understand how they evaluate, adopt, and roll out new tools. This was done through "advertising" my plans at multiple senior leadership calls. Senior leaders reached out to me with contacts and I interviewed them using this live journey mapping activity below as a guide.

This was a "live journey mapping" activity I created for L&D leaders to walk through a time when they implemented a new tool or system in their company. I took notes and built the journey map as they were speaking. Details removed due to confidentiality.

L&D "System Implementation" Research Results: The report became an input into our self-serve PLG initiative to start to understand how L&D leaders think about implementing new software systems in their companies.

Additional benefit: Team Research Habits and designers who can all run usability research sessions

I coached designers through research planning, interview guides, facilitation, note-taking, synthesis, and sharing insights back to the team. Now all of my team members have planned, facilitated, and analyzed at least 2 usability studies each, and one of my team members created templates for future research recruiting, planning, and analyzing.

The Results: Research has become a regular part of how we design, and the business strongly supports us continuing to look for ways to connect with our users. We regularly connect with client success on opportunities for research and everyone on my team knows how to plan, facilitate, and analyze a usability study. We've run 5 studies so far! Our latest study used AI prototypes made with Claude 🎉

And most recently, I introduced and integrated AI tooling into our design process

As AI started changing how product teams worked, I wanted to make sure our design team was learning alongside it without losing the user-centred thinking behind our process. I introduced a series of experiments to understand where AI could improve the way we explore, prototype, and make product design decisions.


In short, I led the design team to meaningfully integrate AI into our design process, making it part of our everyday tool belt without losing core design and user-centred thinking.

First, I organized a workshop and planned two experiements

A sneak peak into where I've started 👀

A sneak peak into where I've started 👀

I organized a workshop with the head of design at Plotly to explain his process using AI tools. For context, in October 2025, designers were just beginning to venture into creating PRs, fully fleshed "production-like" prototypes, and many experiments that fell somewhere between Lovable prototypes and real working code. This workshop was with a design lead who had fully jumped into AI tooling by that point, so it presented a perspective and workflow that was completely different from how my team was working.

After that workshop, I set a few principles for how I wanted to approach the integration of AI tools within my team. I wanted it to support our design thinking, not replace it; I wanted us to learn quickly by experimenting and sharing feedback; and I wanted the team to know that if something wasn’t useful, we could always revert back. These principles gave us guardrails before we started figuring out where AI could actually fit into the design process.

These were the principles I wanted my integration of AI to follow — an AI tool or experiment using that tool wouldn't work for our design process if it failed one of these criteria. The principles listed in this photo are: Support design thinking with AI (don't replace), Learn quickly (experiment and provide feedback), and Can revert back if it fails.

Then I created two experiments to test out AI tools on our team

Experiment 1: Try AI Prototyping in a product-like environment with the ability to share prototypes (Explore & Check)

Experiment 1 would solve our immediate problem around research with a product we were designing and could be a game changer for us making our ideas more tangible, including testing interactions and visuals quickly within our team and in user research. The measure of success was: Could we communicate our ideas more efficiently and effectively using these tools, or were our Figma methods still the best approach?

This is what our real product looks like and each designer has their own environment to test ideas here.

This experiment involved a lot of collaboration with development. We had to have dev environments fully set up on our machines and learn how to use them. While this was quite a bit of work, the pay off was worth it not only in terms of the eventual success of the experiment, but it also gave us more insight into the development process and how things like PRs and deployments work.

Experiment 2: Design ships small PRs with development approval (Make & Implement)

The second experiment was about whether designers could use AI to make and ship small front-end changes with development approval. The idea was that things like minor bug fixes or consistency improvements could potentially move faster if design was able to tackle them instead of handing them off. The measure of success for this experiment was: Would we see a meaningful increase in visual fixes within product? Would having design fix these bugs be an efficient use of time?

This is a real PR created by the design team that was merged into the product. It's small on purpose, and all PRs are reviewed and merged by developers to avoid code conflicts or other product issues.

Finally, I measured the results and implemented the processes that worked

Experiment 1: Success 🎉

The prototyping experiment ended up being much more valuable than I expected. It solved the immediate problem we had with a project in flight where we needed a better way to explore complex interactions, filters and states than Figma could realistically give us. From there, it grew into something bigger: AI-assisted prototyping became a core part of how we explore ideas, refine interactions, and communicate behaviour to development. Since then, we moved beyond one-off prototypes and started using a mix of design prototypes and front-end only testing environments that developers could directly take and use in their implementations.

The biggest shift was that we were no longer limited to mocking up what it should look like, we could actually mock up how it should behave. That has made ideas more tangible, helped us test interactions more realistically, and has given design a much stronger way to communicate their designs before hashing through it with a developer.

Experiment 1: Success 🎉

The prototyping experiment ended up being much more valuable than I expected. It solved the immediate problem we had with a project in flight where we needed a better way to explore complex interactions, filters and states than Figma could realistically give us. From there, it grew into something bigger: AI-assisted prototyping became a core part of how we explore ideas, refine interactions, and communicate behaviour to development. Since then, we moved beyond one-off prototypes and started using a mix of design prototypes and front-end only testing environments that developers could directly take and use in their implementations.

The biggest shift was that we were no longer limited to mocking up what it should look like, we could actually mock up how it should behave. That has made ideas more tangible, helped us test interactions more realistically, and has given design a much stronger way to communicate their designs before hashing through it with a developer.

Example of early prototypes we created - the graphs in particular were a game changer to create and tweak using AI!

Experiment 2: PRs were slow to create and not very efficient

Technically, designers could create PRs, but the value was smaller than we expected. There was more overhead troubleshooting environments and sometimes just “fighting with AI” than there was in the actual change itself. We managed to get a couple of PRs in, but the pay off was often an hour of going back and forth with AI for a small development change. It was faster for a developer to do it.

The result: We didn’t force it into the process. Designers still use this approach occasionally when the change is small and the payoff is clear, but it never became a core workflow in the same way prototyping did. That was still a useful outcome for our team because the goal was never to use AI everywhere, it was to figure out where it genuinely made the team more effective and where it wasn't worth it. We still occassionally submit a PR, but it's not a core part of our role.

Experiment 2: PRs were slow to create and not very efficient

Technically, designers could create PRs, but the value was smaller than we expected. There was more overhead troubleshooting environments and sometimes just “fighting with AI” than there was in the actual change itself. We managed to get a couple of PRs in, but the pay off was often an hour of going back and forth with AI for a small development change. It was faster for a developer to do it.

The result: We didn’t force it into the process. Designers still use this approach occasionally when the change is small and the payoff is clear, but it never became a core workflow in the same way prototyping did. That was still a useful outcome for our team because the goal was never to use AI everywhere, it was to figure out where it genuinely made the team more effective and where it wasn't worth it. We still occassionally submit a PR, but it's not a core part of our role.

Where we are now: AI is a key tool in our design tool belts and used throughout our process

This is our design process now. We use AI tools primarily in Explore and Check and Make phases, and we're looking at how we can more efficiently help provide useful assets for implementation next.

Since running these two experiments, AI has become a core part of how we work through Explore & Check and Make, to the point where Figma now plays more of a supporting role than it used to. We’re continuing to push that further by exploring how design outputs can become more usable in implementation, especially through front-end work that developers can take and build from directly.

Our design process has not changed, and that was intentional. We want to use AI where it meaningfully improves the work (speed, quality, depth, etc.), without forcing it into parts of the process where the value is really in conversation, context, user-centred thinking, and shared understanding.

The Results: AI has become a meaningful part of our design process. We haven't lost the user-centred design thinking rigour, but we have gained speed, efficiency, and a quicker path to high fidelity prototypes that we can test and refine.

Where we are now: A trusted design team with a strong voice in shaping product strategy and direction

The design processes, strategic frameworks, and team research practices I put in place during SkillsWave’s first years helped establish design as a respected function across the company. We now play a key role in shaping new features and workflows, and we are known for bringing clarity, polished experiences, and strong cross-functional collaboration. We've also fully implemented AI tooling into our design process and are further exploring ways to be more efficient in our work while still keeping our user-centred focus.

The design processes, strategic frameworks, and team practices I put in place during SkillsWave’s first years helped establish design as a respected function across the company. We now play a key role in shaping new features and workflows, and we are known for bringing clarity, polished experiences, and strong cross-functional collaboration. The foundation I built has also created new opportunities for the team, including budget for AI tooling, more direct access to clients, and multiple usability studies with both clients and non-clients.

Since 2024, the design team has designed and helped launch:

  • A self-serve product-led growth model

  • SkillsWave Guide

  • A new learner profile

  • Improved semantic search and skill tagging

  • A new employee widget

  • Multiple improvements to provider and approval workflows

  • Coming soon: A new analytics experience

  • And more! (and more on the way!)