All work
Case study · Instructure · Bridge

Keeping every at-risk customer by making programs simple.

Bridge customers were threatening not to renew because building a training program was rigid and confusing. I redesigned program authoring with my PM, tested it with every customer at risk that September, and every one of them renewed.

Role
Product DesignerLed design on the feature
Company
InstructureBridge, training software for companies
Team
Me and a senior PMPlus the Bridge design and product team
Timeline
2015A September renewal deadline
The short version30-second read
Business need
Bridge was a young product. Customers were threatening not to renew in September over how hard programs were to build.
Customer problem
Everything in a program was locked in strict order, authors couldn't organize it, and learners didn't know why they were taking it or what came next.
Behavior change
Trainers needed to build programs on their own, and employees needed to understand them and keep going.
Hypothesis
If authoring were simple and flexible, and learners could see the why and the next step, customers would keep using Bridge.
Solution
A quick outline, sections to organize content, steps that don't have to go in order, and a learner path that explains itself.
Outcome
We tested it with every at-risk customer before shipping. All of them renewed, and we picked up new customers too.
100%
of at-risk customers renewed
Every
at-risk customer tested the redesign before it shipped
2
sides of one product: authors and learners
1
round back to the drawing board when it was too complex
A Bridge program from the learner's side: a title, how long it takes, a short description, and numbered steps grouped into sections
The learner's view: what the program is, how long it takes, and what comes next.

Business need

Why Instructure cared.

In 2015, Bridge was a young product in corporate training. Its first version let companies build courses and live training, plus a simple bucket for grouping content that it called a program.

That bucket wasn't enough. Customers told us programs were too hard to build, and some threatened not to renew their contracts in September. For a young product, losing early customers would have hurt.

Customer problem

What was going wrong.

  • Everything was locked in order. Learners had to take every activity in strict sequence.
  • Authors had no way to organize or shape a program.
  • Learners had no context. They didn't know why they were taking a program, what was next, or what they needed to do.

Behavior change

What had to change.

Trainers and instructional designers needed to build programs on their own, shaped the way their teams actually learn. Employees needed to understand why a program mattered to them, so they'd start it and finish it.

Hypothesis

The bet.

If building a program felt simple and flexible, authors would build more of them. If learners could see the purpose and the next step, they'd keep going. And if both happened, customers would see Bridge working and renew.

We designed for three people: the learning admin building programs around business goals, the employee deciding if a program is worth their time, and the new hire who needs guidance from managers and peers.

Solution

What I designed.

01

Start from an outline.

An empty program invites you to add courses right away. Authors build a quick outline, add learning objects, and publish when it's ready.

02

Organize without rigid rules.

Authors break content into sections and modules, and choose whether learners take steps in order or in any order.

03

Show learners the why and the next step.

Each program opens with what it's about and how long it takes. Steps show progress, and My Learning lists what's overdue and what's up next, so training is easy to pick up and put down around a real job.

An empty program in Bridge with an arrow pointing to the button for adding courses
An empty program points you straight to adding courses.
An author adding a course to a program, with tools for courses, sections, and live training
Adding courses, sections, and live training to a program.
My Learning page listing overdue programs and what's next, with progress for each
My Learning: what's overdue, and what's up next.

I worked closely with Todd Erickson, our senior product manager. We started with a team design session: we laid out the problems, everyone sketched ideas against a timer, and we looked for connections between them. Weekly design reviews kept us honest when we got too close to the work.

Outcome

What happened.

My first prototype got mixed reviews. Everyone agreed on one thing: it needed to be simpler. Authors found it too complex, and some customers still threatened not to renew. So we went back to the drawing board and cut it down.

The simpler version landed. We designed, prototyped, and tested it with every customer at risk of not renewing that September. All of them renewed, and we picked up new customers along the way.

Measurement

How I'd measure it.

Renewals told us we'd fixed the urgent problem. These numbers would show whether authors and learners kept getting value.

What to trackResultWhy it matters
At-risk customers who renewed
100%
The business result, and the reason the work was urgent.
Time to build a program
Next to add
The pain authors felt most. If it drops, authoring is really simpler.
Programs published per customer
Next to add
Customers who build more programs are getting more from Bridge, and are more likely to renew next year.
Learners who finish a program
Next to add
Shows whether giving learners context actually keeps them going.

Looking back

What I took from it.

Test with the people who might leave

Putting the redesign in front of every at-risk customer turned a threat into a design partnership. They told us what to cut.

Simpler beat more powerful

My first version did more. The one that kept customers did less, and did it clearly.

More work

The next Bridge product, built in a month for the CEO, and onboarding farmworkers 60% faster at Sendola.