# TUG: Team-Building Interface for Remote Learning

## Problem Statement
Many KAIST students are having difficulties finding credible and suitable team members for group projects since the remote environment under pandemic does not give students communal places to get to know each other to successfully decide who are appropriate to build a team with.

## Tasks
- Task 1: Discover new people who suits desired abilities of the team
- Task 2: Interact with other students without feeling pressure to form a satisfying team
- Task 3: Score teammates at the end of the project to acknowledge their efforts

## Prototype
### Link
https://www.figma.com/proto/SrG2Q4StPcFci6gNT8pF1g/Team-TUG?node-id=240%3A1416&scaling=scale-down&page-id=86%3A1121&starting-point-node-id=240%3A1416

### Prototyping tool

#### Our Choice of Prototyping Tool: Figma

#### Reason for Choice
1. Ease of collaboration
- The main reason in choosing Figma as our prototyping tool was because it well supports real-time collaboration between teammates. Just like Google Docs, we can watch what other teammates are currently working with and leave comments on other people's work. Since our team always worked online, we valued these collaboration features a lot and hence chose Figma as our prototyping tool.
- Also, the fact that we can make several pages at one document captured our team's interest. This feature allowed us to easily divide roles between teammates and merge each other's work at a later stage. Since we were working online, we agreed that this way of collaboration would be most effective and hence found this feature very helpful.

2. Ease of design
- One of the hardship our group faced during DP3 was that only one of our teammates had experience in using any prototyping tool. Therefore, our main consideration in choosing the prototyping tool was whether it is easy to learn to use it or not. In that sense, Figma was considered as the most appropriate tool since the design process in Figma is very intuitive. For instance, transition between two pages can be made through a simple mouse drag. Also, adding shapes or animations were similar to those in PPT (or Google Slides), which everyone had experience in using it. This helped us to learn the features of Figma very quickly, and hence we chosed Figma as our prototyping tool for DP3.

3. Intuitive for user testing
- Many features of Figma helps the user testing to be done effectively. For instance, we can observe how the participant is interacting with the prototype in real-time. This allowed us to easily observe and write the usabilities problem down. It also helped the users to feel less pressure during the testing session. Moreover, since Figma has feature where it highlights parts that can be interacted if they click the wrong section. This also helped users to not feel frustrated when they make mistakes during the testing but comfortable do the tasks.

4. Connection to Hi-fi prototype
- Also, the fact that we can get css code from the prototype was also very appealing. This feature would really help us when building the final hi-fi prototype for our project when we design the interface. Therefore, we chose Figma as our final choice for lo-fi prototyping.

#### What Worked Well
1. Effective collaboration
- As mentioned above, by using Figma, we could collaborate effectively. We also especially noticed that we could observe how the member interacted with the system created by other members to find the simple usability problems to fix the user testing. Moreover, we could use the comment function of Figma to write feedback and comments to collaborate and improve our prototype efficiently. Furthermore, when people are unsure about how to create some functions, they could directly refer to other people's work to learn by themselves as well. The intuitive design of Figma helped our team to achieve this. We constantly tested each other's work and left feedback to make constant improvements.

2. Division of task
- Our team members could effectively decide which parts to work on to divide the workload. Figma allowed us to create different pages so that each of us could individually work on creating one task and integrated to create the final interface at the end. This was effective since everyone could be responsible for some part of the interface so that we can focus on one job. It also helped us to have the united design at the end. Since one person worked on uniting different pages of Figma created by different members together, when there were some different designs, it could be edited so that the interface looks like one complete system.

#### What Didn't Work Well
1. Real-time interactions (chatting system)
- Our system required the real-time interactions between the participants through the chatting system. However, Figma mostly supported the front-end prototyping with only the simple interactions between the system and the user, not in between the users. Therefore, this limited us to show and portray how real interactions would happen. This also limited us to test the chatting function of our interface since we do not know how people would actually interact and what problems can be caused. We tried to let the user know what is going on by explaining what would happen and creating the automatic interactions to show how it might happen.

2. Building time limits
- This was the similar problem with the previous problem. Figma did not support some functions like building time limit for users to interact. Although this was a function of our interface, we could not accurately build the prototype. However, we tried our best to create it by automating the interaction after certain amount of time to give the user feeling of how our interface would look like.

