Menu

Posts tagged “user research”

Software should be designed for teachability rather than learnability

Related to the podcast discussion I shared the other day, Andy J. Ko wrote a really good essay called The problem with “learnability” in human-computer interaction. He argues that most software is learned socially, not independently:

We just have to think about our own personal experiences to see that nearly everyone learns how to use all but the simplest software socially, not in isolation. Our friends and family introduce us to new software and teach us how to use it. Our parents call us and ask for help troubleshooting software behavior they don’t understand. Our children teach us about new apps.

He then goes on to ask what it would look like if we designed software for this kind of social learning:

What would it mean to design for teachability rather than learnability? It might mean supporting the creation of not just one tutorial, but a myriad of tutorials, each supporting learners with different prior knowledge and interests. It might mean software companies having their app’s splash screens start with the question, “How do you want to learn this app?” rather than dropping users to a home screen and giving them a few tooltips. It might mean designing software to have teacher modes, where someone could go through and annotate key parts of the interface for someone they are teaching how to use an application (e.g., “Dad, remember to always click this box this before you submit!”).

These are good questions to think about as we work on product onboarding strategies.

Companies have to get better at explaining the data behind personal recommendations

Ryan Bigge makes some very good points in his post about better personalized recommendations through transparency and content design:

Data-driven companies know something that the user doesn’t. Yet the language used to convince people to act on recommendations lacks variety and explanatory power.

Algorithms aren’t neutral — or as Ryan puts it:

Every facet of machine learning is fueled by human judgement, so it must be multi-disciplinary.

Users are getting more skeptical about where these magical recommendations for what to watch, listen to, and buy come from. To establish and build trust, companies have to get better at explaining exactly why they’re recommending a specific product or action.

Users as friends, and other product principles from WeChat’s creator

In Four Key Product Principles from WeChat’s Creator, Connie Chan outlines how Allen Zhang, the Chinese programmer known for creating WeChat and Foxmail, thinks about Product:

The backbone of Allen’s product philosophy is thinking about users as his friends. This means designing products with sincere best intentions for the users and putting their interests above all others — even company stakeholders. For Zhang, the importance of always putting the user first is very simple: “Only when we treat users with genuine empathy will our products be used for a longer time.” What this means to Zhang is that product design should not be reduced to “processes” that can be continuously optimized by data-driven teams. He believes there is an amount of whimsical inspiration that process optimization cannot solve for.

The whole profile is worth reading. Zhang is inspiring, and we need more product thinking like this.

The product manager’s battle between ego and customers

It’s a bit of an uneven piece, but Peter Krmpotic’s What’s the Secret to Becoming a Great Product Manager? makes some good points about ego vs. customer focus:

The ultimate goal for product managers and product leaders is to instinctively focus on the customer and not their own egos. This is hard since it is natural to be self-centered and unnatural to be customer-centric.

In Scott Belsky’s recently published book “The Messy Middle”, he highlights how we are hardwired to prefer short-term rewards, because delayed gratification causes anxiety and discomfort. Thus, I think the main career-long objective for product managers is to reprogram themselves over time from being self-centric to customer-centric, to get the urge of acting on their own ideas out of their system. Or as Belsky puts it, “to hack their reward system”.

Human-centered design is not enough

Very interesting article by Anab Jain arguing for More than Human-Centered Design. We need to move beyond ourselves and consider the things around us:

Interdependence is a powerful concept for me: different participants—human and non-human—are emotionally, economically, ecologically or morally interdependent on each other. And this reliance is acknowledged. I think this perspective is something that would be very meaningful for many of us to consider—whether we’re interaction, service, or UX designers, entrepreneurs, researchers or people who put things out in the world for others “to use”.

Have a look at the article for further thoughts and some practical examples.

Who designers work for

Mike Monteiro isn’t always everyone’s cup of tea, but I really like his views in Design Ethics & the Truth About Who Designers Really Work For. In short, designers need to work for users:

When you hire me as a designer, I do not work for you. I may practice my craft at your service, but you haven’t earned the right to shape how I practice that craft. One, you don’t want me designing at your level, you want me designing at mine, which means you don’t get to pull the strings. I do. Two, you’re hiring someone who performs a service, not a servant. There’s a difference. I’m not there to do your bidding, I’m there to solve a problem or reach a goal that we agreed upon.

More importantly, designers work for all users, not just the ones who look like them…

And your job, the glorious job you signed up for when you said you wanted to be a designer, is to support all of these people. Make sure none of these incredible voices get lost. And to fight against those who see that brilliant cacophony as a bug and not the greatest feature of all time.

You are our protection against monsters.

The benefits of buttons that don’t do anything

CNN has an interesting article about placebo buttons:

In New York City, only about 100 of the 1,000 crosswalk buttons actually function, confirmed a spokesperson from the city’s Department of Transportation in an email.

The article quotes Harvard psychologist Ellen Langer for the reasoning behind this:

According to Langer, placebo buttons have a net positive effect on our lives, because they give us the illusion of control — and something to do in situations where the alternative would be doing nothing (which explains why people press the elevator call button when it’s already lit). […]

In the case of pedestrian crossings, they may even make us safer by forcing us to pay attention to our surroundings. And ultimately, pressing a button doesn’t require much effort.

The BCC had a similar article a couple of years ago. Press me! The buttons that lie to you also quotes Ellen Langer, because there is nothing new under the sun:

But instead of framing this as an irrational delusion, Langer described the effect as a positive thing. “Feeling you have control over your world is a desirable state,” she explains. When it comes to those deceptive traffic light buttons, Langer says there could be a whole host of reasons why the placebo effect might be counted as a good thing. “Doing something is better than doing nothing, so people believe,” she says. “And when you go to press the button your attention is on the activity at hand. If I’m just standing at the corner I may not even see the light change, or I might only catch the last part of the change, in which case I could put myself in danger.”

The stress of interacting with voice UIs

This bit from Raluca Budiu and Page Laubheimer’s user study of digital assistants like Alexa, Google Assistant, and Siri echoes my thoughts exactly on why I don’t like interacting with them:

Many participants started speaking before formulating the query completely (as you would normally do with a human), and occasionally paused searching for the best word. Such pauses are natural in conversation, but assistants did not interpret them correctly and often rushed to respond. Of course, answers to such incomplete queries were incorrect most of the time, and the overall effect was unpleasant: participants complained that they were interrupted, that the assistant “talked over them”, or that the assistant was “rude.” Some even went as far as to explicitly scold the assistant for it (“Alexa, that’s rude!”).

Yep. When I interact with voice UIs I spend way more time and energy planning the exact sentence construction and pronunciation than when I simply type and swipe and figure it out as I go. And then, if one word is out of place, the whole thing falls apart. It’s just too stressful. I can’t.

“One Laptop Per Child”: a great solution to the wrong problem

Do you remember the “One Laptop Per Child” project? The PR event made a huge splash back in 2005, and I remember being really impressed and inspired. As it turns out, OLPC is a textbook example of what happens when an organization has a sincere desire to solve a problem that they simply don’t understand.

Adi Robertson, writing for The Verge, has an excellent history of the project called OLPC’s $100 laptop was going to change the world — then it all went wrong. It starts with this anecdote:

Then, Negroponte and Annan rose for a photo-op with two OLPC laptops, and reporters urged them to demonstrate the machines’ distinctive cranks. Annan’s crank handle fell off almost immediately. As he quietly reattached it, Negroponte managed half a turn before hitting the flat surface of the table. He awkwardly raised the laptop a few inches, trying to make space for a full rotation. “Maybe afterwards…” he trailed off, before sitting back down to field questions from the crowd. […]

If you remember the OLPC at all, you probably remember the hand crank. It was OLPC’s most striking technological innovation — and it was pure vaporware. Designers dropped the feature almost immediately after Negroponte’s announcement, because the winding process put stress on the laptop’s body and demanded energy that kids in very poor areas couldn’t spare. Every OLPC computer shipped with a standard power adapter.

As you read deeper, it becomes clear that they were working on a solution that didn’t take local issues into account at all:

Bender thinks OLPC might have struck more deals if it had focused less on technical efficiency. “Every conversation we ever had with any head of state — every time — they said, ‘Can we build the laptop in our country?’” he says. “We knew that by making the laptop in Shanghai, we could build the laptop [to be] much less expensive. And what we didn’t realize was that the price wasn’t what they were asking us about. They were asking us about pride, not price. They were asking us about control and ownership of the project.”

To put it another way:

OLPC had created a computer that could withstand dust and drops, but it hadn’t accounted for political messiness.

There are many lessons to learn from this story, but most important is almost certainly that a desire to do something good isn’t enough to make a product successful. If you don’t fully understand the problem you’re solving and the people you’re solving it for, your chances of success are incredibly low.

The role of instinct in product development

As a product manager I know and understand the importance of making customers part of the product development process through research and interviews. Especially those of us who come from a design background have this philosophy deeply engrained. We know that “I am not the user” and we have the t-shirts to prove it! So it is with some surprise that I recently realized that sometimes — when the circumstances are conducive to it — it’s ok to trust our instincts and create products and features without talking to customers directly about it first.

See, the thing is, talking to customers isn’t something we do, it’s something we are. And if it’s something we are — if we really are immersed in our customers’ needs and behaviors and emotions — we should feel comfortable to trust our own instincts a little bit more.

With this kind of immersion comes an ability to channel our customers in a way that drastically reduces the additional benefit we might get from interviewing them about a specific issue or feature. When we not only have the knowledge of the domains we work in, but also a good understanding of how our customers navigate those domains, we end up with a powerful foundation to base our decisions on.

Does this mean we don’t need research? Of course not! But it means that maybe we don’t need to go out and interview users every time we make a product change or introduce a new feature. It means maybe we do usability testing on major changes to the site, but not when we fix something that we’ve lived and breathed with our customers for months or years.

Those are weird sentences to write. I am a big proponent of User-Centered Design, and obviously research is a central component of that. But what I’m advocating for isn’t less research. I’m saying that it’s possible to reduce the amount of structured research you do, if you have a culture of customer immersion in everything you do.

Customer immersion isn’t an easy culture to create, but it is very much worth it. As a start, everyone in the organization should be encouraged and empowered to talk to customers — whether that is through phone calls, support cases, conferences, or any other way you might be able to reach them. And since not everyone will be able to spend an equal amount of time with customers, it also means you have to listen to those who do spend a lot of time with them — and trust that they are acting as good conduits for customers’ needs.

Making the right choices about when to do structured research and when to trust your (informed) instincts will save you time and money — and make customers happy too. That’s not a bad combination of benefits.