My prototype of an app for learning UTC

Ka Bla
6 min readNov 12, 2016

--

As someone who works for a company with locations around the globe, I am often calculating what time it would be for a colleague in another part of the word. As a software engineer, I sometimes deal with data that may be timestamped in any number of different local times. When I started the capstone for the Coursera Interaction Design and found that one of our design briefs pertained to changing our perception of time, felt that these pain points related to time zone indicated the presence of a design opportunity.

The opportunity: teach the world to use UTC

When I was interviewing users as part of an early needsfinding assignment, I found that other people faced similar issues. I was asking them about scheduling a meeting at “2 PM” but I was sitting on the west coast of the United States and they were on the east coast, three time zones away. They had to stop and consider whose “2 PM” I was referring to, and then do the math to figure out what the request meant for them.

I concluded that it would be better if many communications about time were handled in UTC instead. UTC does not change depending on where you are, and it is not affected by daylight saving time. If two people decide to meet at 4 AM UTC, there is no ambiguity about when that would be, no matter what the geography. The app prototype I created has the goal of teaching people to easily translate between their familiar local time and UTC, so that they would be able to shift to using UTC more in their daily lives. It would obviously require a substantial change in the culture of telling time to convince people to communicate in this way, but given that this course is meant to be a learning experience, I wanted to be ambitious.

How to teach someone to tell time all over again

I started out by considering how people might be able to learn to tell time in UTC. One of my first ideas was to simply provide a simple interface for translating between UTC and local time, and hope that if people used it enough, they’d learn to do the calculation themselves. I think that learning to tell time is fairly boring, though, so I also thought about gamification, where quizzes or games could teach translation between UTC and local time. I also liked the idea of regularly exposing users to UTC time, and taking advantage of the fact that many people already check the time on their phones quite often. In the end, some elements of all of these ideas made it into my prototype app.

The prototype app explains the concept of UTC briefly, then offers three main features. The first feature is the simple interface offering conversion between UTC and local time. The second feature is a scored quiz the user can take to practice doing mental translations between UTC and local time. The third feature is a widget that can be installed on the phones home screen and lock screens which shows both local time and UTC time.

Iterating based on user feedback

There were cycles of iteration in each of these features shared different versions with users. The quiz was particularly challenging I had to find a way to provide feedback to the user about their answers in a way that would be motivating, keep them focused, and also help them learn. I also wanted to strike a balance between giving the user insight into their progress through the quiz, and overwhelming them with numbers at a time when they’re trying to answer mental math problems. Feedback from users who used the quiz feature helped me with this immensely.

In an early paper prototype, I did not provide any feedback on the quiz answers until the user had completed the entire quiz. I thought they would keep them focused and motivated until the end. However, I realized that not explaining the correct answers and just giving a grade was not going to promote improvement over time through learning.

Paper prototype, where the only feedback about quiz performance is this answer screen at the end

With that in mind, my next iteration added an answer screen after every question. However, I found that I providing too much information about the question on the subsequent answer screen, and it was feeling repetitive to the user. I limited the amount of information on the answer screen to the original question in a light font, a statement of “correct” or “incorrect” for the answer, and an explanation of the correct answer. That way it looked substantially different from a question screen, and did not contain the wrong answers in way that could hinder learning.

Prototype before more user testing, where the selected answer remains on the screen and the question is still colored black
Prototype after user testing, where the selected answer is no longer on the screen, and the question becomes gray

Another place where users sometimes struggled was when I asked them to switch from a local time to UTC conversion to a UTC to local time conversion as part of the time conversion feature. The in-person users did not find the button quickly, and expressed verbally that they were not sure what to do. When it came time to do A/B testing as part of an assignment, I decided to focus on that button. The original button was white, so I decided to test that against one where it was a dark color gray.

Control: the switch button is white
Treatment: the switch button is dark gray

I did not see much difference between the performance of users in the two different conditions, and actually found the button without issue. For this reason, I concluded that I did not need to use an extremely bright or bold color to attract users to the button. It is a mild gray in the final prototype, which fits in with the rest of the color scheme. It is possible that the in person users struggled because they were nervous about performing in front of me, their friend who had created the prototype, while the A/B test was administered to anonymous strangers on the internet.

Simple and interesting: difficult to achieve

It’s not easy to balance making an app that people can use without a substantial period or ramping up, and also making the app compelling enough that people will actually want to use it. I got positive feedback that the app was easy to use, but I did not find anyone calling it particularly cool or impressive. This may be fine, since the app does not need to be used intensively in order to possibly produce the desired result. After all, I’m not trying to show the users advertisements or encourage them to buy products, I’m simply trying to have a different perspective on telling time.

The prototype app, called “Learn to use UTC”, is available here: https://invis.io/X79B7EUC6

--

--