Ohne Kontrolle — An alarm-clock app that will help you snooze less, by being unreliable… probably.
I’ve been a lifelong postponer, from getting to bed early so I can get up when I need to, to working on my bachelor thesis back in college, I’ve always had a tendency to wait until the last possible minute before I take action.[MOU1] As with most of things, I’m not alone. A huge amount of people also struggle with managing their schedule, and are constantly showing up late to half their lives.
Over time, we learn to squeeze or stretch our schedules to try and fit all the things we should do. We wake up late, so we have to make it up somehow, and take Time away from other activities. This help us cover the problem, but is far from being a solution. At the end of the day, we manage to “be on time” at the cost of doing less things than we should.
This is why when the Capstone Project for UC San Diego’s Interaction Design Specialization began and we were asked by our mentors to choose whether we wanted either Change, Time, or Glance to be the starting point for our project’s Design Brief, working around Time immediately made the most sense to me.
We were asked to “redesign the way we experience or interact with time”. For me, this wasn’t just classwork, it was a golden opportunity to make use of my skills as a designer and do something that would have a huge impact on my life. It was a personal challenge.
Here’s how this challenge has evolved so far:
Needfinding
Even though the brief aligned with a personal problem I’ve had for a long time, I knew it couldn’t be just me, and that getting other people’s perspective about the matter would help. Following the course plan, I set up a few interviews to further investigate this situation.
My main concern was to understand the different ways in which people make sure they start or stop doing something when they have to. I wanted to know how and why people pressure -or indulge- themselves into doing what needs to be done, when it needs to get done.
Perhaps unsurprisingly, the more punctual and organized of the people I spoke with, were also the less concerned with the way they achieved it. It just came natural to them. The huge contrast between them and the rest, made me realize the problem had more to do with the mental model, and not so much with the specific tools we use to manage time.
I found that, quite often, time management problems are caused by a false sense of security, a miss-conception about how much can we control Time to make it fit more or less things. We tend to think that we can somehow waste Time on something, postpone things a little bit more, and then make up for it by taking Time away from something else. But, in reality, time isn’t something we control, but rather something that happens to us, whether we cope with it or not.
If we instead realize that Time doesn’t belong to us, we might become better at actually learning how to manage it.
Storyboards
Following these findings, I approached the problem from two different perspectives, and communicated them through simple storyboards. On the first one, people would rely on external factors to keep themselves accountable and be on time. On the second scenario (see Image 2), I thought about using people’s internal motivation instead.
Since I previously found that the main problem could be peoples’ own understanding of how time “works for them”, I decided to go with the second approach, and help change this from within. I proposed a simple alarm-clock that takes control away from its users. To some extent, at least.
From the moment they set up an alarm, to the moment it goes off, everything works as any other alarm out there. But if people decide to snooze instead of turning it off, the alarm becomes unreliable, and would ring again at a random time.
We snooze because when we say “just 5 more minutes”, we can fool ourselves into believing we’re still in control. But if we can’t be sure exactly when the alarm will ring, those “5 more minutes” turn into a vague “later”, making that daily morning-snooze not that harmless.
This feeling of uncertainty can work as a reminder that, when riding with Time, we’re more likely to be the deer strapped to the hood of the truck, than the person behind the wheel. This unreliableness can, of course, be prevented. Users just need to stick to the plan and do what needs to be done when it needs to get done. Easier said than done, I guess.
Prototyping and Testing
I then started to make the first sketches and paper-prototypes (image 3)of how I imagined such an alarm would work. This proved to be a great way of experimenting quickly with the ideas I had in mind, and share them later on with others to receive feedback.
Sure, I can’t use a paper-prototype to test people’s reaction to an alarm going off at a random time, but making these kind of prototypes was still extremely helpful as they allowed me to test different ways of communicating what the whole concept was about.
I kept on thinking whether I should let my users know exactly how the alarm is supposed to work, or just hint the functionality through storytelling, and let them figure it out by themselves. I gave the alarm-clock a personality in order to communicate the point of the app through a “conversation” between this character and the app’s users.
I used these first paper-prototypes to test this, and had a few people review my prototype, which also included a Heuristic Evaluation from another student of the IXD Specialization. I discovered people didn’t understand what was going on, or how would the app be different from any other alarm-clock out there, for that matter.
With the first user-test already providing really useful feedback, I started making new prototypes (image 4), this time using Balsamiq Mockups software, to be able to give them basic interactivity and do some more testing with them in the future.
This next batch of prototypes had a more developed interface, and I began to use the Create-alarm screen as a way of showing how this alarm differentiates from others, as the first thing users must do is to tell what they want to do with the alarm, and how important this is for them. This way the alarm focuses on purpose rather than just Time itself, making it easier for users to remember why they should stick to the plan instead of postponing it.
With these new, more polished prototypes, I conducted some live user testing sessions (image 5) with participants I recruited. These included people whom I had previously interviewed, so it was great to see them interact with the prototypes that their insights helped shape.
Further Testing
I still had problems determining how I should communicate to users the special features and overall behaviour of this app, in contrast to others alarms available. So I used the planned A/B Testing sessions in the program to help me find out a possible answer to this problem. I went with usertesting.com’s service for this.
I designed two versions of the prototype (image 6). I used SketchApp for both designing the screens, the UI, as well as making the interactive prototype with the new prototyping tools Sketch recently implemented.
Version A didn’t give users any explanation as to why they should tell how important a task is for them when creating an alarm. Version B did offer an explanation on this through some examples. I wanted to see whether users could find out this kind of features on their own, or if I should provide a more detailed explanation.
I also wanted to test (besides the specific differences between the two versions) if users could really understand the way the app is going to function differently from other alarm-clock apps (the random snoozing) without directly addressing it would do so. I tried to communicate the “ground rules” of the app, to see if users could deduce the functionality of the alarm by understanding the principles of it.
Long-story short: they didn’t.
Users did sense some differences between this alarm-clock app and others they had previously used; the way they were asked to think about the why when creating an alarm really stood out as different, but it still wasn’t clear at all for them the fact that the alarm is going to behave differently from other alarms if they snooze.
It was clear from the experiment that both approaches were lacking in regards of explaining why users should follow the steps. If they don’t understand why they need to do something (that will ultimately help them become more punctual), they won’t be inclined to do it.
For users, the way the app communicated its features through a series of “core principles” made them feel they were being lectured by an alarm-clock. This problem even shadowed the difference between the two prototypes, as neither of them provided users with a clear explanation as to why some of the things the app asks them to do, will actually help them to become more punctual and snooze less.
Conclusion… Well, kinda
So, what did this long list of mistakes and failures amount to? Well, yet another prototype. And a short promo video. And this blog entry.
The current version has had mayor changes in the way users are introduced to the alarm’s mechanics. From making it literally easier to turn off an alarm instead of snoozing it, to openly and clearly stating what the whole deal is about from the very beginning, the new prototype is one step closer to providing users with a new way to fight against procrastination.
The truth is, even though I would love to say that this is going to be the greatest alarm-clock ever, everything that’s interesting about this app -be that its concept, or its potential to help people become more punctual over time-, is nothing but speculation until tests and facts prove it otherwise, and although I have made solid progress in many aspects of its design, there are still many things left to tweak, improve, and test, before I’m able to state its real “life-changing” value.
And that’s precisely what excites me the most about being a Designer. Our job is to tackle products and ideas as experiments, and keep failing -hopefully at a constant pace- until we gather enough evidence to know what works, discard what doesn’t, and show something worth seeing. Sometimes we can also go with our gut and hope for the best. Other times, like this instance, we can do both.
I want to thank Prof. Scott Klemmer, Prof. Elizabeth Gerber, Prof. Jacob Wobbrock, the UC San Diego, Coursera, and so many of my fellow students on the IxD Specialization for your support, feedback, and constant motivation.
In case you missed them, here are the links for both the current prototype and the short promo video:
Prototype: https://sketch.cloud/s/vR541/all/page-1/00-loading-screen/play
Video: https://youtu.be/YSHBKrW8KHo