HiteVision Pie Product Line

Around 2010, competitors began catching up rapidly. While HiteVision still had scale and market presence, competing products were moving faster with more experience-first product thinking.

Under that pressure, the Pie product line was revised and restructured. My task was not just to polish screens, but to help diagnose why the product line was underperforming in actual use and where interaction changes could improve classroom adoption.

Team structure for Whiteboard 8.0: 30 R&D, 1 visual designer, 6 PMs, 4 QA, and me as UX.

I participated in demand discussions, brainstorming, and function screening; helped prioritize functions; created interaction prototypes and functional logic rules; conveyed functional design intent to UI designers; worked closely with R&D to refine implementation details; synchronized design revisions in real time to balance schedule and quality; supported testing with test cases in the agile process; and collaborated with product teams to collect and analyze feedback and guide rapid iteration.

I worked from stakeholder maps, user behavior analysis, questionnaires, and scenario analysis to understand both the teaching environment and actual classroom operations. The most important part of this work was going back to real teaching contexts instead of treating all teachers as one user group.

What I found was that the issue was not only feature richness. Younger teachers and teachers in more developed regions were much more willing to explore interactive tools, while many teachers in less developed areas treated the large screen more like a projection surface. The same product therefore had very different levels of feature delivery depending on the teaching context.

The most important research move in this project was refusing to flatten all teachers into one user type. In practice, classroom behaviour differed significantly across teaching style, digital confidence, school conditions, and regional context. That meant the same feature set could look powerful in a demo and still underperform in daily teaching.

In more developed teaching environments, some teachers were willing to explore interactive activities, annotation tools, and richer classroom controls. In less developed environments, many teachers used the large screen more like a projection surface and stayed close to low-risk, familiar actions. This difference changed how I thought about interaction cost, gesture discoverability, and what “feature delivery” really meant.

Rather than asking only what new functions to add, I asked which existing capabilities were failing to cross the usability threshold in real classrooms. That framing led to more grounded decisions about simplification, gesture logic, classroom entry points, and multi-screen interaction support.

Based on research and analysis, I planned the paths of information interaction for the basic behaviors of lesson preparation and teaching.

In lesson preparation, the redesign covered the file menu, toolbar, interface behavior, QR-code sharing of courseware, convenient access to cloud files, editing and insertion of classroom interactive questions, subject tools, property panel linkage, auxiliary-line adsorption, insertion of teaching resources, and usage specifications for elements.

At the low-level module layer, I also defined gesture operations in detail, defined touch-feedback behavior, proposed solutions for resolution adaptation and object adaptation, and sorted out data instrumentation points.

These research findings directly changed the interaction rules I defined. For example, gesture behaviour had to become more predictable and easier to discover, because teachers under classroom pressure would not tolerate ambiguous touch feedback or multi-step tool logic. I also treated cross-screen and mobile-linked actions as a way to reduce podium-bound teaching behaviour and make interactive control feel more natural in the flow of a real lesson.

The multi-screen interactive mode of "entering the students and interacting in the classroom" was designed to let teachers leave the podium and move into the classroom while still controlling the large screen.

I officially took over this product in December 2017, and it was launched in March. Internal evaluation users included Gaosi Education and internal lecturers. In a questionnaire survey, 100% of the 75 teachers surveyed expressed a strong willingness to use the revised software again.

Team structure for Multi-screen Interaction 2.0: 10 R&D, 1 visual designer, 2 PMs, 2 QA, and me as UX.

There were 28 internal versions and 5 major design iterations. I followed up on testing with each release, raised user-experience questions continuously, participated in demand discussions and prioritization, created prototypes and logic rules, aligned with UI and R&D, supported testing, and collaborated with product teams on experience feedback and rapid iteration.

These design cases mattered because they reduced the interaction threshold in live teaching. In the revised multi-screen interaction product, 100% of the 75 teachers surveyed said they were willing to keep using the software, which was a strong signal that the new flow felt usable enough to stay in the classroom rather than being tried once and abandoned.

I treated this product line as a real behavioural adoption problem rather than as a feature-expansion exercise.

I used stakeholder maps, questionnaires, user-behaviour analysis, and classroom scenario research to understand how teaching contexts changed what users could actually adopt.

I used behavioural segmentation to avoid designing only for the most advanced teachers, because product value depended on whether more ordinary classroom users could cross the interaction threshold.

I connected research findings to interaction modelling, gesture rules, and feature-entry simplification so important capabilities could be used more naturally in live teaching situations.

I also linked interface work to instrumentation thinking, because understanding hot and cold features was necessary for improving later adoption and product evolution.

This project taught me that feature richness can hide delivery failure. A product can look powerful on paper and still fail in the classroom if the interaction cost is too high for real teachers under real teaching pressure.

I learned to ask a better question: not “what else should we add?” but “why are valuable capabilities failing to cross the usability threshold for so many users?” That shift made me pay more attention to adoption, segmentation, discoverability, and behaviour in context.

It also made me more careful about designing for ordinary users, not only advanced users. Strong UX work is not just about making experts faster. It is about helping more people actually use the product well.

These public links show the company context and the download pages for the product lines I worked on.