3. Confusing interactions
- This was a problem that we found out when we tried to add every solution ideas together to finalize our prototype. Sometimes there were so many interactions occuring at one layer or web-like linked slides which was hard to be understood by other members who did not create the solution. This made us to struggle since we had to spend a long time to fix the mistakes if we accidently deleted an interaction or need to edit small parts of the interface. We tried to solve this problem by naming each layer so that everyone can get a grasp of what the layer is doing.

### Design choices
We had to make some design choices about what we would choose to not implement. These are the choices that we made in this prototype.
1. Too much freedom in interactions
- We realized that if we implement the prototype to give freedom to the users in interactions, it might cause some problems and confusion. This is because feature like logging out or back to homepage might cause some safety issues where user get lost in the interface and keep try to do the task over and over. These interactions would rather encourage users to make a mistake and make them to start from the beginning, which might result in emotional pressure. Therefore, we did not implement them so that the users can focus on achieving the main tasks.

2. Common features
- We did not implement the common features like about page or settings page. These functions are already well-known to most of the users which does not give them any new information. We decided not to implement these so that users can focus more on achieving main tasks which we want to observe more into.

3. Hard-coded data for quizzes/profiles
- We only implemented hard-coded data for user input fields, especially in answering quizzes and creating profiles. This was done because the algorithms here do not affect users from achieving the tasks from this low-fi prototype. We created the prototype so that the data feels like the actual algorithm grouping them by giving realistic situations to reduce awkwardness.

4. Features that are not supported by Figma
- As mentioned beforehand, we could not implement functions which require external program and not supported by Figma itself. We tried to mimic its feature doing our best by using automated interactions to help users to feel realistic about the interface.

5. Unnecessary details
- There were many areas where we could provide some details about the interface. However, we thought that those details are unnecessary for the users to achieve their high-level tasks. We also thought implementing very detailed version of the interface would make the user to comment more about the design not the tasks and usability problems.

### Representative screenshots

#### 1) User Profiles
When signing up in the platform, users are ask to write down 3 abilities tags and 2 interesting facts tags. Abilities tag highlights the technical skills that a user can contribute. On the other hand, intersting facts tags highlights interests or hobbies that can later on be used as common ground in starting a conversation.

This feature will be used and displayed later on in the anonymous team formation.

<figure>
<figcaption> Creating User Profiles</figcaption>
<img src="https://i.imgur.com/JezyU78.png" title="User Profile Placeholder" width="80%" height="80%">
</figure>

#### 2) Quizzes for User Discovery

For task 1, we proposed a quiz design to pool users into groups. In this stage, users will answer different questions including values, technical skill preference, and common ground. Based on the answers, students would be grouped into teams where they will be able to interact with each other.

<figure>
<figcaption>Quiz Time</figcaption>
<img src="https://i.imgur.com/FUWyMRU.png" title="Quiz Time" width="80%" height="80%">
</figure>

#### 3) Anonymous Team Formation

For task 2, we designed the users to have anonymous interactions in order to reduce social pressure in forming a team.

After the quiz, users will be grouped based on their profile and quiz answers. A user interface with a chatting function, along with group members, popular tags and unique tags will be displayed. Members will be shown anonymously with temporary user pseudonames.

Clicking the chat message or tag will show the corresponding tag, user, and chat details. This is to help users assess whether they have a well-balanced team needed for the project.

<figure>
<figcaption>Chat with People - tag</figcaption>
<img src="https://i.imgur.com/g7u0VXz.png" title="Chat with People-tag" width="80%" height="80%">
</figure>

Clicking the user will redirect to a window that shows 2 tabs - tags and contribution. In the tags tab, abilities and interesting fact tags of the clicked user are shown.

<figure>
<figcaption>Chat with People - contribution</figcaption>
<img src="https://i.imgur.com/cnP27Xw.png" title="Chat with People-contribution" width="80%" height="80%">
</figure>

The Contribution tab shows a histogram of the contribution points of a user over different periods of time. The black colored graph shows the contribution of the user and the gray colored graph behind shows the average contribution of the past teammates. A comparison of self and teammate points was chosen to help visualize the relative contribution of other teammates.

