myGIIS — Building a Learning Platform from the Ground Up
5M+ users had access to a device management feature. Most weren't using it to manage their network — they were using it to check if someone had broken in. The interface gave them no help doing that.
Role:
UX design
Year:
2021/22
Context
Why GIIS needed to build their own platform
GIIS is a global school group with campuses across Singapore, India, Japan, Indonesia, and Malaysia, serving over 21,000 students. For years they had been using a white-labeled third-party LMS. But as the group grew and their vision for learning evolved, the vendor solution became a ceiling, not a foundation.
The core problem was strategic: GIIS wanted to build adaptive, AI-driven learning experiences tailored to their own pedagogical approach. The vendor platform could not support that direction. Rather than patching a solution that was never theirs to control, they decided to build a platform they could own, evolve, and scale across every campus.
The goal was not just a better LMS. It was a platform that could eventually embed their learning philosophy into every interaction, from how students access coursework to how teachers track progress.
Context
Why GIIS needed to build their own platform
GIIS is a global school group with campuses across Singapore, India, Japan, Indonesia, and Malaysia, serving over 21,000 students. For years they had been using a white-labeled third-party LMS. But as the group grew and their vision for learning evolved, the vendor solution became a ceiling, not a foundation.
The core problem was strategic: GIIS wanted to build adaptive, AI-driven learning experiences tailored to their own pedagogical approach. The vendor platform could not support that direction. Rather than patching a solution that was never theirs to control, they decided to build a platform they could own, evolve, and scale across every campus.
My role
From contributor to track lead
I joined as an Associate Senior Designer on a team of eight to ten people. I was responsible for the teacher experience, specifically the course management module: how teachers view and manage lesson plans, assignments, student attendance, class schedules, and course activity.
As the project progressed and the scope of the teacher track grew, I moved into a lead role, working alongside two junior designers who had recently joined the team. A key part of my work was also aligning the teacher experience with the designers working on the student side, making sure both experiences were coherent. What a teacher configured had to make sense to a student on the other end.
My role
From contributor to track lead
I joined as an Associate Senior Designer on a team of eight to ten people. I was responsible for the teacher experience, specifically the course management module: how teachers view and manage lesson plans, assignments, student attendance, class schedules, and course activity.
As the project progressed and the scope of the teacher track grew, I moved into a lead role, working alongside two junior designers who had recently joined the team. A key part of my work was also aligning the teacher experience with the designers working on the student side, making sure both experiences were coherent. What a teacher configured had to make sense to a student on the other end.
Complexity
Scope, ambition, and the risk of building too much
The client's ambitions were high. Twelve user roles. AI and adaptive learning on the roadmap. A global rollout across schools with different curricula and operational structures. Stakeholders who, understandably, wanted everything shipped at once.
This created a real risk: trying to build a feature-rich platform before any user had touched it. If the foundation wasn't right, no amount of features on top would save it.
Complexity
Scope, ambition, and the risk of building too much
The client's ambitions were high. Twelve user roles. AI and adaptive learning on the roadmap. A global rollout across schools with different curricula and operational structures. Stakeholders who, understandably, wanted everything shipped at once.
This created a real risk: trying to build a feature-rich platform before any user had touched it. If the foundation wasn't right, no amount of features on top would save it.
Aligning with the design lead to push back on scope
The push for prioritisation wasn't something I did alone. I worked closely with the design lead on the project to align on a shared position before taking it to stakeholders. We both recognised that the pressure to deliver everything in phase one was coming from a place of genuine ambition, but that it carried serious product risk. Together, we made the case for a deliberately scoped phase one focused on foundational flows: course access, assignments, scheduling, and progress visibility. Phase two would layer in intelligence and personalisation. The design lead brought credibility and seniority to the conversation with stakeholders, while I contributed the student-side perspective on what was actually essential for a student to trust and use the platform from day one.
A new platform succeeds by establishing trust first, not by being feature-rich immediately. If students and teachers couldn't find their courses or submit assignments without friction, adding AI on top would only amplify the confusion. We needed to earn the user's confidence before asking them to adopt anything complex.
This required ongoing conversations to help stakeholders separate what was essential from what was aspirational, and to reframe phasing not as delivering less, but as delivering a more reliable foundation for everything else they wanted.
Complexity
Aligning with the design lead to push back on scope
The push for prioritisation wasn't something I did alone. I worked closely with the design lead on the project to align on a shared position before taking it to stakeholders. We both recognised that the pressure to deliver everything in phase one was coming from a place of genuine ambition, but that it carried serious product risk. Together, we made the case for a deliberately scoped phase one focused on foundational flows: course access, assignments, scheduling, and progress visibility. Phase two would layer in intelligence and personalisation. The design lead brought credibility and seniority to the conversation with stakeholders, while I contributed the student-side perspective on what was actually essential for a student to trust and use the platform from day one.
Key design decisions
What we built and why
Key design decisions
What we built and why
Designing the teacher course module
The teacher course module was the operational heart of the platform for teachers. A course is already created by the time a teacher accesses it. Their job is to manage everything within it: lesson plans, assignments, student attendance, class schedules, and course activity across their students. The design challenge was information density. Teachers needed to see a lot at once without feeling overwhelmed. The course module had to surface the right information at the right moment, whether a teacher was preparing for an upcoming class, reviewing assignment submissions, or tracking which students were falling behind on attendance. We worked closely with GIIS stakeholders through interviews and user story reviews to understand how teachers actually moved through their day and what they needed to access quickly versus what could sit deeper in the hierarchy.
Designing the teacher course module
The teacher course module was the operational heart of the platform for teachers. A course is already created by the time a teacher accesses it. Their job is to manage everything within it: lesson plans, assignments, student attendance, class schedules, and course activity across their students. The design challenge was information density. Teachers needed to see a lot at once without feeling overwhelmed. The course module had to surface the right information at the right moment, whether a teacher was preparing for an upcoming class, reviewing assignment submissions, or tracking which students were falling behind on attendance. We worked closely with GIIS stakeholders through interviews and user story reviews to understand how teachers actually moved through their day and what they needed to access quickly versus what could sit deeper in the hierarchy.
Aligning teacher and student experiences
One of the less visible but important parts of my work was staying in sync with the designers working on the student experience. The two tracks couldn't be designed in isolation. An assignment a teacher creates has to appear correctly for a student. A lesson plan a teacher structures has to map to what a student sees in their course view. This required regular cross-track alignment sessions to make sure decisions on the teacher side didn't create confusion or inconsistency on the student side, and vice versa. It also meant being willing to revisit teacher-side decisions when the student track surfaced
Aligning teacher and student experiences
One of the less visible but important parts of my work was staying in sync with the designers working on the student experience. The two tracks couldn't be designed in isolation. An assignment a teacher creates has to appear correctly for a student. A lesson plan a teacher structures has to map to what a student sees in their course view. This required regular cross-track alignment sessions to make sure decisions on the teacher side didn't create confusion or inconsistency on the student side, and vice versa. It also meant being willing to revisit teacher-side decisions when the student track surfaced
The mobile-first pivot for parents
A separate but connected decision shaped how the broader platform was scoped. Stakeholder research revealed that parents were not using the existing LMS from a desktop. They were checking their child's progress on the go: between meetings, during commutes, in short windows throughout the day. Rather than designing parents into the desktop-first system and retrofitting mobile later, the team made a deliberate call. Parents would get a mobile-first experience scoped to what they actually needed: attendance, assignment status, and progress at a glance.
This was a trade-off. Mobile-first for parents meant accepting some feature parity gaps versus other roles. But designing for how people actually behave, rather than how a system assumes they will, is usually the right call.
A separate but connected decision shaped how the broader platform was scoped. Stakeholder research revealed that parents were not using the existing LMS from a desktop. They were checking their child's progress on the go: between meetings, during commutes, in short windows throughout the day. Rather than designing parents into the desktop-first system and retrofitting mobile later, the team made a deliberate call. Parents would get a mobile-first experience scoped to what they actually needed: attendance, assignment status, and progress at a glance.
What we built and why
Building a design system mid-flight
Halfway through the project, it became clear the team didn't have a shared foundation. Designs across modules were fragmenting. Junior designers didn't have consistent patterns to build from. Feedback loops were slow because every review involved relitigating basic decisions. The team made the call to build a design system in parallel with active design work, not as a separate initiative to tackle later, but as something built into the process of shipping. It meant going back and adapting earlier work to the emerging system, which felt inefficient in the moment. But it made the team faster and produced more coherent output as the project scaled.
Building a design system mid-flight
Halfway through the project, it became clear the team didn't have a shared foundation. Designs across modules were fragmenting. Junior designers didn't have consistent patterns to build from. Feedback loops were slow because every review involved relitigating basic decisions. The team made the call to build a design system in parallel with active design work, not as a separate initiative to tackle later, but as something built into the process of shipping. It meant going back and adapting earlier work to the emerging system, which felt inefficient in the moment. But it made the team faster and produced more coherent output as the project scaled.
Leading the team
Mentoring junior designers for the first time
Leading the teacher track also meant leading two junior designers who were early in their careers. I had to learn how to give feedback that guided rather than directed, asking questions about why a decision was made rather than just telling someone what to change.
Coming from a strategic design background, I was used to questioning requirements and challenging assumptions. But I realised that skill was only useful if I could transfer the thinking, not just apply it myself. That meant slowing down, explaining the reasoning behind decisions, and helping junior designers build the habit of questioning user stories rather than just executing them.
It was also the first time I had to adapt my working style to others, understanding how they processed feedback, where they needed more direction versus more space, and how to keep them oriented in a system as complex as this one.
Leading the team
Mentoring junior designers for the first time
Leading the teacher track also meant leading two junior designers who were early in their careers. I had to learn how to give feedback that guided rather than directed, asking questions about why a decision was made rather than just telling someone what to change.
Coming from a strategic design background, I was used to questioning requirements and challenging assumptions. But I realised that skill was only useful if I could transfer the thinking, not just apply it myself. That meant slowing down, explaining the reasoning behind decisions, and helping junior designers build the habit of questioning user stories rather than just executing them.
It was also the first time I had to adapt my working style to others, understanding how they processed feedback, where they needed more direction versus more space, and how to keep them oriented in a system as complex as this one.
Outcome
Where the project landed
Phase one reached development and internal QA testing before I transitioned out of the project. The platform shipped after I left. I don't have post-launch metrics, as the data came after my time at Lollypop Design Studio.
What I can speak to is the foundation: a scoped, coherent teacher experience for a platform serving 21,000 students across six countries, built in close alignment with other role tracks and delivered by a team that grew in capability over the course of the project.
Outcome
Where the project landed
Phase one reached development and internal QA testing before I transitioned out of the project. The platform shipped after I left. I don't have post-launch metrics, as the data came after my time at Lollypop Design Studio.
What I can speak to is the foundation: a scoped, coherent teacher experience for a platform serving 21,000 students across six countries, built in close alignment with other role tracks and delivered by a team that grew in capability over the course of the project.
Reflection
What I'd do differently
Looking back, I'd push harder for more structured usability testing with actual teachers earlier in the process. We relied heavily on stakeholder interviews and user stories, which gave us good requirements coverage but less visibility into how teachers would actually move through the course module under real conditions.
I'd also document design rationale more rigorously as the system grew. With a complex multi-role platform and a growing team, institutional knowledge fragmented quickly. Better documentation would have made onboarding junior designers faster and kept the team more aligned without constant verbal context-setting.
Reflection
What I'd do differently
Looking back, I'd push harder for more structured usability testing with actual teachers earlier in the process. We relied heavily on stakeholder interviews and user stories, which gave us good requirements coverage but less visibility into how teachers would actually move through the course module under real conditions.
I'd also document design rationale more rigorously as the system grew. With a complex multi-role platform and a growing team, institutional knowledge fragmented quickly. Better documentation would have made onboarding junior designers faster and kept the team more aligned without constant verbal context-setting.