Students - Gowiem/Sisyphus GitHub Wiki
The survey questions & findings can be grouped into three topics: group make up, communication tools, and individual motivation. An analysis of how these group dynamics currently are like is important to understand first. Then, we go into recommendations (i.e. action items) based on these findings.
An understanding of how groups are currently like. Mainly group projects are...
-
short, between 2 - 4 weeks
-
uncommon, happens **1 - 3 times **per semester
-
made up of 3 - 4 people
What the above points mean is that while group projects occur, they are not regular parts of one's class. So, there is a smaller chance that students have established ways when it comes to managing group projects.(i.e. while students may have an established work flow for completing and managing the more common individual assignments, they most likely do not have a typical work flow for group assignments.) This also means there is opportunity to establish a common work flow for groups, as long as that work flow adds more value to the students in relation to their effort to use a new process.
Also, since groups have 3 - 4 people, this means communication during a project would typically happen in a close setting (i.e. one-to-one communications will occur more commonly than one-to-many, large group discussions when it comes to figuring out smaller details – i.e. after the project has started). When the project starts, it's expected to begin in an "all members present" group meeting. But once the project is on-going, these "all members present" meetings will be harder to coordinate and less relevant to certain tasks which need only 2 members, for example.
-
Make goals / due dates explicit
- because projects are short, students (who are not used to time management) need to be reminded regularly of their quickly approaching deadlines
-
Make the tool quick to set up and allow students to use it right away (i.e. don't let the tool itself get in the way of their class assignment)
- registering for an account should be as automated as possible (i.e. pulling existing student info. from Blackboard is preferred if possible)
- use interactions commonly used (and thus understood by most)
- DON'T use uncommon, abstract interactions like Trello's card system - cards are another level of abstraction away from tasks and thus many students will need an explanation of them (which takes unnecessary time/effort)
-
Initiating communication between members should be low effort
- especially when one member only needs to contact another member. (i.e. how can you prevent a large email thread where certain discussions are only relevant to some, but not all, of the members?)
Source:
With these quick projects, straight-forward communication is very important to meet fast approaching deadlines. Here's how students currently communicate and manage their group projects:
-
Students use their school email – most likely for everything related to the project: to coordinate meetings, discuss, and assign tasks
-
Students prefer **face-to-face meetings
**
- Students just memorize or use their **notebook **to keep track of their tasks
In short, students are using quick, low effort ways to get their assignments done: face-to-face meetings are the fastest way to work out logistics for their short projects (since waiting on email responses take time) – and using pen & paper are the fastest way for individual students to keep track of their own tasks. This is most likely because of the short timeframe of their deadlines – using a tool with a long set-up and maintenance effort (like maintaining and organizing cards in Trello) will most likely be rejected by students.
-
Task set-up should be quick
- remember students are used to quickly writing their tasks in their planners (or simply remembering what they need to do), so setting up tasks should take as few steps (i.e. clicks) as possible
-
Tool maintenance should be as minimal as possible or feel non-existent
- maintaining the tool itself (e.g. moving and organizing cards in Trello) is just added effort and another assignment on top of their projects assignments – students will most likely neglect tool maintenance in order to simply complete their actual project
- if maintenance is needed, find a way to make it a part of the assignment turn-in
-
Make meetings easy to coordinate – whether that's in person or in a virtual chat room
-
Take advantage of Google Drive – students are already using it
Source:
What motivates an individual during these projects? It turns out, students care about the journey (i.e. the process), not the destination (i.e the grade).
-
Students really care about fairness– they strongly feel members need to do equal amounts of work, despite the final grade
-
Students mainly worry aboutpartners not doing their work
- this is unique to academic, student group dynamics – in an industry, work setting, employees have much more positive and negative consequences to be responsible for their work – and students in these short, group settings do not
-
Students care about quick communication, namely face-to-face meetings
-
Allow students to quickly and easily coordinate meetings
- arranging meetings in email threads are highly inefficient and time consuming, so refer to tools like Doodleto see how meetings could be arranged quickly
- for these short group projects, meetings only need two things: time & location
- look at how meetings could be integrated with Sisyphus's existing tasks (i.e could a meeting just be a specially marked task?)
-
Look into how tasks are distributed in the beginning of the project (i.e. get to the root cause of unequal work distribution)
- remember to prevent more "type-A and extroverted" personalities to take over work assigning – think of more objective and democratic ways to give out tasks (e.g. like how the decision matrix in the beginning of our Capstone was used to determine our Capstone project, Sisyphus)
Source:
(Note – the "Earning a good grade" in the real survey has 1 input – this is from us testing the survey to see if the zero output was a bug. We confirmed the zero is real – i.e. not a single student checked it off. Unfortunately, we were unable to delete our test input. The image below represents the actual data, without our test input.)
Some highlighted quotes taken from the survey:
-
It's hard to develop trust in a short amount of time with your group members.
-
I dislike group projects, I just pick a segment and work on that.
-
if the tool makes** communication and dividing the work** more effective, that would be nice.
-
Even though group projects are chaotic at first, I feel like it organically falls in order after a while. In moments of confusion, I've noticed that a person usually assumes the role of the leader and organizes everything. We have to take into account not everyone is always as interested in the project as the rest of their group.
-
It would be good to find a way to talk and share information without everyone having to be in the same room.
-
...having an app that tracks the actual work done by each group member is an extremely interesting idea- particularly, if the app information was viewable by a professor. The people who actually do work will feel relieved and validated, and hopefully the "hitchhikers" will be forced to do work or suffer a lower grade than their partners. This is SUCH a good idea. Please make it a reality.
-
On my last major group project, we used Google Docs and email as our main collaboration tools. It worked well, but it wasn't centralized. I mean it wasn't a single platform that tied it together. I used gmail so in a way, it was, but that wasn't the case for everyone. Our contact information was just a document in the Docs folder. There was no means of tracking progress.
A persona is a representation of a user group and the group's typical behavior (as determined by empirical data). Using a persona is a short-cut in a sense – when designing and brainstorming features, it helps to use a persona to quickly empathize with the users. E.g. "Will feature x benefit Sam?"
Because we collected 194 student responses (as of Dec 2013), below is a student persona who represents the averages from the responses.
This persona is to be used to quickly remember who we are designing our tool for – because it's easier toempathize with a person than a list of graphs/data. During design sprints, it's best to ask "How does this benefit Sam? Would Sam use this in his workflow? etc". This helps to prevent a designer's own preference and ego to effect the designs.



