Products need not be user centered

Putting the user first has always been the golden rule in design. It’s so common that nobody really questions it anymore. We’re told, ‘The user knows best. Listen to them.’

I’ve had my skepticism about the framing of the term — user-centered design. I’ve kept myself from voicing this apprehension, afraid of being dismissed as an outright blasphemy in the design circles. However, having shifted gears from design to PM roles, I feel more comfortable expressing a spicy hot take that — Products need not always be user-centered.

So what’s the problem here with user-centered design?

Imagine you’re crafting a product for Michael Johnson, a fictional character representing the ‘average’ user: a 38-year-old IT project manager juggling work and family life. This approach, while seemingly comprehensive, inadvertently overlooks the diverse spectrum of users with unique needs and preferences. This is the essence of the ‘long tail problem’ as articulated by Kasey Klimes. It states that focusing solely on the average user risks marginalizing those outside this central demographic. The product ends up serving the gaussian middle.

User-centered design by default tends to get optimised for the average. It implies a focus to the right profile of a user. And that’s NOT always the right approach. We just have so much variance in the users, that I sometimes wonder: how do we expand the scope of a product from the gaussian middle to the long tail?

There is a way of addressing the long-tail problem, but it requires a very different paradigm for thinking about the way we design products, tools, and services. We can call this paradigm design for emergence. — Kasey Klimes, Design for emergence

Fortunately, there is a new kid on the block — and that’s design for emergence. This concept finds its roots in Seymour Papert’s emphasis on ‘low floors’ and ‘high ceilings’ in technology. According to him, technology should be accessible for beginners (low floor) yet offer advanced users the scope for complex projects (high ceiling). Think of LEGO, with its simple yet versatile bricks, offering endless creative possibilities — that’s this philosophy brought to life.”

Low floors: could make any object with the least number of pieces. High ceiling — you could even make Optimus Prime from Transformers if you really want to

Subway is another example. A sandwich is made composable. You can choose your toppings, the patty, the sauces in a truly unique way. There is no one ‘right’ way for the ‘right’ user. There are multiple ways for multiple users. By designing products with low floors, wide walls and high ceilings, every fringe user can now use the product the way they want it. Even coffee has become ‘composable’ this way.

An example of how a sandwich is made composable

Designing for emergence is just that. Products with “low floors” and “high ceilings”. Let’s take a couple of digital examples where this has stood out:

Taking Notion for example, where a document processor becomes infinitely composable through infinite ‘content blocks’.

Zapier makes automations infinitely composable through its automation blocks

Arc makes browsers infinitely composable by providing users the ability to make multiple workspaces and customising it the way they want. They even go further providing art tools to even choose the font and styling of the user’s apps

If we classify software in terms of an axes between convention and configurability, on one extreme, you have the DIY types: like Notion built on the principle of composability through content blocks. On the upside, you see people use Notion for all kinds of purposes such as — wiki, project management, CRM, documentation etc. Notion definitely has a high ceiling. However, on the downside, it suffers from ‘too much’ composability leading to featuritis. Features keep getting added, which affects the speed, stability and performance in the core features that defines the essence of Notion (high floor)

Configuration through composability is great. But there are times when you would rather choose a full course buffet curated by a chef, than being given 100 different options to choose and customise on your own. This is where the other extreme lies. Design which chooses convention over configuration. Ruby on Rails is opinionated software, where a team of chefs have picked ingredients on our behalf. As DHH puts it, it isn’t meant to appeal to the taste of everyone, everywhere. This works great when the user doesn’t really know what to look for.

_There are lots of à la carte software environments in this world. Places where in order to eat, you must first carefully look over the menu of options to order exactly what you want…Rails is not that.

Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn’t designed to appeal to the taste of everyone, everywhere.

When we, or in some cases I — as the head chef of the omakase experience that is Rails — decide to include a dish, it’s usually based on our distilled tastes and preferences. I’ve worked in this establishment for a decade. I’ve poured well in the excess of ten thousand hours into Rails. This doesn’t make my tastes right for you, but it certainly means that they’re well formed. —_ DHH on this blog.

Apparently, it’s not just DHH and Ruby on Rails, but also how Tesla was envisioned by Elon Musk:

This is how we create Tesla products
pic.twitter.com/DsmisqDGSp

— Elon Musk (@elonmusk) January 3, 2024

Taking these different philosophies into account, it would be harmful to consider ‘user-centered’ design as the only way to build products. You can design products in DIY, composable ways as illustrated by LEGO and Roblox. Or in Omakase, conventional way as shown by Ruby on Rails.

Products need not always be user-centered. It can be emergent too, accomodating a varied spectrum of users to use the product.