Calendar App designed for Android

How might we help a company’s employees set meetings and navigate to meetings rooms.

Srishti Gupta
8 min readOct 12, 2020

Overview

Every now and again I enjoy working on design challenges outside of regular work. It helps me cut the boredom of working on the same product for a long time; as well as sharpen my problem solving skills.

This personal side project was one such design exercise — done in a limited amount of time to keep things fresh and help me break out of a rut.

Problem Statement:

Acme is a fast-growing company that is adding employees and workspace at a very fast pace. They are doubling every year both in terms of employees and workspace. Given a highly collaborative environment, employees need to schedule a large number of meetings ranging from 1:1s to large brainstorming sessions. Come up with a design solution for employees to schedule meetings and book a meeting room for the purpose.

Things to consider

  • The employees are spread across two different buildings in two different locations
  • Rooms come in different sizes and not all the rooms are equipped with the same set of features and facilities.
  • Since new employees are joining every month, there should be a way to find out who it is that they are inviting to the meeting.
  • Also, there needs to be a way for new employees to schedule meetings and find meeting rooms easily even when they are not familiar with the layout of the facility.

TLDR: How might we schedule meetings and book meeting rooms with ease & minimal on-boarding for employees of a company spread across multiple locations

Users & Audience:

Due to the lockdown situation I was unable to rely on user interviews. To determine the kind of users that will need this product I relied on:

Good ol’ fashioned brainstorming, Insights from 3 People who use calendar apps for professional and personal purposes, Competitive Analysis, User journey mapping.

This helped me identify the key groups that would use a product like this:

1.) Human Resources Representatives: Need an efficient solution to organise company-wide events, schedule interviews

2.) Employees: Scheduling meetings with other team members or 1:1s to discuss on-going tasks / activities

3.) New Recruits: They are integrating into a new team and need to keep track of their meetings and navigate to them easily

4.) Executive Assistants: Juggling between multiple calendar schedules of CXOs has made these people power-users of calendar apps

From here I boiled it down to creating 2 main personas who’s journey i will be mapping in more detail:

Persona 1 (LHS): new recruit | Persona 2(RHS): Executive Assistant

Roles & responsibilities:

This was a simple design exercise done for my own amusement. I found the exact design challenge online and worked on information architecture, persona building, interaction design, high fidelity mock-ups and prototype myself.

Scope & constraints:

  • Our solution must be complete in and off itself and not require additional devices to function — apart from internet connectivity and a smartphone with the app installed on it.
  • We must focus on mobile centric solutions so users can manage their calendar from anywhere.
  • Sign-up/ Login is taken care of via employee ID and password used for accessing other internal services.
  • Users are familiar with / have previously used calendar management and productivity apps

Design Process:

STEP 1: Tertiary research & competitive analysis

I started off the tertiary research about calendar apps with trends/ insights I could find on various white papers about productivity apps. I also read user reviews (available in various places online depending on whether you’re looking for iOS review/ android reviews). Lastly I conducted a thorough competitive analysis of the below apps.

L to R: Outlook, Google Calendar, Doodly, Time tree, Calendly, Meetly

I chose these apps based on the user insights I had from the tertiary research and my user interviews with a limited set of users. This helped my draw out the user types mentioned above and finalise my two key personas.

STEP 2: User Journey Mapping & Information architecture

The tertiary research and persona building helped me benchmark product functionalities. To prioritise the features I would want to include in the design solution, I started by making a User Journey Map keeping in mind the key aims of the two personas I’ve considered.

I started off writing down the key activities users may want to accomplish with this product and then drilled into the exact tasks they would have to do. For example, a key activity could be, creating a new meeting. The tasks within this could be — defining meeting location, setting the agenda of the meeting, searching for colleagues to invite and viewing their availability and so on and so forth.

This exercise helped me formulate the information architecture for my calendar app:

STEP 3: Sketching out key screens

Once I had my IA down, it was a matter of ideating different variations and sketching out the key screens. And outlining the key constraints beforehand helped streamline my final approach.

From the initial brainstorming and list of features to the sketches of key screens

My explorations were made keeping in mind two main things:

Firstly, our users should require no / minimal on-boarding.

A good example for that would be the default view of the app — the day-wise calendar view. I was very inspired by various productivity / time management apps that many power users lauded. And my initial explorations were very ambitious. I was trying to increase the number of things users can do in a given view. As a result I had to include UX paradigms that would work for power users but perhaps would be less intuitive for larger audiences. I was about to fall into a feature frenzy trap.

I went back to my user personas and applied the Pareto Principle i.e. a small fraction of the functionality will receive the majority of user time; this doesn’t mean that the rest of the functionality or content has no value but it does mean that some functionality and content is more important to the majority of users than some of the rest. This enabled me to focus my ideation on the things that matter most and cut the clutter. Less is more — I focused on the core attributes of my product rather than doing a whole bunch of things.

After that I included user experience paradigms that have a very low learning curve thanks to the fact that many users are already familiar with them. This also helped my move faster because I wasn’t trying to reinvent the wheel when it comes to UI elements.

On the default state(centre), only schedule related tasks are shown. One tap away more features are also introduced.

Secondly, users should be able to access this anywhere without requiring any other device apart from what they’ve already got i.e. their personal smartphones.

This constraint guided me while ideating for allowing users to find meeting rooms easily even when they are not familiar with the layout of the facility.

Initially I was tempted to suggest including things like BLE beacons to help users navigate from their current location to the meeting room. But a solution like that seems overly engineered and frankly out of touch with the reality of the user.

Apart from the fact that BLE devices are expensive and could very well be outside the budget of a small/ mid sized company like ACME, it also expects all users to have their phones with them ALL THE TIME. It would also assume that all ACME employees would be ok with the security limitations that come with bluetooth low energy devices. Not to mention the energy drain that comes with keeping your bluetooth on — what if I have to get to a meeting but I have just 5% battery that I’d like to save?

A solution like that would ignore the user’s default behaviour. Based on my user interviews I realised most people go to meetings with other attendees or if they are alone they call up their colleague/ any other related human to get to the room on time. So, rather than give a solution that requires users to drain their battery life and pretend to be in a vacuum where no one else can offer assistance, I decided to lean into their default behaviour.

I decided to make it very easy for users to call up organisers or anyone else who might be attending the same meeting. I also made sure users can ask another attendee to set a location of their meeting if they don’t know which location to pick. It’s not something radical and new. But it is something that most users would think to do.

leaning into the user’s default behaviour of reaching out to their team members for assistance

Outcome

The final screens I created are shown below. I also made a Quick Prototype using InVision which you can try out.

It was a fun 3 day exercise. Day 1 was spent brainstorming, doing competitive analysis and speaking to whatever few target users I had access to in a lockdown. On day 2, I spent time mapping the user’s journey, creating the IA & sketching out key screens. On the last day I turned to sketch to create the final mock ups and prototyped them using InVision.

This helped me break out of a design rut. I returned to my normal design tasks with renewed vigour and refreshed ideas.

In this case study I have focused primarily on the interaction design. Want more details on how I finalised the visual identity? Let me know in the comments :)

--

--

Srishti Gupta

Ux designer | Problem solver | Avid traveller | Animal lover