Designing for user environments

Last weekend, I was lucky enough to experience the Our Happy Life exhibit at the Canadian Centre for Architecture, which explores the way affect and emotion are quantified and used as a basis on which our built environments are designed. The exhibit juxtaposes dystopian descriptions of ultimately sterile or jarring spaces designed with “comfort” in mind against a backdrop of shag carpeting and pastel surfaces usually intended to inspire placidity. Ultimately, one leaves feeling dysphoric and pit against their personal environment, distrustful of its architects.

Accidentally, the intent and effect of Our Happy Life transpose perfectly into deconstructions of how our digital environment is crafted. As designers, it’s impossible for us to escape the necessity of quantitatively measuring the impact of our software — after all, we do have to contribute to keeping our businesses afloat. However, it’s important to examine and dismantle how we are specifically measuring the way our digital products affect someone’s happiness or quality of life. Are we missing the forest for the trees by only measuring usability and the way our products meet immediate demands? Do you know how your software affects your audience when they’re not using it?

Our Happy Life, exhibition view © CCA

Consider the Environment

It goes without saying that usability and functionality are the most basic tenets on which we build digital products. Our entire workflows and systems are built around testing for understanding, crunching analytics to measure the efficacy of a happy path, and analyzing UI patterns to find more ways to reduce friction. This is all crucial research to perform, but it is frequently the only research that is conducted, and that is a problem. Coincidentally, this is the same problem that lies at the root of Our Happy Life: surface-level research begets surface-level half-solutions, while core issues are left to grind further and agitate. I’m reminded of the AI bot that attempted to write an entire Game Of Thrones novel based entirely on its analysis of George R.R. Martin’s writing style, devoid of any understanding of the actual plot or character relationships.

The first and most important thing UX bootcamp students learn is that User Experience Design is not just about what’s on a screen, but rather, that it concerns every facet of your interaction with a product. Think of a time when you left a movie you were fully immersed in — or woke up from a vivid dream — and felt disoriented or gripped by a very specific feeling. In a way, you were still interacting with those stimuli long after they left your field of view. Even if you stopped thinking about the movie or dream the second you reached your next destination, how did you feel? How did the rest of your day go? Were you productive or distracted? How do you regard that experience now?

Can we find the answers to these kinds of questions with regard to our products? Can we design — honestly — for this kind of response?

Stefano Graziani, photographer. ”Rankings of Happiness 2015–2017,” World Happiness Report 2018. © CCA

Towards Environmental Design — Designing for the Real World

Jakob’s Law of Internet User Experience states that your users spend most of their time on other websites. Contextually, this is meant to suggest that if you’re planning on delivering an innovative feature, it‘s best to fall in line with what audiences are already familiar with elsewhere on the internet so they don’t get confused.

Let’s recontextualize and expand the scope of this principle to include the entirety of one’s daily experience. In 2018, American adults spent an average of 4 hours and 14 minutes per day looking at a computer, smartphone, or internet-connected device out of around 16 waking hours. Lest we forget, personal computers’ original primary purpose was to help us bridge friction in the real world; even 45 years after the Altair 8800, we still use our electronics mainly to connect with others, catalog and synthesize data from the world, and create our own media to be shared widely. Counterintuitive to these purposes, most websites and apps monetize off of engagement and reduce our off-screen time below the roughly 11 hours and 46 minutes we spend away from our devices. How does such nagging — or carelessness! — affect our disconnected hours?

Our Happy Life immediately inspired me to reflect on the products I’ve built and, to an exponentially greater degree, the digital products I interact with. I started evaluating this tech against Amber Case’s fantastic Calm Technology manifesto — does my software pull me out of my environment or task? Does it treat me like I’m a computer, or try to act as though it itself is human? The answer, unfortunately, was “yes” more I would have liked.

Social media is an obvious example of how technology attempts to tap into our most intimate feelings and memories to drive engagement, but even “functional” technology that affects us outside of our phone causes ripples that follow us far beyond our screen time. Consider Waze’s gamification and dogged commitment to back roads. Racking up points is a nice feeling in the rare occasions when a Waze member actually thinks about their ranking. But it’s hard to imagine that makes up for the consequences a shift worker may suffer due to relying on the app and constantly being late as a result of its unfailing preference for lesser-used roads, even when the main thoroughfare is the quickest one. The gamification and alert reporting system also keeps trying to draw users’ eyes to the screen and off the road, making for a drive that is halting and awkward at best, or fatal at worst.

