SQOOL was UNOWHY's educational tablet ecosystem, deployed across 465 schools in Île-de-France and used by 500,000 students. By 2020, the suite included five distinct Android applications: a content platform, a messaging tool, a homework tracker, a parent communication app, and SQOOL Connect, which was the launcher that held everything together. Connect was also the oldest, the most cluttered, and the one with the least coherent product direction.
When I inherited it, the backlog read like a wishlist accumulated over years without a filtering principle. Dozens of features had been added in response to individual school requests, management initiatives, and technical constraints that no longer applied. The interface had grown to accommodate them all. Nobody had paused to ask whether the accumulated result still served a clear purpose.
Why redesign was the wrong starting point
The instinct in this situation is to redesign. The interface is messy, the user experience is poor, and design has the skills to produce something better. But redesign presupposes that you know what the product is for. You cannot design a better launcher if you do not have a clear answer to the question: launcher toward what, and for whom, and under what conditions.
Before touching a single screen, I spent several weeks mapping the teacher-student journey across all five SQOOL applications. Not the ideal journey, but the actual one: how students moved between apps during a typical school day, where transitions happened, where they failed, where students abandoned tasks because the handoff between applications was too disruptive.
The journey map revealed something that the product backlog had obscured. The biggest friction was not inside any individual application. It was in the transitions between them. Students lost context when switching apps. Teachers assigned work in one app that required students to navigate to another, with no guidance and no persistent thread connecting the experience. Connect was supposed to be the connective tissue, but it had never been designed with that goal in mind. It had been designed as a menu.
Building a demonstrator instead of a proposal
I did not take the journey map to the executive committee as a problem statement. A problem statement invites opinion. I took it as the basis for a working demonstrator: a clickable prototype that showed what a unified experience could look like if Connect was redesigned around the transition moments rather than around the feature inventory.
This was a deliberate choice. The demonstrator was not a promise. It was a thinking tool. It made the direction concrete enough to generate productive disagreement. When leadership saw it, the conversation moved from abstract questions about Connect's purpose to specific questions about the organization's actual priorities. Did UNOWHY want to compete on a unified platform experience, or on the quality of individual specialized tools? That was not a design question. It was a strategic question. But the demonstrator was what made it possible to ask it clearly.
The executive committee session generated more useful disagreement in ninety minutes than the Connect backlog had generated in two years. Different stakeholders had genuinely different mental models of what SQOOL was supposed to be, and the prototype made those differences visible in a way that slide decks had not.
What users actually said
Before any decision was made, I put the demonstrator in front of real users: students and teachers in three schools. The feedback was consistent and clarifying. Students did not want a more sophisticated launcher. They wanted fewer, more focused applications that did specific things reliably. The current suite was already more than they needed. A unified platform would give them more surface area to manage, not less.
Teachers had a different but compatible view. Their primary need was reliability. They planned lessons around tools that worked predictably. A unified experience was appealing in theory, but they were skeptical of a major change to something they had adapted to. What they asked for, consistently, was that the individual applications work better for their specific use cases.
These were not ambiguous signals. The research pointed clearly toward focused specialization, not unification.
The decision and its consequences
Connect was shelved. Rather than investing in a redesigned launcher, the team invested in the five focused applications, each oriented around a specific job to be done. Over the following two years, the suite reached 500,000 active users. The product that was abandoned was the one that had consumed the most design and engineering attention for the least measurable return.
The lesson I carry from this project is not that redesigns are bad or that unified experiences are misguided. It is that the question of purpose must be answered before the question of interface. Design can produce a coherent interface for almost any direction you give it. What design cannot do is substitute for a clear understanding of what direction is worth pursuing. The journey map and the demonstrator were useful not because they produced a beautiful solution, but because they structured the ambiguity in a way that made a real strategic decision possible.