Designing how AI thinks, not just how it looks

Background

Getmee is an AI EdTech platform serving universities, employment services, and language schools across 15+ white-label apps. End users (students, job seekers, immigrants) use the mobile app for English learning and employability coaching, while teachers and coaches manage progress via the web platform.

When I joined Getmee, the 12-person development team was drowning in customer requests with no real prioritisation framework. Each new item was given the highest priority, and without any real processes across the product lifecycle, much of the work was fragmented and half complete.

Building the foundation

Features were being designed and built with AI tools, but without a shared design system. Each of these new features had to be white-labelled for every customer app which took weeks. This was taking crucial development time away from the product itself.

To tackle this, I built a lightweight design system with a focus on scaling across all of our different apps. I met with our customers to understand their needs, and to get any brand assets from them.

Many of our customers only had a couple of brand colours from their logos and no formal design guidelines. To solve this, I built an AI-assisted tool that would take those colours and generate a full set of WCAG AA compliant shades, giving every app a consistent and accessible palette.

The outcome of this system was that new white label apps now took only 2 hours to build, with most of that time going into testing. Alongside this, new features could now be automatically released immediately to all apps at the same time.

Building the systems behind the product:

• Moving the team to Notion broke down knowledge silos, giving the team a shared space to track work and document decisions, increasing knowledge share across the team.
• The Getmee Product Council ensured we were building the right things. This was a quarterly meeting with key customers used to (in)validate our roadmap and gather real feedback before committing to a build.
• Weekly product meetings and UX office hours gave the whole team a voice in the product, adding transparency to design decisions and engaging the team in the problems we looked to solve.

These processes ushered the team away from being reactive and created space to build new features that actually moved the product forward.

Tightening the product

With a solid foundation in place, I shifted focus to tightening the product itself, turning what was a broad set of isolated features into a cohesive experience.

I started by reducing friction. Passwordless registration replaced the confusing password flow, and I spent significant time fixing stability issues impacting all white-label apps. These weren't headline features, but they compounded into far fewer support requests and greater trust in the product.

The English Level Test was another critical upgrade. Previously it was just a standalone assessment that students took once and forgot about. This was a nice feature, but it could be expanded upon to address a real user problem: learners with lower English proficiency found the app frustrating because AI-generated content was using vocabulary way past their level.

With the help of the English teachers, I updated the Test, adding new question types, actionable feedback, and most importantly ensured that the assessed level now informed content difficulty across the app. It went from a standalone feature to the engine behind the user's learning experience.

I also built per-role navigation so students, teachers, and admins saw different experiences, and created Resources and Courses systems so that organisations could plug in their own training material. With 15+ white-label apps serving different contexts, this configurability was essential for our growth.

The AI English Tutor is an example of where this systems thinking came together most completely.

The problem teachers couldn't articulate

When speaking to our users, in this case, teachers, they often requested we add more and more task assignment features. This seemed like a straightforward request, and one that in the past would have been followed to a 't'.

When digging deep though, the real problem emerged: teachers didn't have time to create, assign and monitor tasks in the first place. Each new feature we built for them added to their workload. Learning new tools, monitoring student progress and keeping content up to date wasn't something that delighted them; it was a chore that took away from what they enjoyed.

Meanwhile, students using the app faced the other side of that problem; if teachers don't create, assign and monitor tasks, then students didn't know what to do. The app was full of valuable features (AI interview simulations, flashcards, pronunciation practice, soft skills training) but they existed in isolation. There was no clear path for how using these features would translate to improved English proficiency.

Identifying Opportunities

Following the user and customer conversations, I conducted competitor analysis using (and proofreading) AI, looking at 7 major language learning platforms to understand their offerings and identify what opportunities we might have over them.

The platforms I looked at did a good job of solving English learner engagement, but none of them were built with employment at the core. For our users (immigrants, students and job seekers), that's the end goal. The opportunity for us was to combine employability-focused features with personalised CEFR-aligned learning journeys that required zero teacher management.

This was further backed by a Harvard study done in 2024 which found that students learn more than twice as much in less time with an AI tutor compared to an active learning class, noting that they feel more engaged and motivated doing it.

