Adiy Bin Yunus — Product Designer

myGIIS — Building a Learning Platform from the Ground Up

GIIS had 21,000 students across six countries and a learning platform that had become a ceiling, not a foundation. We were hired to build what they couldn't buy.

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

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 role lead

My role

From contributor to track lead

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. Stakeholders wanted everything shipped at once.

The risk was real: building a feature-rich platform before any user had touched 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. Stakeholders wanted everything shipped at once.

The risk was real: building a feature-rich platform before any user had touched it.

Aligning with the design lead to push back on scope

I worked closely with the design lead to align on a shared position before taking it to stakeholders. The pressure to ship everything came from genuine ambition, but it carried serious product risk.

Together, we made the case for a scoped Phase 1: course access, assignments, scheduling, and progress visibility. Phase 2 would layer in intelligence and personalisation. The design lead brought seniority to the stakeholder conversation; I brought the student-side view of what was essential from day one.

A new platform succeeds by earning trust first, not by shipping every feature at once. If students and teachers couldn't submit an assignment without friction, adding AI on top would only amplify the confusion.

The ongoing work was helping stakeholders separate essential from aspirational, and reframing phasing not as delivering less, but as delivering a more reliable foundation for everything else.

Key design decisions

What we built and why

Key design decisions

What we built and why

Designing the teacher course module

The course module was the operational heart of the platform for teachers. By the time a teacher accesses it, the course is already created. Their job is to manage everything inside it: lesson plans, assignments, attendance, schedules, and course activity.

The design challenge was information density. Teachers needed to see a lot at once without feeling overwhelmed. The module had to surface the right information at the right moment, whether a teacher was preparing for class, reviewing submissions, or tracking who was falling behind.

Interviews and user story reviews with GIIS stakeholders helped us map how teachers actually moved through their day, and what needed to sit at the surface versus deeper in the hierarchy.

Aligning teacher and student experiences

A less visible but critical part of my work was staying in sync with the designers on the student track. The two couldn't be designed in isolation. An assignment a teacher creates has to appear correctly for a student. A lesson plan has to map to what a student sees.

This meant regular cross-track alignment sessions, and a willingness to revisit teacher-side decisions when the student track surfaced a better pattern.

The mobile-first pivot for parents

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, we 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.

Mobile-first for parents meant accepting some feature parity gaps with other roles. But designing for how people actually behave, rather than how a system assumes they will, is usually the right call.

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

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

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