recap: flow by halo
Overview
Flow is a high-fidelity prototype of an app that I designed in my Usability & Information Architecture class at UC San Diego. In this class, we were divided into teams of 8. My title was Technology Implementation, but I was greatly involved throughout the entire design process, contributing in research, personas/storyboards, ideation, wireframing, and user testing.
Problem Statement
How might we encourage accountability and equal work among a group?
After long discussions, we realized that as college students, a lot of us tend to work in a group project at least once a quarter. We all had experience with uneven work being done. All of us conducted a Google survey using our social media with around 50 college students and found that about 80% complained that they did most of the work in groups. I found that not only did these college students do most of the work, they also worried if their teammates would do any of the work. As a result, we realized accountability and equal work were issues we needed to address with Flow.
Design Process
Main Goals
Our group wanted to create an app that targeted group work management, whether that be in the form of student group projects or business team’s tasks. Our objective was to make tedious and stressful group collaboration a thing of the past. From our discussions, we decided on 3 main goals to focus on in creating Flow:
- Accountability — Establish trust and individual responsibility within a group.
- Equal Work — Fair work loads among teammates.
- Collaboration — Amazing ideas stem from group collaboration.
Personas & Storyboards
After figuring out our main goals for the project, we moved onto personas and storyboards. One of the things I wish we could have improved on with this class and project is more time to conduct actual user research. Besides our surveys conducted at the beginning of the project, personas and storyboards were mostly based off assumptions. Thankfully, we were constantly doing user testing in class which helped drive our decisions. With our personas, we wanted to show how our app adds value to different types of people and situations. Originally, we intended to target college students. However, our our users expanded to include project managers, wedding planners, and all types of people who need better organization in their lives. Here are some of our personas below:
Using our personas and user needs, we were able to decide on features, functionalities our app should have. For example, we decided to work on having a task weight. When creating a task, users can choose from low, medium, or high work load. Another feature we generated from our user needs is the visibility of project status. Also, we thought about how dividing equal work should be done. One way we addressed this was a feature where users can see how much work load each group member has done; in this way, users can assign tasks to people with less work load.
Competitive Analysis
One of the issues we faced during the early stages of the design process were:
How was our app different than competing apps?
Why should students feel compelled to use our app over others?
We decided that making the task manager collaborative was not enough to motivate accountability between users. In order to address this issue, we decided on adding a rating feature to each task. When creating a task, users would be able to rate the difficulty and this would result in the task weight. By rating the task, the app calculates the amount of work each user does in a group and displays the information at the bottom of the page. Users who had done less work would see their percentage of work done in relation to others in the group at the bottom of “Create Task” page. We hoped that this would result in those users feeling the social pressure to balance the spread.
Wireframing and User Testing
Using the information we have gathered, we began working on the task flow and the low-fidelity wireframes utilizing pen and paper. I like starting off with pen and paper first just to get all my ideas out. From low-fidelity wireframes we moved onto a higher resolution wireframes using Sketch and Modao. What I really enjoyed about this class was that all throughout the prototyping stage from the low-fidelity wireframes to the high-fidelity ones, we were constantly doing user testing. User testing really helped drive our decisions. We were able to validate/invalidate our solutions and iterate based off feedback. Below are some of the big issues we ran into through testing:
Navigation:
From our user testing we found that many users had trouble with navigation with our earlier iterations. We found that navigation might have been obvious to us as a team but not to others. We had to really put ourselves in our users’ perspectives, gain a better understanding of who we were designing for. Navigation and working on the flow of the app was one of our major issues throughout the entire project. We constantly iterated off feedback from our users, making sure the navigation and interaction of the app was easy and intuitive.
Another issue we found was making the navigation bar simple and intuitive while including all the projects the user is included in and also the messaging feature of the app. With the design above, we solved the issues of having a navigation bar and where to place the chat menu. We decided on having two separate icons in the top corners of the screen. One would be a dashboard with projects the user is part of while the other would deal with the chatroom with the project and the individual users. This solution eliminated users from having to keep scrolling down if all that information was put onto one side like in most mobile applications.
Homepage:
The homepage was another big issue we came across with this project. The conflict divided our group in half. One half wanted the home screen to display the overall tasks of the users and the other half wanted it to show the projects that users belonged to. I was for the projects side and we eventually got the other half of the group to agree for most of the quarter. I based this decision on our personas and user needs that we defined.
However, towards the end of user testing in the quarter, our group was still having heated discussions about the home screen so we decided to run an A/B test the next meeting with both home screens. The Project homepage supporters believed the design of the app should focus on the projects while the Task homepage supporters believed that the app should focus more on the individual user and the tasks he or her has.
After running the A/B testing, the results showed that users preferred the Overall Tasks homepage. However, after talking to the users after the testing, they also enjoyed the “friendliness” that the Project homepage offered. Based on this, we decided to keep the friendly welcome of the Projects home screen while replacing the Projects with Overall Tasks instead. Projects would now go into the dashboard navigation bar where the user can easily access it and switch between Project pages.
Progression of wireframes from early iterations to final screens on Sketch:
Conclusion
From this project, I learned a lot about making decisions without all the information given. I learned that we must rely on the information we do have (including our assumptions), use good judgment, and make a decision. However, the most important thing is that we validate our choices. If it’s invalidated, we iterate based off the feedback. This was also a great project in improving my wireframing skills. I gained a lot more experience in utilizing Sketch.
At the end of our project, I believe we were able to address our main goals and user needs:
For accountability and equal work — we achieved these two goals through push notifications, task weight, visualization of distribution of tasks and project status.
For collaboration — we achieved this goal through communication. We created a messaging feature where users can message the group as a whole or individually.
