Zoom 2.0: Redesigning Zoom for better classroom engagement

Just over a year ago (at the time of writing), the world as we knew it changed completely due to the COVID-19 pandemic. With people no longer able to meet face-to-face, in came Zoom as the video conferencing tool of choice to replace all physical interactions. In-person classes also became a thing of the past and attending ‘Zoom University’ soon became the new status quo.

Here in the National University of Singapore (NUS), the impact of Zoom can be keenly felt by professors and students alike. The ride has not been smooth-sailing though — pick any current NUS student and they will most likely have witnessed their professor and/or teaching assistant (TA) struggling to get to grips with the Zoom interface. The effect — poor class engagement, unnecessarily long classes, or even silent lectures. (We’re not joking here — a professor contrived to deliver an entire 2-hour lecture while his microphone was muted. Ouch.)

This is where we, a group of 5 Zoom-fatigued NUS undergraduates, came in. We believe that professors, TAs, and students deserve a better Zoom experience with redesigned and enhanced features to make online classes more enjoyable and enriching. Thus, the challenge we set ourselves here is to design a Zoom 2.0 prototype which will tick all of the above boxes.

Sneak Peek of Zoom 2.0 Prototype

Participation Tracker

Many NUS modules have a participation grading component. Currently, it is very cumbersome to track student participation within a Zoom class. This sentiment is echoed by the following quote from a TA:

“…I have to CTRL+F names in Excel and see how many marks a student has before deciding to call him to answer the question. A built-in participation tracker within Zoom would save me a lot of time”

This TA, among many others, would be elated to hear that we have indeed implemented such a participation tracker within our prototype. There is now no need for external participation tracking tools like Excel. Excellent.

Built-in participation tracker with a scoring system

Control Room

Zoom’s breakout room feature has also been the subject of vehement complaints. Here is one such example from a NUS professor:

“Joining breakout rooms one at a time takes really long and sometimes I don’t have enough time to visit all the rooms during a breakout room session. So I’m worried that I couldn’t help some of the students in the rooms that I couldn’t visit”

To solve this problem, we designed a control room feature, whereby all breakout rooms can be viewed within one window. Now teachers can see how every student in each breakout room is faring at one go.

Control room with all breakout rooms within one window

👉 Click here to skip ahead and try out the Zoom 2.0 interactive prototype👈

Design Process

With a clear idea of what we wanted to achieve, we embarked on the design process to do a comprehensive case study of Zoom.

Our design process is modelled on the British Design Council’s Double Diamond framework. Here we have summarised our methodologies in each phase of the design process.

Double Diamond framework

Target Users

We first identified our primary target users as professors and TAs from NUS. But that’s not all. After all, teaching is a two-way street. Students like us play a key role too! Thus we selected NUS students from various faculties as our secondary target users. However, we excluded Year 1s because they have never experienced physical university classes before, so they have no basis of comparison with Zoom classes. (Yes, they matriculated during the height of the pandemic — their university experience is mostly limited to a computer screen. Joy.)

Contextual Inquiry (CI)

To better understand our target users and their pain points, we conducted CIs for 6 target users (3 teaching staff, 3 students). We devised a common set of questions for each target group, some of which are shown below.

Example questions for teaching staff:

“How do you break out the class into the smaller groups?”

“Do you find it difficult to oversee such groups and ensure they get guidance?”

“How do you capture participation by different students? Is it a hassle?”

Example questions for students:

“How do you participate in the lesson when the professor/TA asks a question?”

“If you have a question during class, how do you ask it?”

“How is the experience of using breakout rooms during lessons?”

From the CIs, we collected a rich amount of data on how our target users accomplish their day-to-day teaching and learning tasks in Zoom. But as always, quantity doesn’t equate to quality — more work was needed to make sense of all the data.

Affinity Diagram

To make the CI data more insightful, we crafted an affinity diagram to uncover valuable patterns in user needs, desires and problems.

Affinity Diagram

We also summarised the most common user needs, goals, problems and constraints for our primary and secondary target users in the following infographic.

User Needs & Goals (Teacher / Student)

