Protea Suite

Before designing a single screen, we analysed the existing paper tests, mapping for each exercise the type of interaction and the data it produced. That mapping became the foundation of the whole system: the question types on Corolla, the matching screens on Seedling, the data structure in the reports.

Where to build Test Creation. A dedicated macOS app, or a feature inside Corolla? We chose integration: PMs already use Corolla as their operational hub, and a separate app would have fragmented their flow. Everything about the programmes had to live in one place.

Working without a network. Where there is no connection, an online test simply can't run. Instead of treating it as a limit to work around, we made it a design principle: an offline-first architecture. The test runs entirely on the device, results are saved locally and sync on their own when connectivity returns.

How Mac should a Mac app be? The macOS Human Interface Guidelines describe dense interfaces (sidebars, toolbars, multiple windows) built for power users. Ours weren't: PMs for whom the Mac is an occasional tool, not the environment they live in. The guidelines weren't wrong: they assumed a different user than ours. We kept platform consistency where it mattered and simplified where desktop conventions would have weighed on people with little familiarity: a more open, guided interface, built on a system of cards, one action at a time, a clear hierarchy. Following the guidelines without applying them blindly, reading them through the person who would actually use the product.

Inside each app, dozens of detailed choices. Two tell the story of how we worked better than the rest: one on Corolla, one on Seedling.

On Corolla: the structure of a question. Every question has three elements: an optional Paragraph (the shared context), the question, the answers. The Paragraph didn't exist in the initial design: it emerged from real use, when two PMs, translating their tests, found themselves rewriting the same introductory text for every question, or dropping it and losing the context. A structural gap visible only by putting the product in the hands of the people who use it, closed with a field that mirrors the paper format the PMs already knew.

On Seedling: setting up a whole class. On a test day, a teacher would have had to configure 20-30 shared iPads alone, an unmanageable bottleneck. We flipped the problem: the students do the setup, even the youngest, even those who have never touched a screen. But making it possible for a child who can't yet read required a system of orientation that didn't depend on text.

The answer is a system of redundant visual anchors: every selectable option is identified together by a label, a unique colour and an illustrated animal. The logic is cognitive, not graphic: the youngest programmes use primary colours a 5-year-old can already name (Numeracy = red), the older ones less immediate colours; and the animal adds a channel independent of colour, essential also in case of colour vision deficiencies. In class the teacher guides by voice ("select red", "select the zebra", or the programme's name) and each student completes the setup alone, whatever their reading level.

Twice we faced a design question that couldn't be solved on paper, nor simulated in Figma. In both cases I built the alternatives as working prototypes in Xcode, with AI assistance.

First case: Question Groups. The Paragraph had opened a structural question: how to group several questions that share the same text? Design A treated the group as a question type of its own, easier to spot, but conceptually wrong: a group is a relationship between questions, not a type. Design B kept each question single, with the option to add one linked to the Paragraph: correct, but with a nested logic, harder to discover. Tested remotely with the PMs: even with Design B they completed every action without getting stuck. With usability equal, conceptual correctness won.

Second case: Matching. A new question type for Seedling: connecting related items, a word to its definition, an image to its label. And an open question: drag, or tap in sequence? Drag and drop is direct and tactile; tap-to-select is simpler and, in theory, more accessible for children with little gesture experience. But the question wasn't how the interaction looks: it was how it feels, exactly where Figma is mute and a working prototype speaks.

We took them to Johannesburg, into the hands of 7-8 year olds: whole classes at Salvazione Christian School, groups of seven at Igugu Primary School in Soweto. At that age you can't ask whether an interaction is "intuitive": you can only observe where they hesitate, where they slip, when they get distracted, when they stay with the task.

The result was clear: drag and drop, the more demanding interaction in motor terms, turned out to be visibly more intuitive, fewer errors, more engagement, longer attention. Tap-to-select worked, but felt mechanical. Physical directness mattered more than structural simplicity. It became the matching interaction model, decided before writing a single line of production code.