Some of the work I’m most proud of at Springboard never became a feature.
As we started building new courses and moving more of the student experience into the Canvas LMS, there were a lot of moving pieces. Product had requirements, Learning Experience was building course content, Program teams were figuring out operations and support, and Engineering had platform dependencies.
Each team knew their area well, but we needed a way to see how everything connected from the student’s point of view.
So I started creating student journey maps that brought those pieces together.
I usually start by gathering whatever we already had: user research, existing workflows, program requirements, timelines, and any other related documentation from different teams.
From there, I mapped the experience at a high-level view that showed important touchpoints and transitions without trying to document every detail. Tons of questions came up once we could see the experience laid out in one place.
When does the student get access into Canvas? What happens between enrollment and their first day? Who owns this communication? What does the student see while they’re waiting? What happens if something goes wrong?
I mapped more than product interactions, including communications, course milestones, platform changes, support, and other parts of the student experience.
As I worked on more of these, the process became increasingly collaborative!
I brought x-functional partners together to walk through the journey chronologically. People could fill in details from their area, raise a dependency, or point out a step that was still unclear.
For our first medical course with Allied Health, I worked with team leads to fill gaps in the onboarding experience from application through the beginning of the course. From there I started a regular cadence for updating the journey as dates and program decisions changed.
For a university partner (U of A), we already knew this user base pretty well, but the platform and experience would be different than our native one. So we used the journey during x-functional workshops with workstream leads to walk through what students would experience during and after onboarding.
The map gave us a common place to have these conversations.
Journey reviews helped surface unclear ownership, missing touchpoints, dependencies, and questions that needed to be resolved before launch.
Over time, I created and contributed to journeys across several new courses and student experiences.
They helped teams align on onboarding flows, platform access, homepage content, Week 0 tasks, student communications, support, and handoffs between teams.
The process became more structured as we used it across projects. I would gather what we knew, build or update the journey, bring workstream leads together to review it, incorporate feedback, and keep the map current as the course developed.
Eventually, this approach became part of how we worked through new courses. Design now had a seat at the table.
The process evolved as I used it across different courses and worked with more x-functional teams.
I realllyyy enjoyed making journey maps during my time at Springboard. ( ꈍ◡ꈍ)
More importantly, I learned how to decide what information actually belonged where. Too much detail made them difficult to use. Too little made it hard to spot gaps. Finding that middle ground made the journeys useful for both planning and conversation.
I also became much more comfortable facilitating discussions across teams. Everyone came into these projects with a different POV of the student experience, and part of my role was connecting those perspectives into something we could all understand and work from.
Sometimes that meant asking a very basic question that uncovered a much bigger gap. Other times it meant updating a tiny box on a very large FigJam board after a 30-min conversation.
Either way, I liked this kind of work.
It gave me a chance to zoom out, understand how the pieces connected, and help a group of people build a clearer picture of what we were asking students to experience.
