However, due to the structure of the event, we decided to work backwards from the theme and then pick the subcategory of students we were interested to solve problems for. The final verdict of brainstorming leaned towards making remote classes enjoyable, and reducing boredom by finding out ways to increase student-teacher engagement and student-student engagement in such settings.

‍

Our primary users consisted of students using the student-facing application, and corresponding teachers using the separate teacher-facing application. Initially, the team decided to go with kindergarten to 8th grade students through a close voting process, with the idea that it may pose more interesting challenges compared to mature students as the primary audience.

To simplify our prototype, we made 3 assumptions -:

• The student is able to understand and communicate in basic English
• The student owns a mobile and has some experience using mobile apps
• The teacher uses a desktop to conduct the teaching session

These points were critical drivers to our design because we were demonstrating a solution with English as the primary language(i.e. no localization or RTL language considerations were made for this prototype). Moreover, we discussed that most junior high school kids in today's generation either directly own or have access to their parent's mobile phone or iPad apps. This pushed us in the direction of creating a mobile-first application for the student-facing app. In contrast, by majority we agreed that teachers would use a desktop to host the session for convenience, and hence planned for a web application for teacher side application instead.

We discussed the requirements and had 1 notetaker to write down all the ideas we wanted to sketch.

We then made use of a quick wireframing session that helped us convey our ideas to the developers' team.

After our initial discussion with the developers, we decided to focus on the live classroom experience and therefore decided not to implement the secondary functionalities like the tasklists and workbooks. Moreover, for simplicity we sticked to 1 theme throughout the application.

Dusk had arrived and it became apparent that everything in the design was not implementable within the next day. We met with the developers' team to prioritize the functionalities. Being a developer myself, it was easy to calculate that implementing the trophy system and all the dinosaur animations we envisaged was far fetched. In a bias for action, we also cut down on the dashboard features to include only the classroom experience simulation with important details that would suffice for our concept.

Once the clouds were clear and group discussions on estimates were complete, we went ahead to design high-quality screens for the handoff. Though only some screens would be implemented in the code demo, the design team decided to polish as many screens as possible for the presentation.

I was responsible along with Maggie to create a common style guide for the entire product (both the student and teacher facing application). My personal approach was derived from simplicity, extendibility, branding and feasibility. To keep it easy to follow for other designers and developers, we decided to stick with only the essential components.

‍Typography

We chose a font which would fit well with both the teacher and student application. The considerations for this were being easily readable, and not being a formal font which would be different from the students' taste. We made sure to check the legibility on both mobile screens for the student and on desktop for the teacher and came up with these sizes.

Color Palette

‍

I picked the color palette for both the apps by starting out with bright colors and aiming for complementary shades. In the end, I settled with a blue primary theme for the teacher application to give it a professional appearance and picked fun colors for the students that would go well with the dinosaur theme.

Buttons

Spacing (common for padding and margins)

Spacing was tricky because the teacher-side app would potentially require big spacing values (like 144px and above), but we limited ourselves to presenting the demo on a 13" Macbook. Accordingly, we devised 6 spacing values by checking them against both mobile and desktop screens. Sticking to multiples of 8 pixels helped to avoid grid misalignment issues and 2px spacing value was used for adjustments.

The event did not run overnight but resumed from the next day. This meant I had time to delve into the technology being used.
Programming the User Interface

• The user interface for both the student mobile app and the teacher desktop app was made using React JS as the front-end library and Styled Components for styling to be demoed on a web browser.
• This choice was influenced by a bias for action because it would take less effort to use the same technology for both interfaces.
• For the student app, the resolution in the browser was fixed to that of a mobile's dimensions which would make it resemble a mobile app.

Hosting & Deployment

• The deployment pipeline and the hosting was made possible through Firebase, which is a platform developed by Google.
• This was primarily because our content was static for the demo and Firebase provides these minimal services at no cost.

Event Management

• To glue the 2 apps together, Solace was used for implementing features like live chat during the lecture and the common slideshow.

Data analytics for the class session

• Dash and Plotly libraries were used to collect and analyze the data from the session.

‍

The team prepared a presentation deck using Google slides for our 7 minute presentation at the end. We made use of stock dinosaur assets to make them more appealing!

The demo went extremely well and we received an overwhelmingly positive feedback for the product. Some noteworthy comments included

• "Ship it!"
• "Take my money now!!"
• "I'm ready to invest in this product."
• "A few more days and we could sell this!"

Though we did not cover the metrics during the event, I came up with these critical factors which would measure product adoption and student engagement.

Qualitative metrics

• Timestamp of the class when a student drops off - This could indicate key moments within the lecture that may be uninteresting to other students
• Feedback at the end of every class - A subjective feedback or even a likert scale would help the teachers understand areas of improvement

Quantitative metrics

• A/B comparison of the number of classes attended - We could run classes on another educational platform and do a control-sample testing to observe direct correlation of attendance with the new platform
• Duration of class attended - A simple indication of whether the students are sticking around till the class completes
• Number of click events on polls, raise a hand feature, emoticons and live chat - These indicate active involvement of the students during the class. Moreover, the number of clicks separately will also help us gauge the popularity of these features amongst students and accordingly pioritize/deprioritize them in the future.
• Number of visits to the trophy room - This will help us know whether students are fascinated by trophies. More data can be collected on this screen, like if a student taps over a particular trophy regularly that would imply it's special to that student, giving us insights into what type of trophies are desirable.
• Number of workbook accesses - This would help us measure if having a digital workbook for students was indeed a good idea or if they'd rather use other methods like a separate app for that.

I learnt a ton during this roller-coaster ride of an event to say the least. The most memorable moments for me were the brainstorming, where we came up with a meaningful and actionable problem statement from the initial plethora of ideas, and the design phase where we saw the power of collaboration and how multiple designers working in sync accelerated a great product!

I feel that everyone in the team shared a positive attitude towards a common goal which helped us complement each other's skills very well. Moreover, the frequent scrum-meetings we had as a complete team made that morale soar high.

A notable problem I realized was it was difficult when many people tried to work on the same aspect of a subproblem, for example - several people trying to design 1 screen simultaneously could be tedious if not done properly. In these cases, I learnt that it's better to break out into smaller groups, tackle a subproblem and then collate after a collective discussion, like following the quick wireframes technique in the above example.