<figure>
<figcaption>Vote for team formation</figcaption>
<img src="https://i.imgur.com/u2AGh7V.png" title="Vote for team formation" width="80%" height="80%">
</figure>

After the time limit passes, as shown on the top of the chatting system, the conversation automatically finishes. Based on the conversation that the team had in the chatting room or the observation of the tags and contribution of members, each student can make the decision to accept or reject the team and find another one. When more than half of the teammates agrees to accept, the team is finalized and the contact information is revealed. However, if the team is rejected, they go to another round of quiz and meet new students. This process continues until the limited number of rounds reaches its end.

#### 4)Scoring System

When a team is formed, users can navigate to the Active Teams tab to see the contact details of their teammates. Pressing the 'Teamwork Finished' redirects users to the Scoring Contributions page.

<figure>
<figcaption>Contact Details</figcaption>
<img src="https://i.imgur.com/DyrPdGp.png" title="Contact Details" width="80%" height="80%">
</figure>

<figure>
<figcaption>Scoring Contribution</figcaption>
<img src="https://i.imgur.com/vOMvmsZ.png" title="Scoring Contribution" width="80%" height="80%">
</figure>

For task 3, we have designed the system wherein users have the ability to score their teammates at the end of the project. This is to reward or flag people who did or didn't do well in the project. Through the points system, we aim to motivate people to do their best and reduce the chances of having free riders in group projects.

We designed the system such that users can distribute 100 points to their teammates. The number of points was designed to give users freedom of distributing points even in large number of group members.

### Instructions

#### Notes before running our prototype
* Before using our prototype, please check if the options on the right top corner is selected as “scale down to fit”.
* When running our prototype, please be aware that randomly clicking some parts might result in irreversible result. This means that you might skip or not be able to see some parts of the interface.
* Our prototype flows in the order of task from #1, #2 to #3.

#### Introduction
1. Sign in to our website.
2. Create your profile. Write the tags that can explain yourself to other students.
3. Join the class. Search for your classroom and click the ‘join’ button if you found your class.
4. You can start a team-building session for each class you join. You can click the ‘start’ button at the right side of each class to start the team-building session for the opened class.
5. If you click the 'start’ button, the first round of the quiz will start.

#### Solution 1: Quiz Time
1. Answer each question. Among two or three choices for each question, you can select one of them. If you click one, the clicked choice will be changed to black color.
2. If the question is very important indicator for you to find a team member, then check the square box at the right side of the question.
3. The yellow bar at the top shows your time limit of the given quiz.
4. After answering two questions at the first quiz page, click the ‘next’ button at the right-bottom. You cannot go to the next page until you answer every question on the current page. The ‘next’ button would appear only when you answered all questions in that page.
5. If you finished answering all questions in the quiz, the ‘done’ button would appear on the right-bottom. Click the ‘done’ button to finish the quiz.

#### Solution 2: Chat with People
1. After finishing the quiz, you are located into an anonymous chat room with classmates who submitted similar answers with you.
2. For a limited time (visualized as yellow bar), you and others can look over hashtags of personal traits which are collected from quizzes and user profiles. In this scenario, find people (1) who can code web or (2) who are graduate students. If you click the tag, the owners of that tag will be shown as black profile image.
3. For more details, you can click each profile to get the individual information. There would be 2 tabs, 'Tags' tab and 'Contribution' tab.
4. Click the 'SEND' button below to send a message and get to know them. The 'Chat with People' page will be over after time runs out and a pop-up window will appear where you can choose whether or not to make a team with these members.
5. If you click 'Yes' and more than half of the teammates agreed, your team will be decided. You can leave the team-building session and check the contact information at 'Active teams' tab.
6. If you click 'Try Again', you will go to the next round of quiz until the rounds are over.

#### Solution 3: Scoring Contribution
1. Pick the class through clicking the right arrow below the name of the class.
2. You will be able to see the contact details of your teammates wherein you can contact each other through email.
3. Once the team project is finished, clicking the teamwork finished button redirects you to the rating page.
4. In the rating page, you would need to distribute 100 points to your teammates according to their contribution.
5. Pressing 'done' button will automatically archive the team details. You can revisit the team’s details and distributed points in the 'past teams' tab.

