ACADPLANNER
AN ACADEMIC PLANNING TOOL FOR STUDENTS
OVERVIEW
I'M AN ORIGINAL CATCHPHRASE
Context: AY20/21 Semester 1 CS3240 Interaction Design Team Project
​
Team: (Team 43) Oliver Cheok, Low Zhen Hao Jefferson, Ng Siu Hian, Jessica Phua Shu Xin
​
Roles: Product Designer, UI/UX Designer, Web Developer
​
Target users: NUS undergraduates from most faculties (excluding Dentistry, Medicine and Music as they generally have a fixed academic roadmap and do not require academic planning)
​
Outcomes: After a few rounds of prototyping and testing with users, we developed the solution as a mobile-responsive web application built in React (with Redux).
​
Try it out here: https://olivercheok.com/
When students create their academic plans, they not only need to decide which modules to take, but also an appropriate order in which to take them. This is currently a very labor-intensive process prone to user error. Plans may also be subject to change, making the process even more confusing.
​
This is why we designed Acadplanner, an academic planning tool for students to plan their modules in a user-friendly fashion.
THE PROCESS
.png)
USER RESEARCH
CONDUCTING THE USER STUDY
We conducted a user study to further understand the problem space and our target users. We aimed to find out more about how they currently carry out their academic planning, what they liked about it as well as existing painpoints.
Our user study was conducted in two phases.
Phase 1: Semi-structured interviews and Contextual inquiries
In view of COVID-19, we conducted 13 semi-structured interviews with participants over Zoom. Contextual inquiries were also conducted for participants who were also able to share their screen, where we observed how participants would plan their modules for a semester using their preferred tools (e.g. NUSMODS, Excel sheet).
We also delved into the rationale behind their actions.
Phase 2: Online survey
​
​
After consolidating the data from Phase 1, we conducted an online survey and obtained a total of 64 responses from year 1 to 4 students and from a range of faculties. Our survey questions were crafted based on the insights gained from the first phase of study, which was important as it helped us validate the assumptions we developed and generalise our findings from the interviews to a larger portion of our target user group.
OVERALL USER STUDY FINDINGS
We consolidated our user study results and found out more about why our target users plan their modules in advance, what they currently use for academic planning, what they liked and disliked about their current tools or systems. We also gained other insights that helped us to better understand our users' current practices.
ANALYSING USER STUDY DATA
After conducting the user study, we crafted personas and current use scenarios based on the insights gathered, as well as key potential features that our proposed solution would support and allow users to achieve their goals.
Personas
Scenarios
Key Potential Features
​
1. Plan modules in an intuitive manner (such as by dragging and dropping modules) and provide customisability.
​2. Keep track of modules that are completed and are required to be complete to fulfill degree requirements and graduate in time.
3. Input grades obtained for modules taken and calculate Cumulative Average Point (CAP) across various semesters.
4. Make contingency plans to allow users to consider multiple plans at once and account for unforeseen changes.
5. Make own plans public and take reference from plans made public by the community as well.
WIREFRAME PROTOTYPE
Based on the requirements and insights we consolidated from the user study, we each developed our individual wireframe prototype. Each prototype consists of the same basic set of features that would enable users to execute the key tasks described in the previous section. This allowed us to brainstorm and collectively come up with alternate designs and different workflows. Some prototypes also had additional small features that other prototypes did not include.
This meant that we could test each prototype with users and based on those results, combine the merits of each prototype into one final one.
PROTOTYPE A
.png)
PROTOTYPE B
PROTOTYPE C
PROTOTYPE D
.png)
EVALUATION ROUND 1
We then had each of our wireframe prototypes evaluated by a few of our peers within our module, who were also part of our target user group. We conducted this evaluation in two parts.
Part 1
Four of them tested each prototype where they were asked to complete a set of tasks. They were also encouraged to think aloud so that we could understand their thought processes, such as what made them click on a button or navigate to another screen. This also enabled us to find out why they had trouble with some tasks, which gave us ideas on how to fix these issues afterwards.
Part 2
After going through the tasks, we asked them for their opinions on the prototype to discover what they liked or disliked about it. This qualitative feedback would be useful for us in deciding on the parts of our prototype we should keep and combine into the final prototype and the parts that we could modify to better suit our users' needs.
After gathering all the evaluation feedback for each prototype, we determined and compiled a few significant features that our participants liked about each prototype as well as they felt could have been improved upon. These insights fell under four main categories: general, community plans, degree progress tracker and planning modules.
In our next step, we began to integrate these features into a React prototype.
REACT PROTOTYPE
​
We chose to build our prototype in React due to three primary reasons.
​
1. Drag and drop functionality
We wanted to implement a drag and drop functionality into our prototype as we felt it was a crucial part of making academic planning simpler and more intuitive. However, after having worked with Figma, we realised that there was no clear way to illustrate a smooth drag and drop functionality in Figma.
​
2. Maintain state
It could help maintain state within each page as well as across various pages, such as when adding modules and creating new plans. This is especially important for our plans feature and degree progress tracker as the degree tracker is quite dependent on the current plan that the user has.
​
3. More advanced and dynamic search function
Building the prototype in React also allows us to create a more advanced search feature for the community plans, such as for sorting and filtering the search results with various options.
​
As such, our team, at the time, did not feel that prototyping tools such as Figma were sufficient enough to fully realise our visions for our final prototype and thus decided on developing a web application using React.
​
This video showcases the main features or general flow of our React prototype.
1. Landing Page and Plans Page
-
Start with landing page
-
Log in and see overview of plans
-
Create a new plan and add a name and description for the plan
-
Add a year and the module CS1010 from the dropdown menu
-
Create a new year (year 2) and add the module CS1231 to the semester under year 2
-
Drag and drop the module CS1231 from year 2 to year 1
2. Degree Progress Tracker
-
View degree progress and calculate Cumulative Average Point (CAP) across multiple semesters
-
Choose which semesters to include in calculating CAP
-
All university level requirements are cleared
-
Under unrestricted electives, 4 Modular Credits of modules are needed to complete this requirement
-
Add the module UEM8000 to academic plan directly from this degree tracker page
-
Choose a semester to add this module to, in the modal pop-up
3. Community Plans
-
Search for Computer Science plans and start to type in 'computer science' to show plans with only 'computer science' in the title
-
Sort the results by their titles, newest first or oldest first
-
Filter results based on certain categories such as degree type, faculties and overseas programmes
4. Profile
-
View profile page
EVALUATION 2
After spending some time developing the React prototype, we managed to recruit only 4 users within our circle of friends due to time constraints and our target users' busy schedules towards the end of the semester.
Similar to our first round of evaluation, we asked participants to complete a list of tasks on our prototype. We encouraged them to think aloud so that we can understand their thought processes when carrying out the tasks.
At the end, we asked them some open-ended questions. This allowed us to gain more in-depth feedback regarding our prototype in which we could use to make final adjustments to our prototype.
After the evaluation, we consolidated the feedback from our users that were more commonly brought up or were more significant.
.png)
Based on the critical feedback we obtained from this round of evaluation, we proceeded to make final adjustments to our prototype.
FINAL REACT PROTOTYPE
We took into consideration feedback from the previous round of evaluation and improved upon our React prototype by incorporating it in the prototype, such as:
​
Under Planning Modules:
1. Adding a dots grid icon to the module to indicate that the module can be dragged and dropped and where users can click on to do so.
2. Adding a trash icon to delete the module.
3. Adding a toggle button to easily make a plan public or private.
​
Under Degree Progress Tracker:
1. Changing dropdown menu to a multi-select dropdown menu with clear indication that users can select more than one semesters.
​
Under Community Plans:
1. Adding more filtering options for residential programmes, such as UTown College Programme and University Scholars Programme
2. Allowing comments posted to be shown in the comments section immediately
​
​
Planning Modules
(Turn on video captions)
Degree Progress Tracker
(Turn on video captions)
Community Plans and Profile Page
(Turn on video captions)
REFLECTION
Through this user-centered interaction design process, our group has definitely learnt a lot about designing with the users in mind and how we can achieve a product that would solve issues that users face in the real world.
​
Due to the time constraints and a lack of manpower, we regretted that we did not manage to include some of the features that our target users found to be useful in our final prototype. This could also have been attributed to a lack of prioritisation of features on our part during the prototyping process. In the real world context, developers and designers may also need to think critically about the functionalities to implement due to similar and other constraints such as budget, or decisions made by stakeholders.
​
We have come to realise that as developers ourselves, we typically do not take into account users' needs, goals and motivations when building products as we are more focused on the product itself than users' requirements. This means that UI/UX designers are even more vital in product teams to represent users and help developers understand users better. After all, the success of a product is often determined by how much value it provides to the users.