Omnipointment ("Omni" for short) was created in 2015 by Vinnesh Kannan and Brendan Batliner, two computer engineering students at the Illinois Institute of Technology (IIT). Frustrated by how difficult it was to coordinate meetings for group projects, they created Omni in order to help student leaders like themselves find a time when all of their teammates could meet.
Students loved how Omni took the hassle out of scheduling team meetings by letting them see exactly who was available for each time slot. The only problem was that students had a very low willingness to pay for a product like this. Universities, on the other hand, had expressed an interest in paying for Omni, but only if it solved some of the bigger issues associated with group projects. It was at this point that Vinnesh and Brendan came to me and my team with the following challenge:
Design a comprehensive group project solution that goes beyond scheduling to help students work together more effectively.
Rather than ask users directly what they thought they needed in order to work together more effectively, we asked them for detailed accounts of both positive and negative group project experiences. Once we started to hear the same types of stories over and over again, we began the process of synthesizing the data to gain a better understanding of why teams fail or succeed.
After laying out direct quotes from the interviews, we grouped similar data points together and labeled each column with what worked or failed in those cases. In the end, we identified five key strategies that had contributed to the success of group projects for all of our interview subjects in the past.
Get to know your teammates
Delegate effectively as a team
Set deadlines for each task
Hold each other accountable
Review each other's work
I then summarized these strategies as “needs” and used them to create a research-based user persona along with what we had learned about our user's larger life goals, frustrations, background, and personality characteristics.
At this point, we had identified more needs than we had time to solve for. To help us prioritize, I conducted a competitive analysis using these needs as points of comparison.
All of the competitors I looked at provided some way for users to set deadlines for each task, hold each other accountable, and review each other’s work. None of these competitors, however, helped users get to know their teammates nor did they provide strategies for effectively delegating work. After identifying this opportunity, we decided that our prototype should attempt to solve the following problem:
Students working in teams need a way to get to know their teammates in order to delegate the right task to the right person.
With a clearer understanding of the problem we had to solve, it was time for us to start thinking about how we were going to solve it. After brainstorming on paper, we quickly mocked up two low fidelity concepts to explore different ways of helping students figure out who should do what.
Before testing our concepts with users, I created a realistic scenario along with a mock assignment sheet that we gave to every test participant before each session.
You are a freshman in college. Today is your first day of computer science class and you have to do a group project with two other students whom you’ve never met. Please read the attached assignment from your professor, then use Omni to efficiently divide up the workload amongst yourselves.
By carefully designing our concept tests in this way, we were able to accurately compare the results of each testing session. Using this uniform set of quantitative and qualitative data, we pinpointed the exact ways in which each concept failed or succeeded.
4 of 7 users were able to break the project down into tasks in significantly less time when they had the assignment on screen for easy reference.
7 of 7 users appreciated how they could immediately know how long a task should take just by looking at.
5 of 7 users assigned an equal number of hours to each teammate and verbally indicated that sharing the workload equally is important.
7 of 7 users said they would only need a summary of their team’s strengths and weaknesses if it was relevant to the specific type of project they were working on.
5 of 7 users looked for a way to set a due date or reminder notification when creating or assigning tasks.
4 of 7 users expressed a desire to further organize tasks into groups and divide existing tasks into smaller subtasks.
Before building out any additional screens for our final prototype, we iterated on the screens we had already built to address the issues surrounding deadlines and task organization.
The issue of overly broad profiles, however, required more than just a redesign of existing wireframes. If what our users really needed was information that was specific to the project they were working on, we needed to understand the types of projects they could encounter. After reading through course catalogues from universities and online learning platforms like Udemy and Coursera, I created a comprehensive classification scheme for the types of projects college students might encounter.
Rather than try to build out content for all 20 of these project types, we focused on identifying only the skills that would be useful to know in the context of the computer science assignment we used during concept testing. We started by conducting an informal card sort where participants were asked to write down the skills they thought were relevant and organize them into labeled groups. I then took the results and created a list of applicable soft skills and hard skills to use as content in our final prototype.
Once we had our content mapped out, we started thinking about how our prototype was going to fit into the lives of our users as well the existing Omni product. After going back through our research, we saw that the several users had expressed preference for assigning tasks in-person. As the vision for our prototype began to shift from something students would use at home to something they would use together in the same room, we realized that we were creating a product for scheduling and running kick-off meetings. It was at this point that we created a high-level sitemap to use as the blueprints for building out our final prototype.
With the research and information architecture behind us, the time had come for us to bring everything together in the form of a fully functional prototype. Using Axure RP, my colleague and I were able to build out four fully interactive user flows in just two days.
For the final handoff, we annotated all of our wireframes with future recommendations as well the logic behind all of our design decisions. Knowing that our clients were going to code the product themselves, we also carefully documented the states, triggers, conditions, and outcomes of each interaction.
While our prototype was still in need of further testing and refinement, by the end of our three week sprint we had developed a promising new strategy for Omni as a whole. In addition to addressing a number of problems with group projects that universities would find compelling enough to warrant paying a subscription fee, we managed to carve out a unique corner of the extremely competitive project management space. Furthermore, we designed a tangible vision of what our strategy would look and feel like when translated onto the screen. In the end, Vinnesh and Brendan were excited to walk through the door we had opened for them and continue Omni's evolution from a promising scheduling app into a complete group project solution.