The law changed. The market leader had to move.
Escola da Inteligência sells socio-emotional teaching methodologies to schools working with kids and teenagers. In 2021, that discipline became mandatory in Brazil's school curriculum — and as the major player in the niche, the company suddenly had both an obligation and an opening.
The CEO's call: build a platform for remote schooling that could deliver the company's rich content, track its use, and evaluate metrics. Not a generic tool — an LMS encompassing the specific features demanded by law.
The hard part was not any single feature. It was scope: a huge feature list, legal requirements, a database still to be structured, a third-party company writing the code — and one designer.
Don't start the research. Plug into it.
A project earlier — the Cidade da Memória game, for the same client — I had built an atomic research structure: a system designed to sustain every future need for end-user input, not just that game's. The LMS targeted the same personas.
So the defining decision was to reuse that ecosystem, connecting several existing research outputs instead of commissioning new studies. Delivery speed came from work that had already been paid for once.
The second decision followed the same logic, pointed forward: everything I made for the LMS — object maps, components, schema models — was written down as rules others could build on, so the platform would not depend on me the way the research no longer depended on a new study.
The whole platform, designed solo — possible only because the reusable structures already existed.
Objects, rules, and the seat nobody else was in
-
Scope, then proof of value
The team drafted a huge scope of features, listed them, and mapped processes and user flows. Before anything was designed, each feature's business value was validated with the CEO — the scope earned its place instead of assuming it.
-
Objects before screens
Using Object-Oriented UX, I mapped the system's objects first. That map was not a UX nicety — it was essential to creating the database structure itself. The same definitions that organized the interface organized the tables.
-
A design system that teaches
While building the design system, I documented each component with a clear set of rules and heuristics — so developers and designers could create their own components without me. Alongside, schema models showed developers how to structure tables and front-end displays.
-
Solo first version, committee-tested
I designed the first version alone, then validated the structure and front-end components with the IT team and a stakeholder committee. One author kept the system coherent; the committee kept it honest.
-
Taking the manager's seat
Delivery ran through a third-party coding company, so I assumed the manager role — team, project, and product — tracking deliverables and iterating the roadmap. When the beta launched with the back office not yet built to spec, I built the stopgap myself: an online course teaching sales representatives to support schools, teachers, and students — slides, a recorded class, an FAQ, and frequent seminars.
