Summary
Over the course of 10 months, a small team of myself, another product designer, one director of PM, and a group of engineers, built a 0 to 1 Training & Coaching platform. Our goal was to prepare customer-facing teams for success with learning that sales reps love. The product we built included creating high-impact training materials natively and increased knowledge retention by engaging reps in training with video practice pitches. I was involved in the IA, UX, UI, and research portions of the project, including defining the quality bar for our GA release. 1.5 years following the release to GA, the Training and Coaching product contributed to 20%+ of Highspot’s revenue.
02. The Goal
Create a training and coaching product that would allow sales reps to train within the tool they already used, increasing their effectiveness in closing deals.
The problem: Sales content, the core of Highspot’s product, was only the starting point. For sales teams to be successful, they needed to be able to onboard quickly, decrease ramp time, and achieve higher quota attainment through training. Adoption with other Learning Management Systems (LMS) is traditionally poor because it’s another product that sales reps have to use. What we needed to do was build an integrated LMS on top of our sales CMS platform.
The team: Product Design Director – player/coach role (me!), 2 Product Designers, 2 Product Managers, Technical Project Manager, 2 Eng Architects, 5 Front End Eng, 2 Back End Eng, 2 QA
The tools I used: Sketch, Invision, Google Docs, Google Sheets
03. Discovery
I missed most of the discovery phase. I had been on leave while it was conducted over 5-6 months. My manager pulled me in to help with the project which was “totally off the rails.” As soon as I came in, there was intense pressure from the business to deliver – we were told that we needed to deliver the entire product in 4-5 months. Unfortunately (or fortunately), we didn’t have the resourcing that would support that request, so we reset expectations, took stock of where we were, and estimated how long it would take us to finish, and we agreed on a late-Fall release date.
I had a month of overlap with the designer that had been working on the discovery while I was on leave. There was not much (or anything) documented from their research process (which was obviously less than ideal) so she had to walk me through their progress, thought process, and conceptual designs that had been produced from it. One thing was clear: for the Training and Coaching product to be successful, we had to lean into the fact that it was built on top of a CMS. It led to more complexities than a stand-alone LMS (particularly when it came to permissions) but it would set us apart as a superior option for sales teams’ success and be more likely to be adopted by our users.
04. The Planning
There was a monumental amount of work to get done in a short amount of time. I knew as the Design Lead that detailing it all out was critical to our planning process.
05. The Process
Essentially, we were starting from scratch. And we were on a tight timeline. Engineers were sitting around with nothing to do. The process – in all honestly – was tense, messy, and often frustrating. I learned a lot of lessons from it. We had to focus on the big picture – the architecture of how the product would fit into the existing CMS base, and how it would make sense within the existing paradigms – and the details. In those early days, there were many brainstorming and discussion meetings involving myself, my designer, the director of PM, and at least one if not two high-level engineering architects.
One of the most critical of those discussions was about how we were going to structure the training materials. We already knew that we wanted courses and lessons. Lessons would be built in our native content-creating tool, Smartpages. The power of Smartpages was that our users could create native content that pointed to content that existed within Highspot’s CMS – allowing the content to always stay up to date while designing lessons that built context around content. We had to make adjustments to Smartpages, including the new page type “lesson,” a new question block, and allowing content in a lesson to be marked as “required” to complete the lesson. The model at that point was close to the analogy of typical educational materials – the course equaling a textbook – Sales 101 – while the lessons were individual chapters or assignments from the textbook. Our PM was pretty focused on the idea of sessions – that you could have a single course English 101 – with multiple sessions to enroll in – Fall 2020, Spring 2020, etc. His thought was that by structuring things that way, it allowed the course to stay “evergreen” – unchanging – but have different cohorts of learners to come through and keep track of. Unfortunately, this added a lot of complexity to the model – needing to keep a historical record of each cohort, and keeping track of which version that cohort took if the course or lesson had been updated since the cohort had completed it. After various discussions, we convinced the team that sessions were not necessary – if our users wanted to track cohorts, they could create multiple courses and enroll groups that way.
One thing we noticed in design was that lessons could be long. That meant a long page with a lot of information and scrolling. It was easy to get overwhelmed and discouraged when trying to complete a course that involved multiple long lessons. Therefore, in order to have a better, more inviting experience, design pushed to have lessons broken into “bite-size pieces.” This would be less intimidating for learners and allow them to see their progress through the lesson in a way that would incentivize them to complete it. We had to find a mechanism to make this happen – so we devised “sections” in lessons – they acted like page breaks so that only small sections of the lessons were displayed at a time. Luckily one of the engineering architects was so excited by this idea, he built it over the weekend, and with that addition, we were able to hit our alpha release and start getting feedback from customers!
Long lessons were overwhelming for users to consume but convenient for lesson creators that didn’t need to create multiple materials for a single lesson.
We broke down lessons into individual sections or modules to make the experience less daunting for learners, but still allowed lesson creators the convenience and efficiency of creating one lesson covering multiple topics.
There was one more main piece that was not a great experience. The sense of place. We had adopted a “Russian nesting doll” structure to training materials – a course contained a lesson that contained required content and questions (within sections). Because of our full-screen experience, it was hard to know where you were. In order to tackle that problem, we made the table of contents for lessons more clear, added “wayfinding” text to our lesson information bar, added section labels to the lesson header, and clarified the back button. Not only did we add text to the back arrow that helped users understand where they would go when they clicked on it (“back to lesson,” “go to course”) but we also messed with the back stack. Instead of having the back button map 1:1 with the browser back, we wanted to highlight the “Russian nesting doll” layers by matching the back stack to it. So if you were in a piece of required content, hitting back would take you back to the lesson. If you were in a lesson, hitting back would not remember the sections but instead, take you back to the course. This concluded the last large architecture decision for the product.
At this point, we had two months before we were planning on going to GA. That meant that design, having already produced high-fidelity designs, needed to be engaged in fit and finish testing. We started testing and logging bugs, putting the bugs we found in a large spreadsheet. This allowed us to have a conversation with the team about which bugs should be worked on in which priority, which bugs were required for GA, which bugs needed a discussion from the group before moving forward, and the status of each bug. Some issues we found didn’t have a design and required work from us. There ended up being 231 bugs! Our engineering team worked hard to complete the bugs required for GA. Unfortunately, we didn’t quite make it, which meant we had to push out the GA release for another month. Quality is critical to get right – you only get one chance to make a good first impression!
06. The Product
At our GA release, we celebrated how far we had come over the course of 10 months. It was a lot of effort! Our final product achieved five key capabilities:
- Manage and Deliver Sales Training: Build Courses and Lessons with content your reps need to use in the field, without having to get it from another system
- Structure Practice and Scale Coaching: Provide reps with the opportunity to practice their pitches prior to the pressure of customer-facing scenarios
- Contextualize Learning and Engage Sellers: Put Lessons in context by embedding them in sales plays, or targeting opportunities in your CRM (Customer Relationship Management system)
- Analyze Training Performance: Track training progress at the rep, team, and organization level across your business
- Demonstrate Training Business Impact: Connect training results to business outcomes with Play Scorecards and deep CRM integrations
Learner Experience
Instructor Experience
07. Results & What’s Next
We had come a long way. We created experiences for two different personas – learners enrolling and taking training materials, and instructors that created and managed them. The product was built on top of Highspot’s core CMS product, which led to complexities around permissions and capabilities but was worth it as a competitive differentiator. After 1.5 years of our release to GA, the Training and Coaching product contributed to 20%+ of Highspot’s revenue. And our customers were engaged: 2 years after our launch, 63% of Training and Coaching licenses were engaged; >10% of licenses had enrolled in a course within the past 30 days.
There was more work to be done – but we had a foundation to build on. One of the first fast-follow features we added was the ability for learners to use the product on mobile devices. In the following months, we added the ability to import SCORM lessons (a common format for learning materials), added pass/fail statuses to courses, the ability to reset lessons that you didn’t pass, and added a new role – course managers – that could review submissions for their direct reports. This was a good baseline for the training product and we accomplished a lot through a messy process. I learned a lot about how to move fast by having a clear process. I also learned that it’s hard to move fast if everyone is not on the same page or doesn’t have the same vision to move toward. In the future, I would have insisted on more time and documentation in the discovery phase to help us have a clear picture of where we were headed – and why. Principles and success metrics should also have been created at the beginning rather than along the way. Creating the Training and Coaching product was a huge accomplishment – and it wasn’t easy!
