UX nerd

This post is the second part in the series: the clock. As I mentioned before, I had this lecture with Bert Bongers where he introduced the concept of device parsing, which he came up with (if I’m not mistaken). There, together with Dominika, Maria and Valentina, I did the parsing of a clock.  In this second part, I would like to explain what device parsing is about, illustrating the explanation with our own experience parsing the clock in the image on the left.

When I looked for information on device parsing on the Internet, I found several slightly different definitions (for example, this one). I think that the idea is still evolving, and Bert Bongers says that he’s still working into validating it, which is why it’s probably still changing. Anyway, I’ll just refer to what we did in the lecture.

Device parsing is a method that consists on taking apart some device in order to understand its functionality (and potential functionality) through the analysis of its components. The goal of this is to eventually, once you have understood it, build it up again taking the user into account.

So, we started by thinking about what people may want to use the device for (its functionality):

In the case of the alarm clock, primarily:

• See what time it is
• Wake up to it (it is an alarm clock)

But also:

• Check the date (it has that functionality)
• Check the temperature (it has a thermometer)
• Use the light  to see in the darkness of their rooms

You probably note that some of these are weird, like checking the temperature. At least I can’t imagine why I would like to check the temperature in my own room, I mean I’m not relying on temperature measurements to see if I want to put on a sweater or not, for me it’s just a matter of am I warm or cold. However, for some reason someone felt it should be there. Others, like using the clock’s light to look for something in the dark, are weird because they were probably not intended by the manufacturer. But I’m sure I’m not the only one who clicks on the light button to help me look for stuff when I don’t want to turn the lights on.

Then, we took the clock apart to take a look at the components, finding (no surprises here) that alarm clocks are in their electronic, and more precisely digital, technological stage. Why is this relevant? Because every technological stage has it’s own interaction constraints and capabilities. The interaction that you can realistically introduce at each stage is different and, even if you decide to leap on to the next one, you may want to know why you’re doing it.

Next, we took a look at the input and output devices (in the clock, mainly buttons, but also the screen, the buzzer, etc.) and the different components. We analized how the input and output devices relate to the components inside and the functionality, determining the way in which the tasks associated with each function are performed. The idea is that you get to know why things behave the way they behave. Was something the designer’s choice or was it a technological constraint? Could it have been built otherwise? Why does the same button serve as snooze and light on button? What would it take to make things differently?

Finally we put it together again and took a look at the feel: how the interaction is affected by the components. In the case of the clock, the light/snooze button (on top) had haptic feedback, but the others (on the front, used to change the settings) made a noise when touched, for example.

So, this was it. Now we know why this clock behaves the way it does, what are its technological capabilities and what would take to make it behave differently and we’re ready to undertake it’s redesign putting it together with the user in mind. I agree that it doesn’t make much sense with a clock, probably you can tell what’s inside without opening it up. However the concept looks interesting and I’m looking forward to using it if our suggestion to redesign a mobile phone’s interface goes through (fingers crossed :)