Calm Technology – CTA train tracker

This is the first in a series of projects that will be developed around the idea of applying “calm technology” to product design. Coined by Mark Weiser and John Seely Brown at Xerox PARC in 1995, calm technology can de defined at a high level by the following:

First, by placing things in the periphery we are able to attune to many more things than we could if everything had to be at the center. Things in the periphery are attuned to by the large portion of our brains devoted to peripheral (sensory) processing. Thus the periphery is informing without overburdening.
Second, by recentering something formerly in the periphery we take control of it. Peripherally we may become aware that something is not quite right, as when awkward sentences leave a reader tired and discomforted without knowing why. By moving sentence construction from periphery to center we are empowered to act, either by finding better literature or accepting the source of the unease and continuing. Without centering the periphery might be a source of frantic following of fashion; with centering the periphery is a fundamental enabler of calm through increased awareness and power. – Designing Calm Technology

The goal of calm technology is to have technology serve humans, not the other way around. In today’s world of being bombarded by ads, smartphone distractions, and apps that compete for our attention, it should be a goal to reduce technology to its essentials and push it to the background, while also allowing it to come to the foreground when it needs to. I think this is going to be a big thing in the coming years, partly as a reaction to the poorly designed technology experiences we are forced to deal with today.

Building a better train tracker

One area I lose a lot of time to technology is in figuring out when the next CTA (Chicago Transit Authority) train will be arriving. The timetables are not real-time so do not account for delays and having to pull out my phone to see when the next train is arriving and when I should leave in order to catch it inevitably leads to being distracted by the gateway of information a smartphone provides. This project was built so that I could easily and almost sub-consciously check when I should leave from my home to catch my next train.

Design considerations

The device is built using an Arduino MKR1000 powered externally and a single WS2812B LED, so these were the hardware parameters that were designed around.

Several considerations were given to solutioning for this design:

    How many trains should this track? From which station, and in which direction?
    How should the notification system operate? At what frequency?
    How should this be designed so it operates at the periphery?
    What technology choices should be made so that this device is a good “technical citizen”?

In order to quickly get this built and test its efficacy, the decision was made to just track one train line, station, and direction for now (the nearest line and station to my residence, and the direction I am most often heading in).

As for the notification system light and color were chosen due to their ambient, peripheral qualities. Obviously having an additional or alternative notification system that relies on a different medium (color choices, sound, etc.) would be necessary for those that are blind or color-blind.

Now there were several considerations given to frequency (times) of the light being displayed and which colors to use. The decision was made to calculate time based on travel time from my residence to the station, thereby reducing one more cognitive step (addition of travel time to station plus arrival time). A train tracker will tell you when the next train is arriving but does not usually include the buffer time you need to give yourself to leave from your location. It was a very conscious decision to avoid using red, yellow, and green as these colors already have meaning in relation to transportation and time. If the LED was set to red would that mean the train was delayed? Stopped on the tracks? Would it mean I should stop? If it was green would that mean I should leave? Would it mean the train is going and has already passed my target station? Note here that as the station is about a 6 minute walk away and I don’t want to wait at the station for that long, any train that will be arriving within the next 6-8 minutes will be “time to leave,” with 5-6 minutes being “I might make it in time” and less than 5 minutes being “too late”. The LED used is programmable, so there is only one light source and the colors settled on were blue (neutral) for “time to leave,” purple (neutral, but with enough red in the hue that it suggests importance or urgency) and nothing (LED off). The original design had the LED turn on to a brownish yellow if I had missed the time to leave for the train, but in order to reduce the cognitive processing needed by the user and to not distract, it was changed to just turn the LED off. The LED stays on and at its current color until a change in state of the train’s arrival time. So the design ends up looking as below:

Don’t leave yet

Time to leave

Might make it if you leave now

While periphery choices have already been discussed, it is important to note that as this device is designed to be running in the background all the time when it is turned on, sound as a notification was decided against. It would get annoying very quickly hearing even pleasant “time to leave” sounds due to the frequency at which trains arrive and leave the station. Light is more ambient and less disruptive. Also, the LED used is just small enough to not stand out, but bright enough to be noticed when you want to check if it’s time to leave.

In order to provide timely estimates, the Arduino fetches arrival time data from the CTA Arrivals API every 10 seconds. This seemed like the right balance between betwork bandwidth with getting timely data. Bandwidth used is already tiny (data is returned in JSON format in a few bytes) and the code is optimized to account for small Arduino RAM and storage size. And to turn off the device when it’s not needed, the on-board Arduino power button is used. It can also be unplugged from power and will restart automatically when it’s plugged back in.

Next steps/future improvements

As this is the first iteration of this product, several ideas may be implemented in the future. A priority is designing a physical case for this device to be housed in, removing wires from the user’s view and further reducing it to its bare essentials aesthetically. There might be several devices that a user has in their home/office/wherever this device might be installed that similarly rely solely on light as notifications, so some differentiation would be required here. Whether this is done through changing the light patterns, or probably more effectively, adding some simple signifier to the physical design of the housing, it should be obvious to the user what the purpose of this device is while still remaining on the periphery. Another improvement would be around power, as the device currently runs while plugged into AC. Moving to a long-lasting battery would make it easier for the user to move the device to another location while also further hiding the technology itself (wires) from view.

Lastly, getting this in the hands of real users and doing user testing would be valuable for product improvements. I’ve got some ideas for adding sensors to this to have some internal metrics running for product feedback too.


Monopoly on Empathy

