Daze
UI/UX Design Case Study (5-minute read)
Overview
A self-directed app design and development project aimed at creating a more usable and intuitive experience by challenging common calendar conventions, with the eventual goal of releasing the app to market. While skilled at design, the development of the app will be an ongoing learning experience.
User & Competitor Research
I collected and coded a total of 200 reviews submitted to Apple App Store and Google Play Store for top competing calendar apps "Google Calendar" and "Calendar by Readdle", and coded them for qualitative research (qualitative research attempts to make sense of patterns, traits and characteristics rather than quantitative research which makes sense of numbers, counts and measures). I decided to set aside any customer-support-related complaints in order to focus on solutions that can be addressed firstly by design. In addition to the reviews, I interviewed five every-day calendar users, face-to-face, and observed them using various calendar apps to illicit more in-depth insights. Aware that some competing products aren't digital at all, two of these participants were traditional wall calendar and diary users. The top three findings are as follows:
| 25% of all respondents regard changing the calendar/colour integral to their usage, and found it frustratingly difficult to do so. |
| 20% found the default view unsuitable for the way they like to use a calendar. They were also frustrated by not being able to choose their default view. |
| 15% had issues around the representation of "today". Across all reviewed product competition, there was confusion around the shortcut icon used to jump to "today". Highlighting of today's entry within a wider context was also lost in the sea of competing event colours. |
Being a heavy calendar-user, myself, I wasn't surprised by the many of the findings. But it shocked me to discover that the Google Calendar app, through its recent updates, had been doing themselves a disservice by slowly making the "change calendar/colour" function less noticeable, and finally impossible to do.
User Personas & Jobs to be Done
I used the interview and review data to assemble an extensive list of "Jobs to be done", which helps to clearly inform the Ideation Phase, and also act as a checklist or vote by which to assess the design ideas. I decided to forgo personas in favour of using the JTBD method, which allowed me to focus on designing directly for the users' actions.
To pre-assess my sketched ideas before creating any digital prototypes, I compared them to the existing competition by mapping out both journeys on paper. For each "Job to be done", I drew each screen and illustrated the flow and interaction. I ranked each step as to how instincively findable, identifiable or logical each button was (heuristics), how large or reachable they were (accessibility), and how many overall screens (or steps) it took to get a job done. This stage helped to push me to iterate to create more impactful and intuitive designs, while also providing me with valuable data to illuminate the trade-offs or improvements in actual numbers that reflect a user's experience.
Ideation
During the ideation phase, I discovered that many existing calendar views by nature of their construction accentuate often-unnecessary relationships. In the Google Calendars week view (pictured below), for instance, the relationship between similar times for events/meetings across a week are accentuated, while the relationship of events which follow each other in one day is obscured and important events are often hidden. I see the single-most important aspect of design is to make communication clearer – so it's my opinion that if relationships between different bits of information cannot be easily intuited, then it's a fail of design.
I decided to examine existing calendar view options, understand their benefits and downsides, and come to an understanding as a basis for my design solution. I studied the most conventional separations in time and discovered most were arbitrary for calendar use. Most people have a natural reset with sleep overnight, and acknowledge weekly schedules (some with a natural reset over the weekend). So even though weeks are a somewhat arbitrary social construct, "days" and "weeks" seem to be the most meaningful separations in time. "Months" and "years", on the contrary, cut weeks apart. While many calendars will create distinct separations between months and years, for my design I've sought solutions to accentuate and retain the meaningful separations like days and weeks, and in doing so, offer solutions to common pain points like being late in a month and not seeing events that lay ahead.
Finally ditching many existing common calendar view options, my design offers a "week-wide" view that scrolls through the weeks (where the months and years flow on uninterrupted), a "narrow" view that scrolls through days continuously, and an option to further zoom into a "schedule" view for more precision.
Prototype
How might we design a "today" shortcut to be more easily identifiable and meaningful within the context? How might we create a more intuitive and informative user interface?
"Today" collapses to the top, bottom, right or left, depending on which way you scroll, as an ever present or "sticky" shortcut. The motion and position of the collapsed shortcut serve to provide intuitive meaning and and context.
How might we emphasise and enhance discovery of the colour/categorisation feature?
Google's recent offerings suffer from a poor use of space, obscure some of the most important information, and make editing tediously difficult to do. Despite recent design trends away from a reliance on icons, my solution uses icons to aid in recall and easy identification, while also maximising screen real estate for both portrait and landscape orientations.
Typically in apps, the design is swamped by the keyboard whenever an input is selected. I examined what types of changes were often necessary in changing times and dates, and found a slider mechanism would prove most intuitive.
Next steps
When I began prototyping, none of the tools available offered adequate dexterity to sufficiently represent the interactivity that is pivotal to the concept of the app – so I started the prototype by learning React Native. React Native is an app-building framework, so while the beginning stages are tedious, making the prototype this way will help to shortcut the development process. I look forward to finishing a working prototype and gleaning further insights from observing people using the app.
My Roles & Responsibilities
An exploratory project, with a team of 1: I was UX researcher, interviewer, designer and self-taught developer-in-training.
UX qualitative research
Competitor research
Sketching & wireframing
UX & UI design
Branding & identity
Currently learning: React Native development