3 Key User Tasks

Based on the earlier findings, we determined 3 key user tasks which are as follows:

  1. Assign breakout rooms and monitor breakout room activities (teacher)
  2. Communicate during a breakout room session (teacher and student)
  3. Track participation of students during a class efficiently (teacher)

We selected these user tasks based on the severity and frequency of breakdowns (e.g communication during breakout rooms), the potential to introduce a new feature that would have a significant impact in the classroom setting (e.g tracking participation within Zoom) and whether the task would allow us to generate novel design ideas (e.g monitoring breakout room activities).

User Personas

We crafted 2 user personas for teachers and students so that we could better empathise with our users and bring our data to life.

User Journey Map

After creating the personas, we decided to zoom in (pun intended) on our primary target user, namely the teacher. We crafted a User Journey Map for our teacher persona, Ben, so as to better understand his journey across the different phases of conducting a Zoom class.

User Journey Map for our Teacher persona, Ben

The user journey map also allowed us to identify design opportunities across different phases which served as a guide going into the prototyping phase.

👉 Just a quick note: The following sections showcase the prototyping and evaluation stages of the design process, as well as the UX design considerations. If you feel like that is not your cup of tea, feel free to skip all the way to the end to try out our working interactive prototype!

Scenarios and Storyboards

With the user research data in hand and the 3 key user tasks defined, we were ready to dive deep into the prototyping stage of the design thinking process, which began with Storyboarding. Here, we crafted 3 storyboards to illustrate our target users’ potential experiences for each of the 3 key user tasks.

Key Features:

  • Assign participants to breakout rooms via pre-defined excel file
  • Allocate tasks to each breakout rooms, allowing teachers to monitor the progress of the breakout rooms as students update their progress by checking off completed tasks
  • Monitor students in each breakout room via a “Control Room View” without needing to join the room ⇒ allows for quick intervention if teacher spots a group that needs help

Key Features:

  • Communicate with participants in breakout rooms from the main room, either by joining the room or by chat messages ⇒ allows teacher to quickly address students’ queries via chat and still be able to respond to other rooms at the same time
  • Make a verbal announcement to quickly convey new information to all breakout rooms
  • Broadcast messages should appear in chat history (instead of the current disappearing behaviour in Zoom, as of this writing)

Key Features:

  • Assign participation scores to students with an in-built tracking tool in Zoom so that participation tracking is streamlined
  • Participation scores can be loaded from and saved to Excel
  • Metrics can be used to provide more information to teachers about statistics of students’ participation in class (e.g. how long a student spent talking)

Wireframes

With the rough idea of the features we wanted to improve or implement based on the storyboards, we were ready to start wireframing in Balsamiq.

But first!

Since we had a team of 5 designers, we figured we could make use of another prototyping process that would otherwise be very hard to do individually: Parallel Prototyping. From the storyboards onwards, each of us branched off and worked in parallel to design lo-fi and hi-fi prototypes independently. We then combined the best features of each of our prototypes to develop a more polished prototype in the subsequent stages. Using this method, we were confident that our final designs when combined would be as refined as it could be, reaching a global optima rather than a local optima, so to speak. (But don’t just take our word for it, check out a case study by Nielsen Norman Group about the benefits of parallel design.)

Each of us chose 2 scenarios (out of 3 total) for which to develop wireframes. For brevity, the wireframes shown below showcase only 2 alternatives per scenario, Prototype A and Prototype B.

Having multiple alternative wireframes allowed us to conduct a round of internal evaluation and choose the best designs and features to be incorporated in the hi-fi prototype.

Individual Hi-fi Prototypes

Once again, we made use of parallel prototyping to create the hi-fi prototypes in Figma. This time, each of us developed a prototype for only 1 scenario. Using our own prototypes, each of us conducted a round of usability testing with our target users to gather user feedback about any usability issues. In addition, we conducted a round of internal evaluation to uncover more usability issues, before finally combining our individual prototypes. The examples below showcase the user feedback, both good and bad, on our individual prototypes.

Note: The examples below show only a subset of the features developed in each prototype. Other features were similarly judged and combined in the final prototype.

Scenario 1

Editing of tasks after breakout rooms were created. Note that the same interface layout is used for creating breakout rooms as well.

The Good ✅

  • Editing and creating tasks use the same interface layout, thus maintaining consistency
  • Visibility of system status (Assign > Set tasks > Create!)

The Bad ❌

  • Inconsistent with Zoom design language (different font, different blue hue, non-rounded buttons)
  • Chromatic aberration (red on blue) leading to bad contrast
  • User did not recognise the task progression bar (Tasks are a new concept, so “1/4” is not intuitive)

Scenario 2 (Teacher’s POV)

Prototype A

Sending a broadcast message to all rooms from the main room (i.e. “Control Room”)

The Good ✅

  • Consistent with Zoom’s design language
  • Breakout room controls are located at the bottom, right above Zoom’s existing controls. This close grouping of controls makes it easy for user to find the control that he needs.
  • Broadcast messages show up in chat history just like normal messages

The Bad ❌

  • Broadcast messages are not distinct from normal messages
  • Hard to differentiate participants across rooms as the spacing between each row is too small

One of the 10 Nielsen’s heuristics, Consistency and Standards, served as the guidepost in the design of this prototype. All UI elements were designed to adhere to Zoom’s branding guidelines, as well as to maintain consistency with the existing Zoom controls to keep in line to users’ expectations, by the Principle of Least Astonishment.

Prototype B

The Good ✅

  • Broadcast messages show up in chat history just like normal messages
  • Broadcast messages are immediately distinguishable from normal messages by colour

The Bad ❌

  • View of participants video feeds is inconsistent with Zoom’s existing layout (names are not displayed above the video feeds)
  • Too much space between each row of rooms
  • Font size and buttons are too large
  • Suboptimal visual hierarchy — breakout room control panel takes up too much space at the top, leaving less space to display the more important information (i.e. view of the participants in each room)
  • Breakout room control panel is very far from Zoom’s existing controls, so users have to look up and down to find their intended controls

Both prototypes displayed broadcast messages in the chat history between the host and each individual room, which is an improvement over Zoom’s current broadcast messages (which disappear after a few seconds and do not show up anywhere afterwards).

Scenario 2 (Student’s POV)

Participant asks for help from inside the breakout room

The Good ✅

  • Participants can see the amount of time remaining to complete their tasks
  • Participants can invite the host into the breakout room if they have questions for the host
  • Participants can send chat messages to the host (outside the breakout room) via Chat

The Bad ❌

  • Inefficient communication as participants have to click on both Invite Host and Chat to inform the host as to why they require the host to join the room. A better solution would be to let participants send an accompanying message to the host when they invite the host to their room.

Scenario 3

Prototype A

Awarding participation marks to students

The Good ✅

  • Consistent with Zoom’s design language
  • Participants can be awarded marks regardless of whether they raised their hands
  • Display of participation scores of each student integrates well with the existing Participants panel in Zoom

The Bad ❌

  • User wanted a feature to randomly pick a student to answer a question

Prototype B

The Good ✅

  • Participants who raised hands will get sorted to the top of the list

The Bad ❌

  • Participants can only be awarded marks if they raise their hand, but this is too restrictive on the conduct of the class
  • Showing participation statistics causes unnecessary information overload and is too big of a change to the existing Participants panel in Zoom
  • Purpose of “Done” button is unclear and ambiguous

The usability issues from both our users’ feedbacks and our own expert internal evaluation were categorised according to severity level (‘Catastrophic’ > ‘Major’ > ‘Minor > ‘Cosmetic’ > ‘No Problem’). This allowed us to prioritise which issues to address first.

At the same time, we combined our individual prototypes into 1 coherent prototype for the next stage of iteration. For scenarios where there were multiple prototype options (i.e. Scenario 2 and 3), we chose the one with fewer usability issues as the ‘base’ and incorporated features from the other option into the ‘base’. Here are some before-and-after screens based on the issues highlighted above.

