CAHOOTS
“How many times have you started a planner, only to abandon it a week or two later? Keeping a planner up to date is hard. We slack and we forget things. That’s why
we built Cahoots. Cahoots leverages the knowledge of your peers so that you’ll never
forget an assignment, quiz, or deadline again. With just a few taps, you too can have an organized planner of your own.
Your peers know what to do, and now you do too.”
BACKGROUND
|
Date: January 2015 - March 2015
My Roles: Front-End Developer, UX/UI Designer and Researcher
|
Project Members: Ho-Wei Kang & Ashley Perez
Toolbox: Google Docs & Sheets, Ionic, Adobe Photoshop, Google Hangouts, Github
|
That paragraph was our team's pitch at the final presentation for a ten-week course that introduced fundamental design principles and implementation of web-based systems. With our studio’s theme, “Becoming Better Students”, our objective was to build an effective product that allowed students to be better organized for the academic school year. This led to the creation of Cahoots, an application that incorporated crowdsourcing to help students easily keep track of assignments, midterms, and other classwork in an efficient, seamless manner.
RESEARCH
Need Finding
Considering our web application's goal, which is to simplify a student's life, we started to focus on the struggles that many students face today. Our team agreed that maintaining an updated academic planner can become more difficult as the quarter progresses. So with this thought, we commenced our plan with the question, "How do students currently organize their academic planner?". We made it our mission to discover students' motives, values, and frustrations by observing and interviewing them in their environments.
Considering our web application's goal, which is to simplify a student's life, we started to focus on the struggles that many students face today. Our team agreed that maintaining an updated academic planner can become more difficult as the quarter progresses. So with this thought, we commenced our plan with the question, "How do students currently organize their academic planner?". We made it our mission to discover students' motives, values, and frustrations by observing and interviewing them in their environments.
A Highlight From an Observation
Considering our web application's goal, which is to simplify a student's life, we started to focus on the struggles that many students face today. Our team agreed that maintaining an updated academic planner can become more difficult as the quarter progresses. So with this thought, we commenced our plan with the question, "How do students currently organize their academic planner?". We made it our mission to discover students' motives, values, and frustrations by observing and interviewing them in their environments.
Considering our web application's goal, which is to simplify a student's life, we started to focus on the struggles that many students face today. Our team agreed that maintaining an updated academic planner can become more difficult as the quarter progresses. So with this thought, we commenced our plan with the question, "How do students currently organize their academic planner?". We made it our mission to discover students' motives, values, and frustrations by observing and interviewing them in their environments.
|
|
|
Discoveries
- There was an overwhelming amount of platforms. Depending on the subject and the professor, students are expected to use a wide range of platforms.
- Keeping a planner up-to-date became tedious.
- Required a constant need to check and log into different websites.
- Manually inputting assignments and exam dates became laborious.
- There were various ways a student could organize his or her academic obligations.
- E.g. Google Calendar, school planners, mental cognition, Notes, etc.
- Students struggled in remembering assignments when professors constantly changed them.
- Students relied on their peers via social media or texting to catch up with missed classwork and future assignment due dates.
- Students started off strong in organizing their academic planner in the beginning of the quarter. But as the quarter progressed, students tended to slack off.
Competitive Analysis
|
|
|
|
To gather more insight, we looked into a wide range of resources that students used. We realized that each option provided a specific value but that in itself was a constraint. By taking everything into consideration, we wanted to aggregate the positive qualities and focus on how to avoid the limitations.
Ideation
Throughout our research, we discovered the need for a more efficient and effortless facilitation in managing academic tasks. Students waste too much of their time completing tedious but important tasks such as looking up dates for midterms, figuring out their homework, and deciding how to prioritize everything within their schedules. They collectively spent excess time checking a copious amount of websites, logging into TED, downloading and scrolling through syllabuses, and recording due dates and exam dates by hand. Our team agreed that this particular problem was worth solving. In the end, it is a student’s responsibility to be aware of what is expected from class. If we can make this task less burdensome, we believed that we could help them to be the best students they can be.
However, our team didn’t want to solve this problem at a surface-level by throwing another gimmicky planner application for them to download. We wanted to solve the underlying issue of why students have such difficulties in creating an organized, up-to-date planner through an easy-to-use app. By empathizing with the students’ needs and behaviors, our team sought to create a planner that crowdsourced tasks of other students, teacher assistants, and professors. With crowdsourcing, we eased the responsibility of remembering deadlines and organizing priorities. On top of that, it served as a friendly reminder that the app was open to anyone and everyone who needed a convenient source that could remove some stress from a busy lifestyle.
Throughout our research, we discovered the need for a more efficient and effortless facilitation in managing academic tasks. Students waste too much of their time completing tedious but important tasks such as looking up dates for midterms, figuring out their homework, and deciding how to prioritize everything within their schedules. They collectively spent excess time checking a copious amount of websites, logging into TED, downloading and scrolling through syllabuses, and recording due dates and exam dates by hand. Our team agreed that this particular problem was worth solving. In the end, it is a student’s responsibility to be aware of what is expected from class. If we can make this task less burdensome, we believed that we could help them to be the best students they can be.
However, our team didn’t want to solve this problem at a surface-level by throwing another gimmicky planner application for them to download. We wanted to solve the underlying issue of why students have such difficulties in creating an organized, up-to-date planner through an easy-to-use app. By empathizing with the students’ needs and behaviors, our team sought to create a planner that crowdsourced tasks of other students, teacher assistants, and professors. With crowdsourcing, we eased the responsibility of remembering deadlines and organizing priorities. On top of that, it served as a friendly reminder that the app was open to anyone and everyone who needed a convenient source that could remove some stress from a busy lifestyle.
DESIGN PROCESS
Our vision for the web application was to alleviate the burden of creating a planner and give an existing planner with up-to-date tasks based on the user’s classes. With the automatic updates of tasks, students did not have to worry about constantly checking and inputting information themselves. Our primary goal was to enhance the productivity of a student's life.
Storyboarding
We initiated our design process by coming up with two different design ideas that addressed our users’ needs. Our goal was understand how we can effectively meet our users’ needs so we can ultimately pick one design that resolved the problem.
We created one storyboard for each design to illustrate how we can engage the users and address their needs with our proposed interfaces. We wanted to show what a student can accomplish in a real usage scenario with our interface.
We initiated our design process by coming up with two different design ideas that addressed our users’ needs. Our goal was understand how we can effectively meet our users’ needs so we can ultimately pick one design that resolved the problem.
We created one storyboard for each design to illustrate how we can engage the users and address their needs with our proposed interfaces. We wanted to show what a student can accomplish in a real usage scenario with our interface.
Scenario #1 (Prototype #1)
|
|
We illustrated in this scenario how our app eased the frustrations of a student's need to navigate through the overwhelming amount of websites for updates. In this particular design interface, the user was notified with upcoming assignments, exams, etc and was asked to either add or disregard these tasks in their planner. This allowed for flexibility of personalizing a planner.
Scenario #2 (Prototype #2)
|
|
In this scenario, we had a student excited about the idea that his professors and teacher assistants teamed up to use one application. In this design interface, our goal was to aggregate all these different platforms to create the ultimate application that worked both as a planner and resource center.
Once we finished storyboarding, we moved onto building two paper prototypes for the two different approaches seen in each storyboard.
User Testing
Once we created these prototypes, our team sought three of our classmates to perform heuristic evaluations. Our intentions with these evaluations were to identify and highlight any usability issues like broken flows, content gaps, and pain points our prototypes have that we might have missed.
Once we created these prototypes, our team sought three of our classmates to perform heuristic evaluations. Our intentions with these evaluations were to identify and highlight any usability issues like broken flows, content gaps, and pain points our prototypes have that we might have missed.
Prototype #1
|
|
|
Feedback
- No login button.
- No clear way to get back from Honeycomb button (suggested events feature).
- Checkmarks on main list look like bullet points.
- Settings “icon” confusing, looks like thee logo.
- “Add” button under suggested events list looks like checkmark.
Prototype #2
|
|
|
Feedback
- No login button.
- Cream icon is confusing without explanation.
- No edit or delete option for comments.
- No settings page.
- No way to customize/prioritize itches/tasks.
- No way to add your own itches, limited to school itches.
Final Decision
Students were drawn to the idea of having control and freedom over what tasks can be added, deleted, and prioritized in their planner. Prototype two limited the students from personalizing and interacting with the application; it acted more of a universal platform where professors can add documents and updates. Between prototype one and prototype two, there was an overcoming agreement that prototype one's UI was much more intuitive and simple.
After considering the feedback from our evaluators and deliberating with the team members, we decided to go with the functionality and user interface of prototype one.
Students were drawn to the idea of having control and freedom over what tasks can be added, deleted, and prioritized in their planner. Prototype two limited the students from personalizing and interacting with the application; it acted more of a universal platform where professors can add documents and updates. Between prototype one and prototype two, there was an overcoming agreement that prototype one's UI was much more intuitive and simple.
After considering the feedback from our evaluators and deliberating with the team members, we decided to go with the functionality and user interface of prototype one.
DEFINING THE APP
Fleshing Out the App
Before we started fleshing out our application, we created a development plan that served as a guideline for deadlines, tasks, and goals for individual members and the team as a whole. We used this as a guideline to help us keep track of what was completed vs. what required completion.
Before we started coding, we revisited the heuristics evaluations our classmates identified for our first prototype and created a concrete list on how we can improve these issues.
For example,
Before we started fleshing out our application, we created a development plan that served as a guideline for deadlines, tasks, and goals for individual members and the team as a whole. We used this as a guideline to help us keep track of what was completed vs. what required completion.
Before we started coding, we revisited the heuristics evaluations our classmates identified for our first prototype and created a concrete list on how we can improve these issues.
For example,
“Consistency and Standards"
Feedback: Checkmarks on main list look like bullet points.
The radio buttons on our paper prototype ended up resembling bullet points which caused confusion. We knew that as we started to implement our application, the radio buttons would appear clearer to the users.
"Error Prevention"
Feedback: “Add” button under suggested events list looks like a checkmark.
When designing the prototype, we did not consider the importance of button locations. But after the heuristic evaluations, we discovered that placement can immediately confuse a user. Our evaluators agreed that the buttons that add or delete the suggested task look like checkmarks, which is commonly seen in a task list. To prevent confusion and unwanted actions, we changed the placement as well as the format of the button. We installed an “accept” and “decline” button. The buttons were under the information of the task rather than having an “add” button on the left and a “delete” button on the right. The reason why we decided to have the buttons below the text content was for the visibility of the buttons to avoid any misunderstandings.
Feedback: Checkmarks on main list look like bullet points.
The radio buttons on our paper prototype ended up resembling bullet points which caused confusion. We knew that as we started to implement our application, the radio buttons would appear clearer to the users.
"Error Prevention"
Feedback: “Add” button under suggested events list looks like a checkmark.
When designing the prototype, we did not consider the importance of button locations. But after the heuristic evaluations, we discovered that placement can immediately confuse a user. Our evaluators agreed that the buttons that add or delete the suggested task look like checkmarks, which is commonly seen in a task list. To prevent confusion and unwanted actions, we changed the placement as well as the format of the button. We installed an “accept” and “decline” button. The buttons were under the information of the task rather than having an “add” button on the left and a “delete” button on the right. The reason why we decided to have the buttons below the text content was for the visibility of the buttons to avoid any misunderstandings.
Once we finalized and implemented our design decisions, we sought volunteers to interact with our prototype. We assigned volunteers a series of actions to perform, such as registering with a valid UCSD email and password, enrolling in classes, adding a task, etc. Through these various activities, we aimed to understand the common patterns in our users’ behaviors. Some things we looked out for were:
- Does the user struggle with proceeding prior to adding classes or tasks?
- How often does the user return to the main homepage?
- Which features are least used by the user?
- How does the user interact with the navigation bar?
- Did the user notice the confirmation feedback?
|
|
|
After conducting multiple user testings, we gathered issues that we noticed and prepared the respective solutions in the following list:
- Need for better feedback on the users’ actions. The initial confirmation feedback for our app was quick yet too subtle, which prevented users from affirming if they have added a task or not. After our corrections were made, the app redirected them to the homepage with a bigger confirmation message after a task was added. The existing information was also cleared automatically thereafter.
- Inconsistency in deleting. When a user deletes a class from his or her planner, all related tasks should be deleted from the planner to reduce unnecessary junk. Also, we implemented a warning confirmation that asked students to reaffirm their wish to delete the class.
- Populated planner. We collected the final dates for registering from TritonLink so when students add their classes, they receive immediate notifications to either add or decline tasks and avoid consequences of failing to do so on time.
- Cluttered shared tasks. The task page lacked organization so the tasks were randomly scattered with no sense of hierarchy. To fix this issue, we categorized the task page by classes so it was more intuitive when the users interacted with the task page.
- Vague signal in the task detail page. We added an arrow at the end of every task block so the users can be redirected to the task detail page after tapping on the task icon.
- This task detail page included the details such as the number of users who endorsed a particular task, an editing function, and a “delete” task.
A/B Testing
From the feedback we received from our user testings, we decided to test whether or not we should create the entire task row or activate the radio button. If we made the whole block toggle-able, would it result to accidental actions?
We randomly assigned each user into either group A or group B. Group A enabled users to check off tasks by clicking anywhere and Group B limited users to checking off tasks by only tapping onto the circle on the left of each task bar. By looking at the data, we discovered that having the whole block as an active button created confusion.
So when we observed this common behavior among our users, we concluded that they were confused by this feature. There was no visible feedback when the users checked off their tasks so we decided to create a strikethrough animation in order for users to know that checking off a task means “completed”.
From the feedback we received from our user testings, we decided to test whether or not we should create the entire task row or activate the radio button. If we made the whole block toggle-able, would it result to accidental actions?
We randomly assigned each user into either group A or group B. Group A enabled users to check off tasks by clicking anywhere and Group B limited users to checking off tasks by only tapping onto the circle on the left of each task bar. By looking at the data, we discovered that having the whole block as an active button created confusion.
- Activating the block removed the task instead of navigating the user back to the task detail page.
- Users assumed that instead of tapping on the circle for completion, they had to tap the whole bar.
So when we observed this common behavior among our users, we concluded that they were confused by this feature. There was no visible feedback when the users checked off their tasks so we decided to create a strikethrough animation in order for users to know that checking off a task means “completed”.
Additional Design Changes
- We realized how some assignments, exams, and labs are time-sensitive. We decided to allow users to input time when creating tasks.
- Because our delete task feature was written as text, it was frequently overlooked at. We implemented a button so students know deleting tasks was available.
- For on boarding users, we populated tasks like "add your classes in settings" and "accept and decline tasks in the shared tab" on their homepage. These goals acted as a guidance and introduction for our app.
- We allowed users to search either the course or professor when adding their classes.
FINAL DESIGN
|
|
|
|
|
Conclusions
Reflection:
- The importance in articulating design decisions. No one knows your design process except you and your team.
- Ask open-ended questions. We should not confine our testers to yes or no questions.
- Understand why users want a particular feature.
- Feedback is inspirational.