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 stepped into my first design leadership role as SkillsWave spun off from D2L.

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 covers the processes, activities, and strategic work I led to establish SkillsWave's design practice. 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 built into every stage of the process, represented by the two circles of hexagons in the diagram. 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 looked for opportunities to bring design into product decisions earlier and demonstrate the value of our new process. 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. We could no longer rely on D2L's dedicated research team and longer timelines. We needed practical, quicker ways to learn continuously 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

My team’s experience with AI tools as of October, 2025 was using ChatGPT to help with copy and “dabbling a little in Figma Make”. SkillsWave designers had no expectations and no corporate licenses for any AI tools unless AI was baked into something they were already using. Around November, 2025, there was pressure from the company to “adopt AI to move faster”, so I needed to see if AI tools could make a meaningful difference in the efficiency and speed of our work without compromising design rigour.


To address this, 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 to learn and set some guiding principles

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 understand if AI tools could work in our process

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

I started with prototyping in AI for two reasons:

  1. We were designing a new analytics experience, and we needed a prototype that could let us experiment with the look and feel of charts and graphs. I thought AI could potentially let us experiment before we got to development, and in the best case scenario, even test some of these interactions with users in usability testing.

  2. This was a common use case that designers in the industry started with

My 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. The process to run this experiment was more than just setting up any website for us to test prototypes — if we wanted to truly test ideas for Analytics, we had to have the context of the rest of the platform. This involved setting up development environments to run the product on our machines, learning how to use git and push things to PRs, and more.

While this was initially a huge lift, the pay-off was worth it. Now every designer has a local environment set up on their machine and can test any exploration they want in the real product. We could also test any confident exploration with users using our same PR deployment process.

This experiment involved a lot of collaboration with development. The process to run this experiment was more than just setting up any website for us to test prototypes — if we wanted to truly test ideas for Analytics, we had to have the context of the rest of the platform. This involved setting up development environments to run the product on our machines, learning how to use git and push things to PRs, and more.

While this was initially a huge lift, the pay-off was worth it. Now every designer has a local environment set up on their machine and can test any exploration they want in product. Additionally, we can test any confident exploration with users using our same PR deployment process with temporary environments.

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

I wanted to see if designers could use AI to make and ship small front-end changes with development approval. I chose this as the second experiment because I saw the opportunity to address more visual UI bugs that have a tendency of getting bumped down to the bottom of the defect list. My 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.

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

Experiment 1: Success 🎉

The prototyping experiment was extremely valuable and changed the way we did design exploration and final solution crafting (Explore and Make stages of our design process). It solved the immediate need we had in the Analytics project, and then 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 can directly take and use as a starting point in their implementations.

Example of early prototypes we created - the graphs in particular were a game changer for the Analytics project! More detailed prototypes are omitted due to confidentiality.

Another win: Prototypes that are deployed and sharable using our existing development deployment process 🎉

An additional win from this experiment was that our prototypes are now deployed and shared using existing development team processes. With every PR submitted, we create a temporary environment to test the PR. Design uses that same process to push a new prototype it to a PR, and share it using the same temporary environment link. While it did take me and the team some time to learn how git worked, it's a neat win that solved all of our needs and allowed developers to fully explore our prototypes without having to learn any new design tools. Designers also gained some empathy for development :)

Another win: Prototypes that are deployed and sharable using our existing development deployment process 🎉

An additional win from this experiment was that our prototypes are now deployed and shared using existing development team processes. With every PR submitted, we create a temporary environment to test the PR. Design uses that same process to push a new prototype it to a PR, and share it using the same temporary environment link. While it did take me and the team some time to learn how git worked, it's a neat win that solved all of our needs and allowed developers to fully explore our prototypes without having to learn any new design tools. Designers also gained some empathy for development :)

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 and sometimes just fighting with AI on small details than there were actual changes in product. We managed to get a couple of PRs merged, but that was usually after an hour of going back and forth with AI for a small change. It was faster for a developer to do most of the PRs we created, and sometimes the development team had to re-work the PR anyway.

The result: I don't force designers to make small product changes and often discourage it. Designers make PRs occasionally when the change is small and the payoff is clear, but I didn't implement it as a core workflow because it wasn't worth the time investment. I would rather have a designer working on design work than fixing small visual UI fixes. If the visual fix is important enough, it should be something development to takes on.

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 and sometimes just fighting with AI on small details than there were actual changes in product. We managed to get a couple of PRs merged, but that was usually after an hour of going back and forth with AI for a small change. It was faster for a developer to do most of the PRs we created, and sometimes the development team had to re-work the PR anyway.

The result: I don't force designers to make small product changes and often discourage it. Designers make PRs occasionally when the change is small and the payoff is clear, but I didn't implement it as a core workflow because it wasn't worth the time investment. I would rather have a designer working on design work than fixing small visual UI fixes. If the visual fix is important enough, it should be something development to takes on.

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.

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!)