Education Workflow Redesign

I approached this as a multi-sided workflow problem, not only as a teacher-facing UI issue. Teachers needed faster orientation, clearer task progress, and less cognitive load in the reading process. The product team needed a structure that was easier to evolve. Engineering and QA needed a more reusable and stable interface logic so every change would not trigger repeated handoff and implementation friction.

To make the redesign meaningful, I first diagnosed where the product was actually failing. I reviewed the end-to-end task structure, checked where users lost context, mapped which navigation layers were overloaded, and identified where the interface and production model were creating repeat work. That let me define the project as a workflow redesign, an information-architecture redesign, and a delivery-efficiency redesign at the same time.

When I took over the project, the system already had the functions it needed on paper, but the actual workflow felt confusing and heavy. Teachers struggled to find the right entry points, the reading process was difficult to follow, and the system often failed to show users where they were or what they had completed.

The problem was not only on the user side. The interface style was inconsistent, interaction patterns were not unified, and the design approach was not componentised, which meant later development changes were also costly and inefficient. I therefore defined the work as both a usability redesign and a structural redesign for delivery.

I became involved at the point where the product clearly needed more than UI cleanup. The workflow had already become difficult for users to follow, and the lack of componentisation meant changes were expensive for the team to maintain. What made this work important was not only that the system needed improvement, but that someone had to reframe the problem clearly enough for the organisation to act on it.

My contribution was to take that vague sense of “this system feels difficult” and turn it into a more actionable diagnosis: overloaded navigation, weak state feedback, inconsistent patterns, and a design-production model that was increasing downstream cost.

One of the clearest structural changes was reducing the top-level menu from 15 first-level menus to 7. This was not only a simplification exercise. It was a way to reorganise the product around what users were actually trying to do rather than how the old system had accumulated features.

I also added a left-side navigation structure to solve the long-page problem and make it easier for users to see charts and related data tables within one screen. In practice, the new grouping moved the structure closer to real teacher tasks instead of scattered feature accumulation, so the interface offered fewer but more useful choices and made the workflow easier to scan and complete.

I unified the color system. Before the redesign, one website used six different shades of green. After the redesign, the system used one clear main color.

I also unified component style. Before the redesign, component styles were inconsistent and their application scenarios were not clear enough. After the redesign, the style was unified into three clear scenarios: selected, unselected, and mouse-hover states.

In page structure, I unified the page style and layout, moving from inconsistent left-right and top-bottom patterns toward a more consistent layout system. I also standardised the use of cards as the modular unit of page division.

To maintain continuity of visual consistency, I worked through font, layout, color, and icon systems, and used those standards to guide repeated page design.

I then shifted the team toward a componentized production process. The traditional page-production process relied on repetitive business page design, repeated low-efficiency communication, and difficult handoff restoration. The componentized process made scenario-based product requirements and modular visual expression easier to scale.

The collaboration impact became visible once the team no longer had to redesign or reinterpret every page from scratch. PMs could align around reusable patterns, developers had clearer restoration targets, and QA no longer had to evaluate every new page as if it were a different design language. That is where the component strategy started to pay off as a team workflow improvement, not only as a design-system decision.

In the traditional page-production process, repetitive business page design created repeated low-efficiency communication and difficult restoration in development handoff.

In the componentized page-production process, product requirements were handled in scenario-based form and visual expression became modular. Existing components could be selected after communication, while new components were created only when necessary to support new pages.

The redesign also included unified page style and layout rules. Before the redesign, page structures were inconsistent. After the redesign, the system moved toward more consistent layout logic and card-based modular division.

I also used the visual specification to keep continuity across fonts, layout, color, and icons, so later screens and modules could remain consistent instead of drifting apart.

I treated this redesign as a workflow and product-operations problem rather than as a UI clean-up task.

I used workflow audit and problem diagnosis to identify where users were losing orientation, where the information hierarchy was overloaded, and where the interaction model was increasing cognitive effort.

I used information-architecture restructuring to reduce structural noise and make teacher tasks easier to discover, scan, and complete.

I used componentisation as a product strategy, because consistent modules improve both user learning and internal delivery efficiency.

I measured the redesign not only by interface clarity, but also by whether the team could design, build, test, and evolve the system with less friction afterward.

This project taught me that redesigning a workflow is not the same as cleaning up screens. One early risk in work like this is improving visual consistency without solving the deeper navigation and handoff problems that are making the product hard to use and hard to evolve.

I learned to be more explicit about diagnosis before solutioning: what is actually broken for users, what is creating maintenance drag for teams, and which structural problems have to be solved before interface polish becomes meaningful.

That lesson still shapes how I work now. In complex products, the real design work often starts one layer below the screens, in workflow structure, reusable patterns, and delivery logic.