Reducing teacher navigation overhead
through context-preserving UI

Simple tasks, complex paths.

The project started with a small observation.

While reading through teacher discussions about LMS platforms, I came across a teacher describing how they had multiple tabs open just to move between related tasks. They weren't struggling with the work itself. They were struggling with getting to it.

That made me wonder:

This is a concept project based on secondary research, including Reddit discussions, G2 reviews, and workflow patterns from products like Linear, Notion, VS Code, and Slack. I didn't interview teachers directly, so I approached this as a hypothesis rather than a validated problem.

PRODUCT	INTERACTION PATTERN & PRINCIPLE
Linear	Uses a command palette to help users navigate through intent rather than menus.
VS Code	Surfaces actions from a single entry point through shortcuts and search.
Notion	Uses overlays to help users access information without losing context.

Across all three products, I noticed a similar pattern: they reduce interruptions by making it easier to move between related pieces of work.

While teachers and software teams have very different jobs, the underlying challenge felt familiar. As workflows become more complex, finding information and switching between tasks starts taking effort of its own.

That made me curious whether a similar problem existed inside education platforms.

Workflow fragmentation.

I started the research expecting to find missing functionality.

Instead, I kept noticing a different pattern.

Teachers already had tools for grading, attendance, communication, and planning. The problem didn't seem to be the absence of workflows. It was moving between them.

Every switch came with a small cost. Not just the clicks required to get somewhere, but the effort of reorienting and picking the task back up again.

The more examples I reviewed, the more the problem started to look less like a navigation issue and more like a context issue.

That shifted the question for me.

If the friction comes from moving between workflows, how should the interface respond?

Two paths to efficiency.

Where I'd start.

I explored Direction 2 because it challenged the assumption I started with.

If navigation creates friction, why not remove navigation altogether?

The more I developed the concept, the more interesting it became. Instead of helping teachers move through workflows faster, it asked whether they should need to navigate those workflows at all.

At the same time, it introduced a question I couldn't answer through the research I had.

The concept depends on teachers trusting the system to surface the right work at the right time. If that trust exists, the experience could feel dramatically simpler. If it doesn't, the queue becomes something teachers need to monitor and verify.

That uncertainty is why I'd start with Direction 1.

Direction 1 solves a smaller problem, but it does so using patterns teachers already understand. It reduces the effort of finding and accessing information without changing how people work.

Preserving momentum.

I started this project thinking about navigation.

I ended it thinking about context.

The research pushed me away from questions like "How do we reduce clicks?" and toward questions like "How do we help people stay focused on the task they're already doing?"

That shift shaped both directions I explored.

Direction 1 focuses on reducing the effort of moving between workflows. Direction 2 questions whether users should need to move between them at all.

Exploring both helped me separate an interesting concept from a product recommendation.

The most ambitious idea isn't always the right place to start. Sometimes the better decision is the one you can support with more confidence.

The project also changed how I think about complex products. Users don't experience software as a collection of features. They experience it as part of an ongoing flow of work.