The Weather-Calendar App
This rapid prototyping project did not happen as quickly as I thought the name would suggest – much needed to be completed even before the step of prototyping: user interviews, affinity mapping, exploration of concepts and story boarding. After coming up with the first low fidelity prototype, there is usability testing and editing, more testing and editing and the iterative process continues…
My project revolved around the idea of ‘weather’. As I needed to keep the design process a very objective one, I had to constantly remind myself to not have any pre-conceived ideas of how the eventual app was supposed to be. It might not even be a mobile app!
I began my user research through face-to-face interviews with 3 subjects, using the 4-list method. The 4 areas which the subjects had to consider were the pains, pleasures, contexts (place & time) and behaviours in relation to ‘weather’.
With the findings from the research, I began searching for common themes and created various affinity diagrams.
Since the user interview was on the topic of weather, I first sorted the based on the weather type — rain, sun or the in-between (weather change).
Associated with the weather was a lot of mentions about different types of activities. So I did a shuffle based on activities too, sorting them by indoors and outdoors.
However, there weren’t significant takeaways that I could draw, so I delved into more details and looked at what types of pains were there. They could be divided into 3 categories, those related to physical discomfort (being cold & wet), plans being disrupted and consequences from uncertainties in weather (eg. Having to carry the extra weight of an umbrella everyday in case of a rain). In the end, the point about making plans was most salient — a lot of the pains were a result of inability to perform an activity according to one’s plan because of unexpected weather change.
With the findings, the problem statement was born:
“From my interviews, I’ve learnt that a common problem among the users I interviewed is that unexpected rain tends to disrupt their plans for the day, such as going to appointments or exercising outdoors, causing much unhappiness.”
My initial concepts to overcome the problem were based on the ideas of ‘unpredicted rain’ and ‘planning indoor activities’. Sketches were quickly generated to explore each idea in different ways.
Eventually I selected the weather-calendar idea under ‘unpredicted rain’ in creating a more detailed screen flow. This became first version of the paper prototype used in the usability testing. To accompany it, a story board was also created and the scenario put out to users was: “You and your friends really enjoy outdoor activities and they would like to arrange a day for cycling at East Coast Park this week.” The task they were tested on was: “Check for a suitable day this week.”
The usability testing with paper prototype version 1 revealed ambiguity in the buttons, leading to several changes: 1) ‘Link to Calendar’ was renamed ‘Calendar, 2) Instead of a button on first screen, ‘Rain Alert’ became a toggle on/off in-app, with other preferences within app settings and 3) Left, right arrows were added to the month in the calendar to enable users to jump from month to month instead of scrolling to no end. A second version of the prototype was then sketched.
2nd version of the paper prototype brought surfaced the issue of incoherence in app flow. As there were 2 main features in the app, it was difficult to show the flow with both features going on: 1) a calendar that has day to day weather indicated and constantly updated and 2) a rain alert feature that is only activated when there is a impending rain. After some deliberation, I decided to ditch the first 2 screens and shuffle some around. Despite most weather apps having a summary of the weather conditions on the first screen, I realised that my target audience did not need that information. Since the weather condition was already indicated on a daily basis in the calendar and would be constantly updated, the summary was not only redundant, it confused them as to what they should do next.
Later, I refined the prototype using Balsamiq, while incorporating the insights gained from paper prototype version 2.
In version 3 of the prototype, I decided to start the screen simply with a rain alert on the home screen. This could immediately give the user a gleam at one of the features in the app. After dismissing the alert, the user searches for the app icon and tap to launch the app. User is immediately led to the calendar, hence the ‘home’ button on top left has been removed. User can choose a day and enter the information by double-tapping. If later, the day turns out to be a rainy day to come, the rain alert (change date) will be triggered on the home screen. After tapping on the option ‘Go to Calendar’, user simply have to tap, hold and drag the calendar entry to another day.
This version of the prototype was later made interactive using POP.
From prototype version 3, another consideration came up with regards to the rain alert — it might be better to have the alert as a header notification that could appear even when the user is currently using the phone and not just on the home screen, especially when an impending rain is just 1 hour away. Subsequently, I may also consider the need of incorporating some back end issues into the UI. For instance, using crowd sourcing to get more immediate update of weather for each day. As well as syncing with user’s existing calendars from Outlook, Google, etc.
An open mind will help to create objective questions and results, especially in an in-depth user interview. This is really important in shaping an app that will appeal to more users. It will also help one to see beyond an assigned topic, to think creatively and to find an answer to what the users need. However, being humans, we cannot help but to have bias in our judgment; we can only try to be as mindful as possible when dealing with something objective like UX design.