Martin Crowley
UX designer

The Story of OverlApp

A team-based mobile app design project with a business-focused approach.

Project Context

During the 'Mobile Application Design' module of my Master's thesis, we were challenged to come up with digital solution to a problem that University students commonly face.

My role in this project was that of Lead UX Designer. The final deliverable was a high fidelity prototype of sufficient fidelity to be handed off to a development team.

The Problem

College students find it hard to coordinate group project meetings.

We had difficulty finding a slot to arrange our own team meetings. What we came up with was a calendar-based planning app to help solve this problem. The project incorporated a blend of design practice and business strategy. Firstly, our team established that this was a viable product and secondly, we designed iteratively, guided by continual user testing. 

The Design Team

Martin (Me) - Team Lead / UX Designer

Sushmita - UX Designer

Zhiyuan - UX/UI Designer

Mayukh - UI Designer

Research & Analysis
Much was learned from the discourse recorded in group interviews

Much was learned from the discourse recorded in group interviews

User Interviews

We first needed to establish if other students had the same difficulties that we had. We also want to learn how other students coordinated meetings. To learn more, we conducted group interviews with students who were already engaged in projects together.

We learned that much effort is wasted in trying to coordinate meetings. Also, people not pulling their weight was a huge pain point.

Insights allowed us to set out some stipulations for future designs:

  • Facilitate transparent communication.

  • Promote even workload distribution.

  • Enforce accountability for "slackers".

"Quite often, people don't show up for group meetings. It would be helpful to know who, if anyone, will be there or if someone is running late"
Interviewee Statement
Considerations for the design of an app.

Considerations for the design of an app.

Is an App the Best Means?

We first need to establish if a web or native app was the best means to solve this problem.

We decided that an app was most suited for the following reasons:

  • An app allows the flexibility to send and receive notifications anywhere and any time.

  • GPS functionality could prove helpful to establish and navigate to a meeting place.

Market research.

Market research.

Feasibility Study

Next, we need to establish if this was a financially viable endeavour or not.

After some market research we discovered that, in Ireland alone, there are 150k college students, many of whom will be involved in group projects at one time or another.

We established that this was a marketable endeavour and, as an incremental approach, we could use our University as the initial testing ground.

Competitive benchmark.

Competitive benchmark.

Competitive Benchmark

Analysing similar apps helped us to understand what we could do differently... & do better

In our favour, none of these apps coordinated meeting slots particularly well. We also learned ways in which our app might turn a profit.

We decided to take design cues from the best features in our favourite apps and opt for the "Freemium" earning model.

Design
Early flow diagram.

Early flow diagram.

Establishing Initial Flow

With focus on satisfying our MVP (to find a meeting slot that suits all group members), we needed to plot a simplified flow through the app.

After setting out the desired functionality, simple chalkboard sketches helped us to quickly plan this initial high-level flow. Features that made the flow needlessly complex were shelved for the time being.

Group sketching session.

Group sketching session.

Design Team Sketch Sessions

By now, we had a better understanding of the problem area and the likely flow a student might take to arrange a meeting. Next, we needed to pull together some concepts that might solve the problem we identified focussing on the key outcome of making meetings quicker to setup and track involvement. We ran a collaborative sketch session to probe concepts and what the bounds of a solution could look like.

This enabled us to explore, but more importantly discount ideas and possible solutions to craft concepts that could then be tested to guide the possible end solution.

Video document of paper prototype user testing.

Low-Fi Prototype

It was now time to open up our designs to outside scrutiny. We began with a paper prototyping phase that underwent two iterations; version 2 benefitting from more realistic interactivity (via 'Marvel Pop').

Our main findings from round 1 were:

  • Users found it difficult to navigate to “find a free slot” after the initial onboarding was complete.

  • We implemented an element of gamification that was not culturally understood by one user who was of Chinese descent.

Round 1 helped to established a workable flow, however, we needed to examine the universal understanding of certain concepts.

Marvel, a cloud-based platform, allowed members to design remotely, as well as in group meetings.

Marvel, a cloud-based platform, allowed members to design remotely, as well as in group meetings.

Medium Fidelity Prototype

Feedback from user testing indicated that the paper prototype contained too much functionality and too many steps.

We realised that, while we started out simple, 'scope creep' had set in. We decided to refocus our thinking on a simple solution by re-establishing our USP:

"To find a meeting slot at a time that suits everyone"

User Testing & Improvements
Different outcomes.

Different outcomes.

Outcome Flows with Less Conflict

We needed to improve the main selling point of our app - finding a free slot to suit everyone. Appeasing all members is not an easy task!

Through usability testing, we identified three possible outcome flows and proposed the following solutions:

  1. Everybody agrees: No conflict!

  2. The majority decides: No conflict!

  3. Everybody disagrees: Two flows available:

    • Tiebreaker game.

    • Negotiate via group chat.

Floating

Floating "Find a Slot" button.

Easy to Find Floating Button

The hard-to-find "Find a free slot" button was converted to an ever-present floating button. In tests, candidates found it much easier to carry out this task successfully.

Universal appeal: 'Pick a stick' was changed to 'wheel of fortune'.

Universal appeal: 'Pick a stick' was changed to 'wheel of fortune'.

Cultural Misconceptions Rethought

User tests prompted us to swap the 'pick a stick' game for a more universally understood ‘spin the wheel’ version.

The playfulness of this new approach was generally appreciated (and, most importantly, understood!) by all candidates.

Final Design - Key Design Considerations
Home screen.

Home screen.

Intuitive 3-Button Navigation

The three primary functions within the app: 'home', 'find a slot' and 'groups' - were now always within reach.

Home screen.

Home screen.

A More Focused Home Screen

A calendar-focused home screen better highlights the urgency of upcoming meetings and tasks. The user has an at-a-glance view of the most vital information.

Status notifications.

Status notifications.

Capacity for Status Notifications 

In our interviews, we learned that meetings are unpredictable. Designs should be mindful of this. We therefore included some functionality for live updates.

Tiebreaker game.

Tiebreaker game.

Animated Tie Breaker Game

The tiebreaker game is now given more realistic and engaging animation.

Groups screen.

Groups screen.

A Dedicated Groups Page

All the users' groups are easily accessible in one screen with thumbnails that can be customised for easier identification. 

Tentative timeline.

Tentative timeline.

Next Steps

Unfortunately, due to outside factors, we could not move on with the project. However, we did highlight a rough timeline of planned improvements and an eventual initial rollout date.

Reflection

Learning Points

Several factors hindered us from working efficiently during this project:

    • We realised too late that we should have focused on doing one thing really well than catering to several 'edge cases' badly!
    • In the early stages, everyone had an idea and very few ideas were shelved (AR navigation to meeting place, anyone?). Focusing on the core USP helped in streamlining our process.

    • As there was nothing at stake for test candidates, we were not fully satisfied that user testing was sufficient to test the feasibility of the proposed meeting solutions (e.g. gamification/majority rules etc.). Building a functional high fidelity prototype and observing its use within the context of a real group project might better serve this end.
    • Team roles overlapped quite a bit, partly due to us all wanting to learn new skills. We may have worked more efficiently had we stuck to specialised roles.