Time Zone Helper
Project type:
Research case study
Services:
User Interviews,
Prototype Testing,
UI/UX
Client:
Quickbase is a cloud-based, low-code/no-code platform that allows users to build custom applications to manage projects, connect data, and automate workflows. It enables businesses to create solutions for specific challenges without extensive coding, making it a flexible alternative to traditional software development for tasks like project management, CRM, and other business processes.
Project goals
Existing date-time fields in Quickbase didn’t indicate which timezone is applied, leading to errors, confusion, and manual conversions using external tools. This combined with the fact that at the time of conducting this research none of Quickbase’s competitors had an easy solution for entering/viewing time in different zones was creating a good opportunity for our product to gain advantage by improving our date & time fields.
A bit of background that is good to know is that there's this confusion between user's local timezone, App timezone (in which all entries are stored) and things get really complex if the used field is related to an activity in third different zone.
The purpose of this research is to find out:
• If allowing users to set timezones (or time differences) for time fields will help their workflow?
• Evaluate user mental models for “App time” vs. “Local time.”
• Identify pain points with entering and viewing times across zones.
The Method used for this research was User Interviews & Prototype Testing conducted over a zoom call. This were standard usability sessions where participants were told to think out loud, that there's no right or wrong answers and they were asked to rate the ease of each task and of course asked for their consent to be recorded.
Participants info: 9 users for 1st iteration and 8 for 2nd iteration, with diverse international location, using frequently time fields.
Approach
Prototypes:
In order to get more insights in how we can come up with the best solution, we’ve decided to conduct a usability sessions where we tested two prototypes built in Axure. One is showing a functionality where people see the timezone and it calculates their local time when hovering over the time, and the other is allowing them to select the timezone for the time they’re entering.
Tasks:
1. Set up a meeting start time in your morning schedule with a team based in San Francisco.
2. Set up a meeting with the same team, which has temporarily moved to Rome, Italy and their only available time is 4:00 PM local time.
Key findings:
• The most positive feedback and ease-of-use rating was received for the dropdown allowing users to choose custom timezone, even though the average ease of use was still not satisfactory (~49%). People preferred seeing explicitly the additional information like the calculated local time instead of have it hidden behind a tooltip. Users showed positive expressions for showing the timezone code after the saved time along with the calculated local time in the view mode of the form.
• One of the most important questions brought by some users is that if we are going save and show the timezone that’s entered by
different users then how will sorting/filtering of table report work? And also what will be shown in the data when exported to
excel?
• It took most effort for people when they had to think about 3 timezones at the same time - their local time, the app’s timezone and
a custom third one. They needed a way to see and compare multiple timezones.
• Whatever time conversions we do, users need to see the preview of what they enter
while editing the field so that they’re confident that the saved value is the one that they intended.
Suggestions for improvement of prototype for 2nd iteration based on users' feedback:
• Add comma-separated locations for each timezone which is a lot more meaningful for people who don’t know codes.
• Have a local time as part of the dropdown selected by default.
• Showing apps timezone by default in the dropdown.
• Search the timezone dropdown by typing timezone name or city or country name.
• Alternative approach is possible where we have two separate inputs which affect the values of each other - one for the app time
and second one for the custom time zone.
Creative direction
Solutions
-
After finding out some of our assumptions were wrong, and some usability issues that we received feedback for, we used that information to come up with an improved solution for Timezones. The so-called “Timezone helper” is basically a popover with additional time input field and item-picker to choose timezone which can be used to calculate and convert the time to the App time. The local time of the user based on browser is shown below the fields as a help text. We had to test if our improvements were working and beneficial for our users.It had the following goals:
● Understanding app timezone
● Seeing correct preview before saving
● Avoiding external tools
Users were asked to perform the same 2 tasks as previous usability study and additional one of comparing times:
1. Set up a start time for recurring activity in your morning schedule with a team based in London.
2. Set up a start time for recurring activity with member of the same team, who has temporarily moved to Sofia, Bulgaria and their only available time is 6:00 AM local time.
3. Compare the times of the two activities and tell which one will start earlier each day.
Positive Outcomes:
● No one used third-party tools for time conversion.
● Users clearly understood relationships between fields.
● An average of ~83% perceived ease of use.
● 7/8 participants said it would improve their workflow.
Remaining Improvements for the final component:
● Make helper button more visually clickable.
● Add 300ms fade animations to emphasize auto-updates.
● Default helper to user’s local timezone.
● Add recently used timezone list for power users. -
After taking into account all the user recommendations, data and analyzing it, we had a few rounds of team discussions where we did ideation, rapid testing and implementation. Different roles as PMs, Developers, QA etc. took part in these meetings and it all resulted in few live code experiments where we got closer and closer to a real working widget and could more easily see how small visual and interaction-level refinements (animation, button affordance) mattered as much as logic.
We worked to implement the following conclusions derived from user feedback:
● Add 300ms Fade-in/out animations for auto-converting time and loading indicator for local time so that it’s more obvious that changes in the helper are affecting the main field.
● Improve the visual appearance of the button that triggers the timezone helper so that it looks more clickable.
● Automatically highlight the whole text of the selected option in the timezone helper in order to make it obvious that users can type and search there. Also add the clear “x” icon for better indication.
● Improve the copy of the new functionality and add an additional explanatory line under the title.
● Defaulting the timezone to user’s detected timezone.
-
At the end we arrived at the decision to split the two fields inside the TimeZone popover and make it wider to show more information as it won't be visible most of the time. Thus we optimize space in the forms. There was also a technical solution to show the already saved value with the user's used timezone for cover even more user cases.
You can see the final result below:
