CommuniCourse: From a Problem to a Prototype
by The Baguettes
Introduction
As any student in 2020 can attest, online learning is challenging. Due to a lack of motivation and peer support, it can be hard to progress through online content. We need better tools for online learning that can provide these supports.
We tackled this issue by creating a mobile application called CommuniCourse. The value proposition for our application is different from other learning platforms like Udemy and Coursera: instead of providing expensive, sequential course content, CommuniCourse provides an online platform for crowd-sourced course content that users can navigate more freely. Rather than forcing users to follow a strict learning pathway, CommuniCourse uses algorithms to recommend relevant content based on a user’s course progression. The course content provided is linked to various external sources, allowing users to find the best content regardless of the platform. Furthermore, the application places a large focus on connecting with the community through course-based group chats. CommuniCourse offers more than a place to consume content — it is a place to both learn and contribute to the educational community.
How can we make it easy to get peer support? How can we motivate online learners? How does one even make a community-oriented learning platform? These are questions we needed to focus on throughout our design work. Over the past three months, we have progressed through five stages of iterative design: empathize, define, ideate, prototype, and test. Along the way, we faced numerous challenges — ranging from design problems to issues with the design process itself. Nevertheless, by the end, we developed a prototype that demonstrates the key elements of our collaborative learning platform.
Empathize & Define Stages
To start our design process on the right track, we needed to understand our target users’ needs. This goal encapsulates the motivation behind the activities within the empathize and define stages. We began by identifying personas for our target users and continued by conducting research to better understand prospective user needs. We created three personas in order to guide our design.
Sam: Sam is a 22 year old university student who is inexperienced in fitness and exercising. She is looking to start a fitness program to feel healthier and be in better shape.
Mark: Mark is a professional chef who works at a high-end restaurant. He wants to expand his knowledge of unique technologies and add creativity to his expertise.
Peter: Peter used to play the piano and wants to get back into his creative side by learning how to play again. He hopes that playing the piano will be a coping mechanism during hard COVID times. He doesn’t know any musicians so he wants to find a way to learn and connect with others who share this interest.
While personas are a useful tool, they can be misleading without user research. Thus, we conducted interviews with people who matched our personas to better understand their challenges with current online learning platforms. Our interviews had two parts: firstly, the participants filled out a questionnaire about their learning and online community preferences. Afterwards, we conducted free-form interviews to give participants a chance to talk through their thoughts and experiences.
Participants responded that they are more motivated to learn when they have a peer group. Furthermore, they like the personal touch of in-person classes, but they also appreciate the flexibility of online learning. This showed us that there is a need for a community aspect in our application. Additionally, participants had varied preferences regarding class sizes. From this, we realized that our platform needed to provide space for both more anonymized, wide-open forums and more personal, direct discussions.
We formulated these results into an affinity diagram in order to better understand the myriad of data points gathered. Through the exercise, we identified four key categories of needs: motivation, course content, learning style accommodation, and community. In summary, the participants wanted more incentives to learn, better ways of finding quality learning resources, better accommodation of their unique learning styles, and the ability to get community support.
Using the insights gleaned from the affinity diagrams, we identified three key tasks to help users achieve their goals: selecting course content to view, getting peer support for the course content, and adding to the course content. Through hierarchical task analysis, we started gathering our thoughts together so that we have foundational goals for the features we will need to determine in the following stage.
The first task, selecting content to learn, is critical in helping users achieve their learning goals. We want to make it easy for users to review recently viewed content, resume work in progress, and perhaps most importantly, find the next logical content to view. The second task, getting peer support when they have problems, is similarly important. Receiving help from their peers helps users continue through a course and engage them in the course content. It also helps foster the sense of community we want our app to give to our users. For our final task, it is key for the improvement of the quality of the courses to allow users to contribute to a course through adding external content such as a YouTube video, a quiz, a deck of flashcards, or an article. Courses are built and managed by their communities which allows for constant evolution to reflect the users’ needs.
Throughout the empathize and define stages, we developed a stronger understanding of our target users and what they would need to do on our collaborative learning application. We carried these initial ideas throughout the remainder of the design process. We consistently consulted our personas to ensure that we remembered the needs of the users that are the core of our design goals and our task analysis was foundational in the design of our features as it confirms that we are designing features that actually satisfy the needs of our users.
Ideate Stage
In the ideate stage of our design process, we focused on generating ideas and concepts to solve the problems established in the define stage. We began by brainstorming as many features as possible that users might need in order to achieve their goals. From there, we identified five important features that we felt brought the most value to our users: a course content rating feature, a course content tagging feature, a notification system, a community posts forum, and a live chat.
From these five, we felt that the notification and chat features in particular helped users achieve their goals. In our interviews, we noticed that many participants find it difficult to stay motivated and keep up with online learning. Having intelligent reminders that prompt the user to view course content at appropriate times could help them maintain a learning schedule. Participants also found it easier to stay motivated when they learned alongside their friends and had peer support. Many also stated that a downside to online learning is that it lacks a personal touch. For these reasons, we wanted to highlight community engagement in our application and a live chat feature would help users connect with other members in their community. Therefore, of the five original features, we decided to focus on iterating over the design of the live chat and notification system.
In order to conceptualize the features, we created user stories, storyboards, sketches, and user flows. User stories helped us establish how users would utilize these five features. Using our personas, we created storyboards to illustrate a user’s experience with the feature. Storyboards helped us emphasize with the user’s frustrations and motivations. Both the user stories and storyboards helped to present the importance of providing these features.
We then sketched rough drawings of different possible implementations. This was a good, low-cost way to play around with and evaluate different ideas and layouts. After deciding on the concept, we created a simple sketch of each feature. These sketches provided a visual explanation of how the basic concept works and helped us picture the feature. From the sketches, we constructed user flows which illustrate the user’s interaction with the feature through screen sketches and indicators noting the user’s actions.
The chat feature lets users create their own sub-community group chats and includes direct messaging as illustrated above. Users can utilize this feature to ask for help from peers, share interesting content, and connect with other members of their community.
The notification system prompts the user to view course content at appropriate times and aims to help them maintain a learning schedule. This feature is customizable in order to suit different users preferences and schedules.
Overall, this stage was especially insightful in showing us the role of iteration in the design process. Throughout ideation phase, we altered our features many times, forming the base for our chat and notifications features which we continued to iterate in the following stages.
Prototype & Test Stages
As we moved towards the last design stages, we developed prototypes to simulate the UI and functionality of the application. Rather than starting with a high-fidelity prototype, we iteratively built more and more detailed prototypes, gathering feedback from others after each iteration. Through these stages, we focused on our two key features: the chat and notifications features.
Our first prototype was a low-fidelity paper prototype based on our user flow designs. This original prototype was implemented in Figma. We learned early on that using a sophisticated system like Figma was not as good as physical paper prototypes for the early stages of prototyping. Figma is powerful, but without elaborate interaction setups, it can limit the types of interaction users can perform. This became evident with our first round of prototype testing: our test participants struggled as most interactions beyond simple movement had no feedback.
For the evaluation of our initial prototype, we had three test participants who were all avid smartphone users that were familiar with using their devices for communication and personal organization with calendars. All of them reported messaging at least multiple times per day. It would have been desirable to test our prototype with some participants who rarely use smartphones to avoid biasing our results towards what seasoned users expect, but we had limited access to participants.
For the first part of the study, we asked our test participants to send messages, add members to the chat, and mute notifications from the chat. Overall, our study revealed that our preliminary design was confusing. For example, all of our participants struggled to close the chat: the up arrow in the top right corner was not a familiar signifier for returning to a previous screen. Additionally, without context, the circular avatar icons on the right hand side were ambiguous and users didn’t know if they were avatars for the users in the active chat or buttons to view other chats. This became an issue when we asked users to add a member: instead of opening the chat information screen, they hit the button for adding a new chat. Furthermore, when participants tapped the “Mute Chat” button, the prototype redirected to the settings menu, which participants found unnecessary and confusing. Our last key insight was that the chat information screen was cluttered, so we reworked this in our next iteration along with the other concerns about our chat feature.
In the second part of the study, we asked our participants to change the notification settings for one of their group chats and edit a weekly reminder. This was another place where the digital prototype format led to issues: it was difficult to represent how toggle bars changed when participants tapped them. In general, they found our representation of the weekly reminders confusing; when told to edit a reminder, one participant created a new one instead. Additionally, we realized that having a single page with global settings for group chat notifications was redundant. The only feature our participants thought was essential was the ability to mute a chat, which was easier to do on the chat information page. Our participants also suggested a few additions, such as confirmations before overwriting or double booking reminders, and providing options beyond just weekly reminders. We implemented these suggestions in our high fidelity prototype.
In our second prototype iteration, we focused on simulating the user experience more closely. We refined our branding with a colour scheme and logo, and standardized our application’s overall style. Furthermore, we built up more of the foundations of our app like the dashboard and course content pages. We once again built our prototype in Figma, but in this iteration, we implemented more detailed user interactions and our features were better integrated for a more meaningful simulation of our end goal. We evaluated this prototype with a cognitive walkthrough and two heuristic evaluations, conducted by a new participant and two students enrolled in CS 449/649 at the University of Waterloo.
We came up with three scenario-based tasks that each evaluation would use. The tasks we chose for participants were to send a message to share sheet music with their group chat, find and review a sourdough recipe, and set a reminder to play piano. For our heuristic evaluations, we also chose some heuristic criteria based around user freedom and ease of use to evaluate our design on. For the cognitive walkthrough, we broke down each task into basic steps forming an action sequence to use during the evaluation. We then took the results of these evaluations and turned them into improvements for our prototype.
From the cognitive walkthrough, we learned that the group chats could have less clutter by only showing a name once before a series of messages from the same person. Furthermore, we realized that the ordering of the chats in the chat home screen was not clear and that adding timestamps would help resolve this ambiguity. We reworked the chat and the chat home screen in our final prototype to include these changes which made our design cleaner and more intuitive.
After doing the heuristic evaluations, we learned that the notification feature did not have enough visibility due to the fact that participants had to click through many screens in the settings menu to access it. This led us to lifting that feature out of the settings menu entirely and creating a new icon directly accessible from the navigation bar. In the final prototype, the feature is available right from the home screen and can be easily reached.
Throughout the prototype and test stage, we improved and refined our application design by iteratively creating more detailed prototypes and gathering feedback from others outside our team. All of the design stages culminated in a completed prototype, with features repeatedly refined based on user feedback, from the first exploratory study to the final heuristic evaluation.
Conclusion
Throughout the design process of CommuniCourse, we have developed and tested prototypes for a community learning platform. What differentiates our platform is its focus on providing peer support and keeping users motivated towards their goals.
This is just the beginning. In order to support learners online, there are missing pieces we have yet to consider. For instance, to incentivize progression through courses, our next step would be to gamify the application by providing badges and progress indicators. In addition, we also want our application to be compatible with voice assistants to improve the overall user experience.
To improve our peer support experience, we will have a system that identifies user interest and suggests users to join groups. Also, to build a sense of a cohort working through levels of a course, the system will place users in group chats with users at a similar level.
Given our current course content and resourcing strategy, we also understand the course quality challenges that will accompany our crowd-sourced platform. Thus, we need a system for submitting and reviewing course content.
Looking back at our journey, we’ve learned a great deal about how to take a problem and create a prototype solution. Before even coming up with designs, performing an exploratory study helped us understand the wants and needs of potential users. This made it possible to support our design decisions in the ideate phase with real data, helping us make informed decisions on how our application would work. The iterative prototype and testing phases made it possible to build a more intuitive product with easier navigation. Critiques for our designs were invaluable throughout every stage to get feedback and help improve our vision.
However, there were also some pitfalls along the way. We moved through the design stages linearly, for the most part, giving us first hand experience about the benefits of iterating and repeating several stages of the design process. While we iterated and improved our features over time, it felt limiting to be locked into our previous choices. We could have benefited from revising our ideas by revisiting past design stages instead of simply iterating the downstream results.
Furthermore, some design exercises could have benefited from multiple sessions. We chose the initial layout of our chat feature after a quick crazy 8s brainstorming session, but eventually decided to change the chat screen based on the feedback in our studies. We had a limited design space initially and then pivoted to a new idea without slowing down to consider additional design options. We could have expanded our choices by repeating the exercise and spending more time generating alternatives once we concluded that our initial design was lacking.
Our biggest takeaway from building CommuniCourse is how to focus on the user. It takes time to perform exploratory studies and prototype evaluations, but the results justify all subsequent design decisions. This ensures that the product matches user needs, before even touching a line of code.
