C3 Education: Designing the user flow of an educational platform

Project Summary

C3 Education offers premium, bespoke tutoring services to K12 students across Australia. At the time of this project, they have 4 tutoring centers across Sydney, with the aim to expand to more tutoring centers across NSW and further to other Australian states.

As part of their offering, they wanted to launch an online learning platform, which would compliment their on-site learning to students, as well as offer the option to learn fully online.

What I did

• Use case mapping: mapped out all the different types of users that would use the platform, and their use cases (i.e. what tasks they do on the platform; what features they will need access to).
• Features mapping: I collaborated with the Whitehat Agency web project manager to map out all the features that will need to be built for the platform for an MVP launch.
• On-site research: I did some quick guerilla-type observational research on-site in one of C3 Education's tutoring centers, to understand the learning environment and what the student and teacher requirements are.
• Client interviews and workshops: I ran workshops and interviews with C3 Education's co-owners, to really map out project requirements, as well as provide updates throughout the project.
• User flows and wireframes: I designed extensive user flows through wireframe artefacts, to design how the platform would work for all the different types of users.
• Developer handover and component design: Throughout the project, I worked with our internal development team to do design handover of the use cases, features, and then the wireframes. I also designed some finalised components for developers to reference.

How can we design a platform for multiple tutoring centers?

I focused on requirements gathering by utilising past marketing and research engagements, as well as running requirements workshops with the clients.

Teachworks was the software being used for managing class schedules and student enrollment. However, this had the following issues:

• Did not have an intuitive user experience.
• Not scalable for multiple C3 tutoring locations.
• Student progress analytics was very rudimentary, and it was difficult for teaching staff to get an overall look at student progress.

I also spent some time on-site at one of C3's turoting centers, observing the learning environment, so that experience could be brought forward in the platform design:

• Very friendly learning environment
• Teachers really focus on individual student progress
• Teachers design learning plans according to individual student needs
• There's no cookie-cutter approach: everything is bespoke for the student's needs. This set apart C3 from the competition and was a major selling point.

Mapping platform requirements

I worked collaboratively with our project manager to map out all the important requirements, use cases and features of the new platform. The research I conducted was used to refine these through several iterations of requirement gathering.

Here are some examples of how these requirements and features were mapped in documentation.

The new education solution should be able to do as much of the following as possible:

• Scalable for multiple tutoring centre locations (with ability to manage various centres under one account by a super-admin user).
• Allow for teachers to design bespoke learning plans for each student.
• Book students into classes.
• Produce reports and analytics on student grades/progress.
• Student and parent logins, with separate dashboards for each type of user.
• Staff logins, with ability to see detailed progress reports for each student (for each class, or across classes).
• Timetables of various classes, sorted according to the tutoring centre location. Each class lists the students in the class, the teacher, and the classroom name/number.
• Staff can distribute notes to students for each lesson.
• Provide grades to the student for each lesson.
• A student can generate reports for themselves to see their progress in class.
• Sync with yet to be chosen CRM application.

Designing for multiple user types

I approached the user flow designs on the basis of each type of user. There were four main typs of users I identified:

• Student — an enrolled student
• Teacher — a teacher in either one or multiple campuses
• Campus admin — the main admin of a C3 campus who could view information across their assigned C3 campus location. They can manage teacher and student users on their campus.
• Super admin — the owners of C3 Education, who could view information across all campuses and manage all users.

I designed user flows for each of these user types by each individual use case. I used detailed wireframes to design the user flow, as I needed to:

1. Address the use case
2. Map the features and content for each use case
3. Use somewhat realistic data and content

Wireframes were the most useful type of tool for doing this quickly and efficiently.

You can view a sample of these wireframes in the zip folder below:

Results

• Each iteration of wireframes were completed and presented to clients for feedback and improvement.
• After wireframes were finalised, the use cases were updated with the references to relevant wireframes.
• I handed over the wireframes to the development team as documentation for the platform build.
• I also handed over a small design library, consisting of the most common components used throughout the platform, so that developers have a consistent guideline.

Reflections and lessons learned

• Requirements gathering and feature mapping included collaborating on very large documents, and around 14 (!) versions of these documents were produced throughout the length of this project. This got out of hand quite quickly, especially when the client had questions or clarifications. If I was to re-do this project, I would have utilised a project management tool like JIRA to map out all the use cases and features, and make changes to them.
• As a designer, I got too focused on screen-by-screen design. This has its benefits, as it gives an overall view of all the user tasks, and how the information layout works. However, next time I would try to approach a project like this with a component-based design, where essential components are standardised first before moving on. This would have made prototyping much more efficient in the long-term compared to screen-based designs.
• Next time I would have liked to focus on the interaction design of the components. While I was handing over wireframes and not final high-fidelity prototypes, I think a focus on some interactions would have been helpful for developers.