The Course Drafts project became the first test of a new, disciplined approach to product development at Skilljar. Previously, initiatives often took months to launch, making time to market slow and errors costly. Our new VP of Product challenged the organization to focus on shorter, MVP-sized releases that delivered value faster while reducing risk.
Drafts touched one of the most sensitive parts of the Skilljar platform: how academy content moves from idea to live production. The publishing model had long forced customers to make changes directly against live content. Introducing flexibility had been discussed before, but concerns about data integrity, performance, and system complexity repeatedly stalled progress.
When the project shipped, we had more than a new feature. We had a new model for moving from idea to engineering, and an experience that allowed customers to work asynchronously without risk.
My Role
I led Drafts end-to-end, from defining the problem and reshaping the brief process to hands-on interaction design. My role spanned design, research, facilitation, and cross-functional leadership, partnering with a PM on ticketing and testing with engineering.
This project required being willing to work in a much more flexible way: shorter briefs left questions unanswered, smaller releases amplified uncertainty, and success depended on resisting over-specification.
I acted as the connective layer between product, design and engineering disciplines, translating customer needs into design intent, surfacing tradeoffs early, and guiding confident decisions. The goal was not just to ship Drafts, but to show that strong outcomes were possible without lengthy processes or over-engineering.
Designing the Brief
The first step was to simplify our brief process, which had grown overly complex and time-consuming.
As we moved toward smaller, faster releases, we needed a different kind of brief. The purpose was no longer to define an entire solution, but to help the team decide whether a problem was worth solving and whether it deserved our attention now.
As we moved toward smaller, faster releases, we needed a different kind of brief. The purpose was no longer to define an entire solution, but to help the team decide whether a problem was worth solving and whether it deserved our attention now.
I realigned the brief around four core questions.
What problem are we solving for real people?
Why should we do it now?
How much is it worth?
How does it align to our company strategy?
Why should we do it now?
How much is it worth?
How does it align to our company strategy?
Everything else was secondary. If information did not help answer one of those questions, it did not belong in the brief.
Each brief allowed for one of three outcomes: proceed, pause for later, or cancel. All were treated as positive results to create psychological safety. The option to “go learn more” and come back soon was eliminated. It was either important or not.
This approach created alignment early without constraining execution. Product, design, and engineering could agree on intent, urgency, and value, while still leaving room for teams to apply judgment later. The brief became a tool for decision-making, not a contract for implementation.
To prepare, I conducted targeted customer interviews with participants who had reported frustrations to our support team. This allowed us to surface the most painful points and estimate the potential ARR impact of solving them. A clear and painful customer problem emerged: they were forced to update courses outside working hours. This became our rallying cry.
Samantha should not have to
update courses at 3:00 am!
update courses at 3:00 am!
Shaping and Collaboration
After presenting to the product review team we would choose to move forward with the project. We scoped it for a six week engineering timeline, balancing ambition with feasibility.
With the project green lit, I led three shaping sessions with a small multidisciplinary group: myself, a PM, and three engineers. I prepared by creating a future state flow that illustrated some key areas for debate and drafting a working document where the team could comment and break down the workflow. This acted as a durable, digital whiteboard and a shared space for discussion.
A sample of the first flows to facilitate discussion. Comments were left open to capture what was discussed in the meeting. They would be used as a heat map to determine the areas that we needed to focus on.
The first meeting had the risk of only focusing on fears around timelines and scope. To mitigate this I did two things.
First, I started the meeting by saying. “There are a lot of reasons this is scary. It’s different than how we’ve worked. But for 90 minutes I want us to think about HOW we could do it. Not if we can do it. We’ll find initial gotchas, note them and move on. Let’s assume this will work and that we can do it.”
The second was to anchor our conversation to our rallying cry. “Samantha shouldn’t have to update courses at 3:00 AM.” This helped limit the scope of our conversation and problem space, and importantly keep it focused on the human beings we were building for.
The team agreed to those principles and we had a healthy discussion.
A sample of the notes that started emerging. These would get deeper as the sessions went on. Note that getting the UI right was not a priority here, getting ideas down was key.
The second session introduced higher-fidelity mockups. We refined priorities, explored technical feasibility, and identified potential risks, like analytics integration. We also made intentional decisions about what to defer, such as Live Events, which not all customers used and would have expanded scope unreasonably.
Examples of areas that we would defer or just not do. These were decided based on how close to the core problem they were and how much engineering effort they would be. We wanted to launch fast.
In the third session, we finalized scope and highlighted known risks, preparing for the build phase. The resulting document was not a PRD or technical spec. Instead, it outlined our intent, constraints, and areas requiring judgment, giving engineers a foundation while trusting them to solve implementation details.
These sessions created alignment on intent and reduced feature creep early. By the end of session three, engineering had clear direction while retaining ownership of implementation decisions.
New Design Patterns and Very Tight Scope
During shaping, a need for a new design pattern emerged: a sticky header for navigation and save functionality. Previously, users had to scroll to the bottom of long course pages to save changes. The sticky header solved this while supporting other interactions.
I kept mockups intentionally incomplete, often using bright colors to make them clearly temporary. This encouraged discussion and prevented the team from being “wowed” by a polished design too early.
Early versions of the sticky header can be seen above, as well as part of a debate around if the customer should default into draft mode or have to click a button to enter it. Comments from other contributors on where we had opportunities were tracked. Notes were written in a conversational style to keep collaboration going.
Balancing design ambition with engineering constraints was key. We wanted to meet our six week deadline without compromising product quality. I proposed that we leave the sticky header on the table during early shaping and sizing. If it proved too large or complex, we would revisit the pattern. In this case, it fit within scope and was included successfully.
Deferring perfect design until clarity was established allowed us to make thoughtful tradeoffs. It ensured the final implementation was both practical for engineering and meaningful for users, while avoiding unnecessary delays or over-engineering.
Ultimately we would choose to launch a version of Drafts without the sticky header to a limited number of customers, following up very quickly with the new pattern. This would allow us to solve the immediate customer pain quickly, and iterate into the design solution we wanted.
Clarity Leads to Craft
Once shaping and constraints were clear, it was time to focus on pixel-perfect UI work. Something simple that could handle the complexity beneath surface of Drafts was needed.
I was able to keep it on my desk because our design team was small. Being hands-on allowed me to fully control the craft and ensure alignment with the intended user experience.
The sticky header, once approved for development, went through several variations and design critiques to balance button fatigue and clarity of navigation.
Because the problem, technical constraints, and timeline were clearly defined, I could focus on the right interactions without wasting time on ideas that would be abandoned. Early experimentation had allowed the team to work quickly and make mistakes in low-stakes ways, so by this stage we could invest deliberate effort in details that really mattered.
This approach ensured that design decisions were grounded and deliberate. It also allowed me to mentor engineers, PMs, and other team members, showing that strong craft only works when aligned with clear purpose.
As a bonus, with the sticky header no longer a blocker for Drafts (at least the beta), we made a couple of additional improvements. We connected the course directly to its publication settings and analytics, which were historically scattered across the dashboard and required six to ten clicks to access. The sticky header brought these elements closer to the course, saving users real time. Customers LOVED this change.
Details around the hover tips and RBAC controls, which allowed us to expose powerful actions without increasing cognitive load or violating admin permissions.
Outcome and Impact
Drafts launched on time, within the allotted time. Beta feedback was immediately positive: users no longer felt constrained by off-hours updates, confirming we had solved the most meaningful pain point. Requests for features like versioning and scheduled publishing were seen as future opportunities, reinforcing the value of the new brief-to-shaping-to-build process.
This approach became the standard workflow across product and engineering, refined with each project and adapted for longer initiatives when needed. I was regularly asked to train other PMs and Designers on how to lead shaping sessions and refine briefs. Even two years later, the principles informed the Dashboard Homepage redesign.
Drafts stands as a concrete example that high-quality product outcomes are possible without long timelines, heavy process, or over-designed solutions.