Our next step was to conduct another round of usability testing and evaluation for the combined hi-fi prototype. For brevity, only notable examples are taken from each of the 3 scenarios to show the issues highlighted and the subsequent design modifications made to our final prototype.

Assigning participants to breakout rooms via excel file

Before / After

Problem:
User pointed out that loading excel files might be an issue because of different table formats. Additionally, user was left wondering if the file was successfully uploaded as he could not tell.

Evaluation:
The main issue here was the lack of clear instructions on file formatting. We decided to not only provide instructions, but also a pre-formatted template for room allocation. This saves the user the trouble of creating a file, and also enforces the file format to prevent any confusion.

Design Adjustments:
✅ Provide instructions to the user on the spreadsheet format to use for uploading Breakout Room allocation, as well as a template for reference.
✅ Visibility of system status — updates are reflected as the file is uploaded

Breakout room notification banners

Before / After

Problem:
User noticed the banners when they popped up, but he did not know that it could be interacted with (click to go to room).

Evaluation:
User’s suggestion was to add an animation to the banner to get future users to interact with it. However, based on our internal evaluation and discussion, we felt that animations only draw attention to the banner without solving the key issue of informing the user that the banner can be interacted with. Instead, we decided to use tutorial-styled information cues to explicitly inform the user.

Design Adjustments:
✅ Help and documentation — instruction overlay that informs the user how to interact with the banner

Viewing participants’ shared screen in breakout rooms

Before / After

Problem:
User either did not notice the View Shared Screen icon or did not understand its purpose (which was to open a view of the participant’s shared screen)

Evaluation:
Indeed, there was no established icon convention for a View Shared Screen icon. Hence, instead of using an icon button to view the shared screen, we decided to make it more obvious by stating that the participant is sharing their screen and placing a View button beside it.

Design Adjustments:
✅ Clear statement of “Participant X is sharing screen”
✅ Consistency with Zoom’s design on share screen mode (using green labels when sharing screen)
✅ Match between system and real world — Use clearer instructions (“Participant X is sharing screen”, “View”)

Announcement notification banners

Before / After

Problem:
Before the user can make a verbal announcement, the user is supposed to wait for all rooms to be notified via a sound alert. However, the user started announcing during this time. This suggests that the banner may not be obvious enough, and/or the banner’s wording “Notifying rooms for announcement” is not clear enough to inform the user to wait before speaking.

Evaluation:
We changed the format of the instruction from a banner to an overlay notification to make it more noticeable, and used clearer wording to give a stronger impression for the user to wait for the sound alert to be over before speaking.

Design Adjustments:
✅ Match between system and real world — Use clearer instructions (“Please wait”)
✅ Have the notification occupy the screen with overlay to signify that this is a compulsory step

This brings us to the end of the entire design process! Now, we present to you…

Zoom 2.0!

If you are a Teacher, our redesigned Zoom experience features:

  • Easy assignment of breakout rooms by uploading an Excel file
  • In-built task allocation within the Zoom breakout room creation process
  • Control Room View providing an overview of all breakout rooms allows you to monitor activity in all rooms
  • Task progression bar allows you to gauge room progression and easily pick out rooms that need help
  • The ability to speak and send chat messages to any room while still maintaining an overview of all rooms allows for easier and more efficient communication
  • Broadcast messages now show up in chat history, allowing both teacher and students to easily refer to past broadcast messages at any point in time rather than disappearing
  • Verbal announcements can be made to all breakout rooms at one go to convey urgent and important information
  • Participation Tracking tool built into Zoom itself to reduce the use of external tools for manual tracking. Metrics can be stored and loaded for accumulative tracking.
  • 5-star rating system to allow scoring of student’s answers during participation

Try it out!

Make sure to scale down to fit the display for a better experience.

If you are a Student, our redesigned Zoom experience features:

  • Checklist of allocated breakout room tasks.Tasks progression can be seen by the teacher in real time
  • Ability to instantly communicate with teacher via chat messages when he/she is not in the room makes it easier to clarify doubts

Try it out!

Make sure to scale down to fit the display for a better experience.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store