## Observations
We recruited 5 participants from a local university with age of 20-27. The majority of participants (N=4) had prior team building experience in remote environments. Participants ran through our instructions to achieve the given three tasks minding the purpose of our solutions. We ran a brief interview asking qualitative feedback for each solution.

### Total number of participants: 5

- P1: Undergraduate Student (3rd grade) at Industrial Design Department
- Previous Experience:
- Has experience in online team building.
- Mostly the professor built the team by himself/herself after taking a survey regarding topics of interest.

- P2: Graduate Student at Bio and Brain Engineering
- Previous Experience:
- Has experience in online team building (once).
- Professor asked students to freely team up with each other. This participant failed to find team members, and hence did the project alone.

- P3: Ph.D. Student at School of Computing
- Previous Experience:
- Have no experience in online team building.

- P4: Graduate Student at Electrical Engineering
- Previous Experience:
- Has experience in online team building.
- Professor and TAs randomly assigned teams after taking a survey regarding topics of interest.

- P5: Undergraduate Student (4th grade) at School of Computing
- Previous Experience:
- Has a lot of experience in online team building (at least 5).
- Some subjects asked students to freely team up, and some subjects provided random team members.

### Usability Problems (Sorted by Priority)
We prioritized the usability problems based on how much it hinders the users from achieving the three tasks given.

#### Task 1:
- The choices given for each questions did not include the exact answer that I wanted to give. (P2) (Criticality: High)
- Future Plans: Use questions that can be answerd in a 5-point likert scale. This can quantify the answers and cover variety of range while maintaining the accuracy rather than giving qualitative options.
- If the quizzes change after each round, there might be occasions where there are no questions regarding the values that I consider when building teams. (P3) (Criticality: High)
- Future Plans: Instead of giving quizzes at the start of each rounds, provide full list of existing questions at the first round only, which can be iteratively used throughout all rounds.
- Check box and its description on the top right is too small and hard to notice. (P1, P5) (Criticality: Low)
- Future Plans: Provide a simple tutorial at the start of the quiz so that the users can learn the presence of the check box.
- Solving quizzes each round is quite frustrating. (P4) (Criticality: Low)
- Future Plans: Same solution above (from the second usability problem) would solve the issue.

#### Task 2:
- The conversation starter of 'ask questions about their dream team' is not narrow enough to start a meaningful conversation about team building. (P1, P5) (Criticality: High)
- Future Plans: Rather than providing a conversation starter, we might give simple and fun team tasks to each teams so that people can preview teamwork. (i.e. design a new fantasical animal) This would enable all teammates to participate in the discussion, while not having the pressure of coming up for a new topic.
- It was difficult to distinguish the members, since the icons used were the same. (P1) (Criticality: Medium)
- Future Plans: Instead of using same icons, we would use random images of avatars or characters, or even simple colors to help them distinguish each other. (Think about anonymous animals used in Google Docs)
- Hard to distinguish different sections in the chatting page. Chatting window is also too small compared to other elements. (P1, P2, P5) (Criticality: Low)
- Future Plans: We would improve the design of the chatting interface by adding more labels, adding lines that separates each sections, enlarging the chatting interface, etc.

#### Task 3:
- I would forget to give out credits to other teammates when the team project finishes after a some period of time. (P5) (Criticality: High)
- Future Plans: We would attempt to solve this problem by creating task managing service to let users use our system continuously throughout their team projects. When users constantly visit our website throughout the team project, users would constantly be aware of the presence of the rating system, hence reducing the chance of forgetting it.
- Credits can be biased when there are friends in the team, who share credits within themselves only. (P3) (Criticality: High)
- Future Plans: We already planned to tackle this problem by finding the user who constantly reports an anomaly of the credits distribution. This user can be internally flagged within the system as unreliable to have disadvatage in team matching.
- It is difficult to understand the chart regarding past contribution. For instance, what does the label teammate mean? Is it average or sum of previous teammates' credits? (P5) (Criticality: Medium)
- Future Plans: Instead of only putting words "teammate", we can put the pseudonym and display the detailed distribution of credits to make it clear that it's the user's points plotted across different projects.
- It was hard to assess someone's contribution only with numbers. There may be situations where someone participated well, but was always late for the meetings. (P1) (Criticality: Medium)
- Future Plans: Guided rubric such as punctuality, quality of contribution, willingness to help, can be shown to further help assess teammates.