In The Value of Inconvenient Design Jesse Weaver discusses the role of user friction in design — the things that slow us down from getting a task done — and how the goal is not to remove all friction from our product flows:

The friction of the checkout process provides a check against impulse purchases and overspending. In a world where many people struggle to manage their money, these small barriers can be critical to maintaining financial balance. While the market would dictate that it’s not Amazon’s job to help its customers control their spending, lowering the barrier to impulse purchases could have a net negative effect on the value people get from Amazon’s service. The Dash button, for example, eliminates so much friction that customers may not even know how much they’re spending until after they’ve completed a purchase. In light of this, Amazon Dash was recently deemed illegal in Germany for violating consumer protection laws.

If you’re interested in the topic of “frictionless design”, here is some related reading. Clive Thompson digs into software that aims to add friction to our lives in his Wired essay We Need Software to Help Us Slow Down, Not Speed Up:

It’s certainly possible to slow our software, and thereby ourselves. But it’ll happen only when we become too unsettled by the speed of our journey.

Here is Chris Palmieri in A Practice of Ethics:

But some friction is borne of respect, when we present information about the choices available to users and help them make better decisions. An emailed invoice could remind a customer they were paying for a service they no longer use. A checkbox could assure a user of their current content privacy settings before posting a sensitive photo. Recognition of a past purchase can save a customer the hassle of having to return a book they already have, or confirm that they are re-buying exactly the same shampoo.

And Andrew Grimes in Meta-Moments: Thoughtfulness by Design:

Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.

In short, not all friction is bad…

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.

I found this discussion on the Product Love podcast really interesting. Eric Boduch talks to Adam Avramescu (Head of Education at Checkr) about the importance of educating customers on how to use your product. They cover a bunch of topics, including the myth that you don’t need education if your UX is good enough, the right way to approach documentation, and how onboarding is an important part of customer education but not the only thing you need.

Listen on Soundcloud or Overcast.

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.

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.

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.

There are some great product tips in Scott Belsky’s How to Shape Remarkable Products in the Messy Middle of Building Startups, but this part about onboarding particularly stood out for me:

You can’t expect new customers to endure explanation. You can’t even expect customers to patiently watch as you show them how to use your product. Your best chance at engaging them is to do it for them — at least at first. Only after your customers feel successful will they engage deeply enough to tap the full potential of your offering.

One of the hardest things to figure out with onboarding is the right balance of selecting defaults (“doing it for them”) and having users learn by doing things themselves.

For example, within Postmark’s onboarding a continuing debate is whether or not we should auto-create a user’s first “server” for them, or help them understand the concept better by making them do it themselves. Finding the appropriate amount of friction to introduce is an ongoing and important challenge for any product’s onboarding.

Empowered Product Teams is another gem of a post from Marty Cagan. This part stood out to me:

In most companies, technology teams exist “to serve the business.” That is very often the literal phrase you will hear. But even if they aren’t explicit about it, the different parts of the business end up driving what is actually built by the technology teams.

However, in contrast, in strong product organizations, teams exist for a very different purpose. They exist “to serve the customers, in ways that meet the needs of the business.”

The distinction is subtle, but important. If you only serve “the business”, you’re going to make decisions without asking whether something is user-hostile or not (see, for example, scroll-jacking, or Twitter’s tendency to “forget” that you prefer a timeline that shows latest tweets). Bringing customer needs into any conversation about business needs is the way to build something that’s profitable and sustainable.

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.