Project management for college students,
by college students
An independent study at the Human-Computer Interaction Institute
at Carnegie Mellon University
the Team
Felicia Wang
{ Product Management | UX Research | UX Design | Documentation } feliciawang.com
Felicia is a senior at Carnegie Mellon University double majoring in Human-Computer Interaction and Business Administration. On campus, she is a captain on the varsity swim team and serves as Head Teaching Assistant for course 15110 Principles of Computing. She loves bringing new products to life and helping students grow their interests in the world of technology. Felicia is originally from sunny Southern California and for fun enjoys surfing, skiing, cooking, and traveling with family and friends.
Gail Wilson
{ Product Management | UX Research | UX Design | Tech Implementation }
Gail is a senior at Carnegie Mellon University majoring in Computer Science with a minor in Human-Computer Interaction. On campus Gail has served as a student representative on the University Review Committee and student Senate, been an Orientation Leader, and TAed for 15150 Functional Programming. Gail loves taking advantage of the opportunities and passions that come her way whether, it be working on cool projects outside of class, studying abroad, or choreographing hip hop performances.
Jeff Bigham
{ HCI Independent Study Advisor }
cs.cmu.edu/~jbigham
Jeff is an Associate Professor at Carnegie Mellon University in the School of Computer Science and the Human-Computer Interaction Institute. On campus he teaches 05320 Social Web in which Felicia and Gail were students in Fall 2015.
the Strategy
The idea of Loop was first conceived as the topic of a final project at Carnegie Mellon University in course 05320 Social Web taught by Professor Jeff Bigham. In the context of a class which discussed the impact of social media, online coordination and crowdsourcing on our modern society, we saw the opportunity to create a project management environment specifically catered toward college students which takes advantage of different facets of the social web. We aim to create an experience that was distinct from the many existing project management tools which cater more toward corporate use cases such as Slack and Asana by understanding how undergraduate students instinctively leverage the web .