Amazon’s Alexa is a particularly jarring example of this phenomenon, because it becomes your environment once you set it up in your home. It constantly listens for cues to chime in, which not only introduces a new presence into your home, but adds awareness of constantly being watched. Humans tend to act differently when they know they’re being observed, so Amazon voice devices’ ever-presence creates more ambient stress by reducing the amount of places where their users can act completely naturally. By keeping us online even when we’re not looking at a screen, Alexa also attempts to keep us connected during our screenless, private, intimate moments.

Jussi Puikkonen, photographer. View over Helsinki on a summer night, Finland, 2015.

I think it’s crucial that we apply Jakob’s Law to users’ time spent completely offline when building or evaluating our products and be very, very careful about how our creations influence that time. Say you’re designing a money management app or bot, and you’re targeting people who genuinely need help organizing limited finances. These people probably turned to your product because they already have anxieties about money, and at some point, it will have to give them a basic appraisal of their situation. Given that this anxiety is likely continuous and not episodic, what details can we adjust to indicate in order that the product be frank about the user’s situation while still asserting that the situation is manageable?

Let’s walk a slightly less obvious route — imagine you’re creating a website that teaches you how to code. Many online courses attempt to ease you into a state of confidence without realizing you’re getting there, but end up holding your hand through much of the experience, occasionally throwing you blind into a full-scale project largely unsupported. These courses are often geared towards children, for whom frictionless learning prepares them especially poorly not only for a blind final project, but also the real world, and may institute poor expectations for learning or struggle. How can you introduce friction gradually in a way that actively sparks problem-solving skills? Where can you leverage friction in situations where a user may have to make a major decision that will affect either their broader online experience or offline world?

Whatever the case may be, acknowledging the potential for ripples beyond our user flow opens the door for us to design for them. Maybe that user flow could branch or expand beyond interactions directly pertinent to the product and appeal to broader common-sense. Perhaps before asking “How Might We”, we should consider how the basis of our “HMW”s affects our clientele’s entire day, or week, or year. Maybe you don’t need that FOMO-guilt in the copy of your email signup modal, and you probably should bug-test and usability-test the edge cases for your point-of-sale system, because you never know how small barbs in your user experience will affect tertiary users. No matter the specific behavior, we could all stand to zoom out one extra stop and make sure our work in the weeds ties back to that top-level view.

Deeper Testing

More and more articles crop up every day that stress the importance of actually meeting your user base for interviews and testing, which is a really heartening trend that I hope inspires more companies to invest in thorough qualitative studies. As a next step, I’d propose that these interviews and tests are merely an introduction to our audiences. Very few case studies I come across use contextual inquiry, journal studies, or onsite interviews and testing to find out how products are used in users’ personal ecosystems; why don’t we lean on these techniques more?

Letting someone sit with a program unsupervised in a comfortable setting opens the scope of use and removes the pressure of observation, which will then open the door for your subject more honestly attempt to fit your program into their lives (or not). The prompt to report openly allows for more spontaneity to crop up, leaving users open to talk about ancillary effects. On the business end, you’ll also get more honest information about how frequently a subject returns to your app or site, and if they’ve found uses for it that you didn’t expect.

If there’s no time or budget for in-situ studies, even a pre-interview to establish rapport and a follow-up call to gather posthumous feedback and determine if your software has changed the way a subject perceives their current situation adds value to simply working off of whatever they immediately leave on the table. The more you interact with your interviewees as humans and try to understand their human world, the more human insights you’ll receive.

By contrast, when we expect people are anything other than human (against the Calm Technology manifesto), we end up meeting them with our products in the same way that the spaces in Our Happy Life meet their inhabitants.

Healthy Escapism

One important exception worth mentioning is the use case where individuals, especially those beset with mental illness, might scroll through social media or turn to an offline game to take a breather from a stressful real-world situation or spur on latent mental processing. I’ve witnessed this behavior most frequently with Instagram as the “escape app” of choice; while I fully recognize their other toxic engagement behaviors, gently informing users when they’ve seen everything new while also allowing them to insist and keep scrolling is an exemplary model of healthy engagement. If you’re building a site or app where this kind of escape is possible, it is distinctly your responsibility to mitigate opportunities for stressors that mirror real-world ones to creep into the app or, at minimum, show users the door occasionally so they don’t forget where it is. If Instagram can float financially while upholding that responsibility, so can we all.

TL;DR: Design a World You’d Live In

Every day, the line between our digital life and personal life begins to perforate and blur as we creep along the timeline of Moore’s Law; we can’t go on assuming these spheres are so separate any longer and ignore one while architecting the other. At risk of sounding like a broken record, in order to design effective apps and websites, we have to acknowledge that people exist beyond their interaction with our programs and zoom out appropriately in our research and builds. There is more to our impact than measuring where the rubber meets the road.

Leave a comment

Your email address will not be published.