Look through any User Experience (UX) conference presentation description, UX profile on Linkedin, or go to any UX meetup and the word you will hear most often is “empathy.” As UX has become more formalized as a discipline over the last few years this word has been a rallying cry for the industry. “We fight for the user!” and “We bring empathy to software applications!” are commonly heard. But this word is problematic for many reasons and it’s a massive oversight by the profession that it continues to be used. It is not so much because of the word itself but moreso because of its application and implications. While “empathy” is the most commonly used, it’s certainly not the only one in this tale of poor language choices. A pass at slaughtering these sacred cows will be made too. I aim to point out how this language problem is ultimately counter to the goals of UX (both the end user’s experience, as well as UX as a profession). For want of avoiding making this seem like a fastidious excursion into semantics, I will also tie this into how it impacts UX’s standing within the corporation at large.

The foremost problem of using “empathy” to define your profession’s existence is that you are essentially stating that you as a UX professional have a monopoly on empathy. You are implying that developers, marketers, business people, and anyone else peripheral to the UX craft are apathetic, indeed the opposite of empathetic. It is implied that without you, there would be no empathy for the user, as if the rest of the project team would, whether through menace or ignorance, create and deliver an application that confuses and demoralizes the user. Of course, this is absurd; no one will argue with you that wanting to ensure your users can easily use your application and accomplish their goals is a positive thing. And it should be made clear that UX as a group does not have a monopoly on empathy, just as it does not have a monopoly on the user. Other groups are perfectly capable of wanting to ensure the application works well and easily for users. This is all without even mentioning that “empathy” is a very presumptuous term altogether.

Perhaps the second-most offensive word in our UX existentialist vocabulary is “delight”. Within an application measuring delight is subjective at best, and I can guarantee that no user study that utilizes the encroaching practice of video recording will be able to suss out or give any reliable data whatsoever regarding delight. The misguided pursuit of delight has led to unnecessary animations, uncalibrated and perhaps even overly personal/conversational help text and copywriting, among other things. While delight might be nice in video games or entertainment, I would argue it is not something that is even needed in all applications. Do users even want or need to be delighted? Delight should mean they accomplished their goal or task with the application, not that they saw some pretty colors and slick button animations (…Material Design). Or receiving confirmation emails like “you’re totally awesome for signing up dude, surf’s up!”

The final piece of language we will pick apart is certainly the easiest to do so, due in part to its lesser frequency compared to the prior, but also due to the extremity of its claims – “changing the user’s life.” If “empathy” or “delight” were pretentious or presumptuous, laying claim to “changing the user’s life” through designing experiences is mega-pretentious. Too often this language is a mask for signalling of the offending UX professional’s importance, not the user’s. “We are changing the user’s life” is how this is most often heard. The language has become self-serving, ironic given that UX is meant to not be about the designers themselves but about the user.

Why are we seeing such language be used, and used so boisterously? As mentioned in the opening paragraph, UX has only recently become an “official” group within most companies. While UX has been around for a long time, it’s acknowledgment by the corporation is more recent. Thus the profession has had to utilize language that displays confidence in an effort to establish and formalize itself as part of its entry into the corporate landscape. There is without question a degree of pretentiousness and egoism exhibited by some in the design and UX professions. Is the self-righteous language we are examining the brainchild of those offenders? Perhaps, but the more plausible cause is this birth-stage of the UX profession.

Any discipline at early stages is both burdened and liberated by being able to define themselves. Software engineering is a couple decades ahead of UX and thus has had to work to establish itself within the corporation for much longer, so observing the software engineering profession can serve as a cautionary tale for UX as I believe the isolating language that developers often use has resulted in the profession shooting itself in the foot time and again with regards to its standing within the corporate hierarchy.

A common attribute of the language discussed above is moralism (or even self-aggrandizing). Whether or not this is intended, what we can see is a two-fold effect: through moralizing, you start to create a division between you and other groups (them below, you above); through using this language to establish a jargon of its own for UX, you start to become other. Creating barriers between you and other groups – isolation – is existential death within the corporation. Don’t follow the mistakes that the software engineering profession has made by rattling off technical jargon and buzzwords, feeling shocked at the business’ lack of understanding (or more accurately, caring). UX does NOT want to get the same treatment while making remarks like “yeah we just need to boost the level of empathy with this onboarding flow so that we can delight our customers a little bit more and the user’s life will be forever changed.” Do this and UX becomes “those guys creating experiences and delight for our customers… or something like that, I don’t know but they’re in the basement somewhere” rather than a partner of the business.

Furthermore, empathy and delight are not easily understand in business terms. Something like “helping remove roadblocks for users so that our products are better and get more people through the funnel” – now that is something that the business can understand AND it works in service of the user. Hopefully it is evident that vague and vacuous terms like empathy and delight are terrible word choices for a profession that is working to establish more respect for itself within an organization. The reality is that sometimes business goals cannot be ignored, and designers unfortunately cannot always make the decision that is in the best interest of the user. They can “fight for it!” sure, but it can’t always happen and this is ok.

My recommendation: get rid of the moralizing and self-aggrandizing attitude and use language that puts you on equal footing with the business while explaining the importance of paying attention to user needs. Language puffed up to display a confident attitude may have helped when UX was working to establish itself within the corporation, but it can only do a disservice now. Language plays a larger role in business than many of us wish to acknowledge, so change this before it’s too late. Before UX becomes a group that is relegated to lower rungs of the organization, rather than seen as a business partner. Understand whether users actually need empathy or delight. Dispensing with this language can only help UX in its goal of being seen as a crucial element of the business. Developers have their own self-alienating language they use, and have suffered for it. UX professionals should stop now and avoid it before it’s too late. Take a more research-driven approach to design and gather metrics (where you can). Focus less on capital UX and more on lowercase ux, that is focus less on the profession and its existentialism and more on user experience. And if you truly believe that a software application can be “life-changing,” then it is ultimately the application itself, that is to say, the product, that affects this change. That product is everybody’s job, not just UX’s.