The original team who prototyped Loop in its first stage as the deliverable for Social Web's final project consisted of five undergraduate Carnegie Mellon students: Lauren Goldstein, Casey Fischer, Evi Bernitsas, Gail Wilson and Felicia Wang. Since January 2016, Loop began its next stage as an independent study within CMU's Human-Computer Interaction Institute driven by Gail and Felicia and advised by Jeff. Our scope for this project in the Spring 2016 semester focuses on the bulletin (later extended to Trello integration), messaging and calendar systems for which we aim to deliver a complete UX design in the form of user tested mockups and a fully implemented front-end to demonstrate the concept and usability of the product.
the Research
Though we had done some research, competitive analysis and user testing in the first stage of Loop, we decided to approach the project from scratch beginning with our own initial research. We put together the following script and interviewed 10+ target users in an attempt to understand how college students use the social web in their daily routines and how we can leverage some of these features to facilitate collaboration in getting work done. Our participants were upperclassmen students in their junior and senior years of undergraduate at CMU. We attempted to find a variety of participants from as many areas of study as possible (computer science, business, design, engineering, natural sciences) but most participants were friends of ours.
After Gail and Felicia had both finished interviews, we discussed our findings and summarized our research results to a few key points.
Common responses...
Virtually nobody reported using PM specific software for school, even if they have heard of it/used it in industry. Those who have used it in the past do not even suggest it because they believe that their teammates will not know what it is. If a teammate does suggest it and others in the group do indeed know what it is, it is nearly always voted down because the majority believe that setup costs are too high. Many people commented that PM specific software seemed like overkill for what they were trying to accomplish at school. They do not believe they need all the features that often come with the software. PM software is, however, more commonly used in student organizations (Trello, Slack).
Interesting things that came up...
A chemical engineer and a biology and psychology who interviewed were both much less familiar with PM and collaboration software than other interviewees in Information Systems, HCI and Business. The bio/psych major said that they spend so much time together in required lab classes anyway she usually has live access to her teammates on a regular basis. The chemical engineer said that they do not have required lab time but that they create a teamworking environment that is similar. They study together in the same room, go off in separate corners to do their own work and talk to each other live if they need each other.
Implications for Design
Participants reported that some of the worst logistical parts of working a team include scheduling around diverse conflicts, remote communication, and lack of accountability. However, participants also most commonly cited Doodle Poll, GroupMe and Facebook Messaging as platforms that they currently use in their group work. This told us that students have indeed been attempting to use software to address their most common pain points, but that these existing solutions are not satisfactory for this context. Based on this knowledge, we decided to begin our first iteration of design with a focus on the messaging and calendar systems to tackle the most obvious problems immediately.
the Design
{ Messaging }
Designing a usable messaging system for Loop became a focus of our project as messaging and communication was identified as one of the most common pain points for our target users in our research phase. We observed that many existing solutions such as Facebook Messenger and GroupMe are currently being used by our users with varying success. Thus in our design, we aimed to create our own unique messaging experience that addresses the shortcommings of existing platforms while still maintaining the advantages and design literacy of commonly used messaging solutions.
Basic Layout & Active Conversations
In our first design iteration, we chose to display the messaging layout in its own ever-present section in a column on the right hand side of the page. Because messaging and communication were mentioned frequently as core aspects of teamwork by our interviewees, we designed the messaging system such that it was featured prominently and constantly accessible, independent of the other systems of Loop (Bulletin, Trello, Calendar). As can be seen below, the messaging section corresponds to the currently selected team on the left hand side of the page, consistent with the other systems. In the messaging section itself, conversations with members of the current team (with summaries of the latest message) occupy the top half of the layout while a messaging window displaying the selected convseration occupies the bottom half.
Add New Conversation
When we intially designed the interaction of adding a new conversation in the messaging section, we experimented with leveraging design literacy. The initial inspiration to use Gmail's floating "add message" button eventually lead to the rotating add and delete button that was included in our first design. The button would also float in the bottom right hand corner of the upper half of the messaging section as an "add message" button until it was clicked. At that point it would rotate and become a "delete message" button for the new message workflow which would be initiated in the messaging window below. The purple was chosen for the visual design of the button and the background for the new message workflow to denote their relationship.
Add Active Participant
In the new message workflow or during any point in an existing conversation, the user may begin typing names into the "active participants" text bar which would make suggestions of members within the given group. This interaction and visual feel again harkens back to inspiration from Google's Gmail design, attempting to leverage users' design literacy of frequently used software. For Loop, we definted a policy of active versus muted statuses for each conversation from each users perspective. To further explain, we decided that all messages within a group on Loop would be viewable by any member of the group. However, a user is only notified about messages in which he is an active participant. Any user has the ability to make any member of his group an active participant in any message, including himself. Our research showed us that separating topics into channels was a popular feature of Slack while being constantly bothered by irrelevant group messages on Facebook and GroupMe was a negative. Therefore, with this design we hoped to both preserve a positive feature and also allow more flexibility for users to cope with a pain point.
Like a Message
Another design literacy experiment we borrowed from one of GroupMe's most popular features was the ability to like individual messages to show approval or take attendance. GroupMe handles the liking messages interaction by providing a heart icon next to each message bubble which the user may tap. Continuing down the path of the design literacy exploration we've adopted for Loop's design, we decided to touch on Instagram's liking interaction which is to double tap a photo. In our case for Loop's messaging system, a user may double tap or double click a message bubble to like the message. The feedback will then appear as a heart icon within the message bubble inside of which the number denotes the people who have liked the conversation.
Muted Conversations
To further detail the handling of muted conversations which were discussed briefly before, conversations in which the user is active are displayed at full opacity at the top of the conversations scroll list in the upper half of the messaging section while muted conversations are displayed toward the bottom of the list at a lower opacity. Though they are muted, users are still able to view these conversations in the same way as active conversations and have the ability to unmute the conversation or add other group members as active participants.
{ Calendar }
Identified during our research stage as the second biggest problem faced by a majority of our users, the calendar and scheduling system became our second priority for Loop. This was also our most developed system in the previous iteration of Loop which we had done for our final project while taking Social Web. Because we already had a serviceable prototype which included code and design for the calendar, we were able to start light-weight user testing before undergoing a full design cycle for this system. However the mockups shown below are our final designs for the calendar system.
Scheduling Workflow
This was perhaps the most challenging interaction and workflow which we faced from a design perspective. Though the final visual design was not user tested and could be improved, we accomplished our main objective which was to reasonably allocate real estate within Loop's base layout and create a higher fidelity mockup of the workflow of actually scheduling an event among multiple members of a group with this tool. Another interesting fact to note which we believed contributed to the challenge of this design was that, unlike the messaging system, not many similar applications or web tools exist from which we could pull inspiration for interactions. On the flip side, our users also gave us relatively less useful feedback as compared to the messaging designs because they did not have many preexisting expectations and felt rather neutral about most spects. For this workflow, we again borrowed from Gmail's "add recipient" interaction in our handling of adding and deleting participants to the event. We also looked at the Sunrise calendar web and mobile app to help us wth the layout of the calendar view itself, though it of course looked rather similar to any other calendar layout.
the Code
Coming in March!