Making complex curriculum simple to build.

A young LMS, outgrowing its first idea.

In 2015, Bridge was a young and raw newcomer to the corporate training scene.

Its MVP had a simple way to create courses and live training, plus a feeble attempt to chunk learning content into a bucket Bridge called a program. After interviews with existing and potential customers, we discovered real problems that needed to be addressed. I was tasked to lead this feature work alongside my product manager counterpart.

No flexible way to build — and no clarity for learners.

Authors and training managers needed a way to easily create a curriculum in the Bridge LMS. There wasn't a robust or flexible way to organize content and learning objects. Some existing problems with programs:

How might we help training managers and instructional designers create robust, flexible learning experiences — so employees gain the skills, knowledge, and confidence to grow in their careers?

Teamwork makes the dream work.

I knew that to succeed we'd need a process that let us deeply understand the user's needs, validate, and iterate. I collaborated closely with my product manager, Todd Erickson, and together we brainstormed and whiteboarded through several possible solutions.

To kick things off, the product and UX team gathered for an iterative design session. We laid out the core problems in the existing tool, then each designer sketched or wrote as many ideas as possible within a set time. Coming back together, we explored each concept one by one — finding connections and looking for ways they could solve the problem. We identified three main points of view.

Two experiences, one program.

From our early interviews and brainstorms, we knew what each side needed. I mapped user flows across multiple points of view to understand how everything worked together in the app.

Getting feedback early and often.

Bridge was highly collaborative. We held weekly design reviews with both the design and product teams, which gave us outside perspective — sometimes being on a project long enough starts to introduce bias. Meeting with customers really helped us simplify what we were creating.

I built a robust prototype in Sketch and InVision to test our designs with users. We got mixed reviews, but everyone agreed on one thing: it needed to be simpler. The feedback on the authoring side was that it was too complex — and we had customers threaten not to renew their contracts. So we went back to the drawing board.

Simpler — and it kept the customers.

After simplifying the authoring and learning experience quite a bit, we landed on a solution that resonated with our users.

In fact, we were able to design, prototype, and test with every customer at risk of not renewing that September — and made them happy enough that we retained 100% of our existing customers while picking up some new ones.

I believe a smooth handoff and tight collaboration with development is crucial to the success of every product. Knowing this was a very large feature, I wanted to be as prepared as possible. Once we had further validated the solution, I fleshed out every detail of the experience I could think of, reviewed the designs with our development team to get input on technical considerations, and put together a comprehensive set of specifications to accompany the mockups and clickable prototype. It's an approach I take regularly — it streamlines development and ensures a higher level of visual and interactive quality.

An immersive, dual-path experience.

The final design let the author create simple yet powerful learning paths, while the learner saw exactly what they needed to learn — and a path that would help them accomplish their goals.