This external validation coupled with our competitor analysis gave us enough confidence to move forward with a focus on personalised, AI-generated tasks.

Designing the system, not just the feature

My first version generated tasks one day at a time, in isolation. It worked in my own testing, but it broke down once I realised every learner's journey is different. A single daily guess couldn't build a coherent week or structure learning in a way that made sense at scale.

The change made was to plan the whole week up front, making sure that the entire context of the learner, the system, and the curriculum were properly considered. This taught me a core lesson of the project: AI can generate content, but it needs guardrails, put up by experts, to do so successfully.

Working with English teachers, I defined a near 50-page Curriculum Framework covering what learners can and can't do at each CEFR level, which task types suit each level, and what good looks like. I then worked with the development team to build a library of example tasks and specs for every task type. These would all serve as the reference that the agents would use to ensure personalised, proper learning tasks were being created.

The generation itself is split across three agents, so no single call has to do everything. A Curriculum Planner decides the week's focus and assembles a self-contained brief; the learner's context plus the task types and content relevant to them. A second agent, built again with teachers, generates the tasks using that brief as its guide along with seeing the user's previous tasks so as not to create duplicates. A third reviews every task against a defined rubric and the weekly brief, so only relevant, on-level tasks reach the user.

AI could still make mistakes though, so students needed the ability to flag tasks that they saw as poor quality. Flagged tasks were sent to our dashboard where we could see the entire task list and remove any tasks that had been flagged disproportionally to their usage.

For the student, the experience was simple. During onboarding, they could select their interests and take an English Level Test, this would then prompt the AI to generate relevant tasks for them.

The app's home page was restructured to show users their clear next action, reducing any ambiguity or decision fatigue for them. AI generated tasks, made up of all of the app's key features, unlocked each day, creating a mild sense of urgency for users. Each time a user completed a task they earned points, which added up to unlock English Level Tests that tracked their progress over time.

Teachers could view and adjust each student's level from the dashboard. They could also continue to create their own tasks with a refreshed UX. All person-generated content would be prioritised on the students' app, ensuring teacher content always took precedence over AI-generated content.

The real work in this project was in defining quality, building multi-level feedback loops, and restructuring the product experience so that everything, from onboarding to daily tasks to level progression, felt like a coherent journey rather than a collection of features.

I learned to design the behaviour of the AI, not just the UI around it.

Early Validation

While the full AI English Tutor pilot is scheduled post-departure, early indicators from internal testing and stakeholder feedback show strong promise. The system has successfully generated tasks across 6 CEFR levels and 30 interests, with a high AI QA pass rate.

This builds on proven product quality across pilots in multiple geographies:

The AI English Tutor is the strategic evolution of infrastructure that's already demonstrated impact across pilots with 1,100+ students in three countries.

All of the foundational work, product tightening, and AI English Tutor helped scale Getmee from 20,000 to 40,000 active users across 15+ white-label apps while significantly reducing support burden, increasing product trust and improving the team's release velocity.

What I learned about product leadership

• Designing AI behaviour, not just interfaces. As the UI is becoming an increasingly easier output for product teams, the systems behind them are where true designer value lies. I learned to write system prompts, design QA rubrics, and set confidence thresholds, making sure to serve real user needs.
• A product is only as good as the team building it. At Getmee, it was clear from the start that many processes didn't exist, and wouldn't unless someone took control. By setting up UX office hours, weekly leadership calls and by engaging with feedback, I helped the team to become more cohesive and engaged in the product.
• Saying no is a leadership skill. At Getmee, every feature request came with urgency attached. Learning to push back, to challenge the brief, question the assumption, and redirect the conversation toward the actual problem was one of the most valuable things I did for the team and the product roadmap. It ensured important work was prioritised, and led to impactful releases for users.
• In a distributed team, clarity is a design problem too. Working across time zones with varying communication preferences, I learned that how you communicate a decision is just as important as the decision itself. I defaulted to over-documenting by using Slack, Loom, and AI-assisted docs so the team always had the context they needed, in a format that worked for them.