Turning Cross-Device Complexity Into a Coherent Classroom Workflow

syGlass was expanding its scientific visualization platform into schools. A teacher would prepare a lesson on the web, launch it for students to experience in VR, and then students would return to the web to complete and submit their work.

But that classroom workflow had grown around the technology rather than around how teachers actually ran a class. Teachers were already reaching out to the team for help with lesson setup, launch, and troubleshooting.

With more schools coming on board before the new school year, that support model would not scale. I had about 2.5 months to redesign the teacher and student web experience so a class could move from preparation to submission with less technical help.

I combined teacher interviews, recurring support issues, a platform audit, and Jobs to Be Done with journey mapping to understand where the classroom workflow was breaking down.

To understand that structural problem from every side, I looked at the same classroom journey from four perspectives.

Looking across those perspectives, three problems consistently created the most friction and had the biggest impact on whether a class could run successfully.

With 2.5 months before the new school year, redesigning the entire product was not realistic.

The biggest classroom problems were not inside the core VR lesson. They happened around it: preparing a lesson, launching it, knowing whether it worked, recovering when it did not, and completing the work afterward.

I kept the core VR experience outside the redesign, limiting my VR scope primarily to teacher and student login.

I focused the rest of the work on the web platform surrounding the lesson, where we could reduce the most classroom and support friction within the time we had.

The first problem was structural: teachers thought in terms of a class, but the product was organized around separate capabilities.

I tested three ways to reorganize the platform against the classroom workflow.

I chose the classroom-centric view because it matched the unit teachers were already using to organize their work: the class itself.

Content-led made lectures easier to find but separated them from the students and assignments around them. Task-led made individual actions clearer but still required teachers to move between contexts. Classroom-centric kept the people, content, assignments, and activity for a class together.

Teachers were not separately managing content, students, and assignments. They were running a class.

From a classroom, a teacher could now manage students, prepare lessons, launch them, and follow up on assignments without rebuilding context across separate areas of the product.

Launch was the most fragile handoff in the workflow.

The teacher clicked Launch on the web, but the meaningful result happened somewhere else: inside the students’ headsets.

Teachers needed visibility into what happened after the click.

That led me to define launch as a set of system states the teacher could see.

I worked with engineering to define what the teacher needed to know as the lesson moved from ready, to launching, to available.

Making launch visible solved the successful path. The harder question was what happened when the system did not reach the expected state.

A teacher could have an entire room of students waiting while trying to understand why a lesson was not appearing in their headsets.

The teacher should not need to diagnose whether the problem came from the web platform, VR, or another technical layer.

So I designed recovery as part of the launch workflow itself.

The recovery experience needed to answer three questions:

The student side introduced a different constraint: schools often had fewer headsets than students.

A class might have 30 students but only 10–15 headsets, so completing an assignment could not depend entirely on VR.

After a VR activity, students could return to the web, reconnect with the same assignment, manually add evidence of their work, and submit it.

The goal was to make the transition out of VR feel like a continuation of the same assignment.

I brought IA and system models into feasibility reviews early, aligned web and VR behavior before detailed design, and reviewed builds weekly to catch workflow gaps during implementation.

The redesign shipped before the school year.

The larger change was structural.

Teachers had more control over the classroom experience without needing to understand the technical system behind it.

Students had a clearer path through the parts of the lesson that happened outside the headset.

And routine classroom problems were less likely to become engineering support problems.

The redesign solved the most urgent classroom workflows before the school year, but it also exposed opportunities for the next version.