It’s always inspiring to read about the early days of an idea. About the doubt, the pushback, the impossibilities, the models telling you it’ll be too expensive, the “but, but, but…”, the breakthroughs, the vision, and the drive when you just have a hunch. The knowing that there’s no way to know until you try. These moments are often wrapped with unusual combination of vulnerability and confidence. I find them fascinating. Here’s an oral history of how Amazon Prime came to be.
Debates continue to rage about the role of UX designers, user research, and how far knowledge about the user should permeate the organization. On one extreme, UX is seen as a specialized pocket of knowledge that informs the definition of projects and sets requirements. On the other, UX is something for which the entire organization should somehow feel responsible.
A few concepts can facilitate a deeper discussion by drawing meaningful distinctions.
- UX at the boundary between supply and demand
UX happens at the boundary between what is technically possible and what is fitting for the problem at hand. The canonical picture for this boundary is the client/firm relationship. The firm knows how to do a lot of things. The client wants something in particular. The firm tries to understand the client as well as possible to do what they want (create “value” in business jargon.)
This boundary happens at different points within a company too. Each boundary can be viewed from the supply side or the demand side. Somebody knows how to make something (supply) and somebody needs something (demand). These two perspectives meet at each link in the value chain.
For example, programmers program something according to some kind of requirement. The requirement is set according to some understanding of the problem. The person who’s responsible for understanding the problem is looking at it from the demand side, while the person who’s responsible for finding a solution to that problem is looking at it from the supply side. Or the same person may be doing both by alternating their perspective from demand side to supply side.
Often when we’re talking about UX we assume a view from the last link in the chain: the end user. Knowing explicitly which link we’re talking about can inform the discussion. For example, the user and the buyer might not be the same person. They both need “UX.” To clarify what that means and who’s involved we can make the boundary explicit. The parts of the supply side at the buyer boundary (marketing, sales, product features in macro) will be different from the parts at the user boundary (onboarding, interaction flows, back-end performance).
The concept of supply/demand boundary lets us think about how far down to go too. Consider a freelancer who builds on WordPress. The design of WordPress is affecting the UX from the most macro perspective. But from the perspective of the freelancer, WordPress is a constraint on their supply side capability and it’s her job to adapt its potential to the demand of the client.
2. Modular vs integrated boundaries and UX
The boundary between two links in the chain can be of different types: either a distant third-party style relationship or a more intimate “let’s solve it together” relationship. The freelancer using WordPress is an example of the former. A designer and programmer teaming up on an interface concept is an example of the latter. Following Clay Christensen’s lead, we can call the former ‘modular’ because there’s a standardized interface and the latter ‘integrated’ (he calls it ‘interdependent’).
This distinction describes the organization of the people who provide the supply to fit the demand. Some teams are small and intensely collaborative. They talk directly to the customer and then sit around the table together to architect the solution. In that case the boundary between requirement setting and programming is integrated.
Often when a company grows beyond a certain point the boundary modularizes. This means there’s a formal interface (aka handoff) at the boundary with some procedure for how information from the demand side is communicated to the supply side. An extreme example of this would be the relationship when one team creates specs for the project and another team fulfills those specs. Each has a different boundary. From the spec creator’s perspective, the demand side would be the use case they are looking at to design the spec, while the capabilities of their technical team are the supply side. From the spec fulfiller’s perspective, the demand side is the spec itself and the supply side is their knowledge, toolset, and stack. Both do “UX” in the sense that they want to provide the best experience to the demand side of their boundary. But they don’t all sit at that last boundary with the end user.
This doesn’t make a good/bad judgment about how to organize. Different organizations suite different constraints. Generally speaking, if the problem has been solved a hundred times already, the organization can modularize. On the other hand if the solution has never been done before, more integration is required between links in the chain. That’s why at Basecamp our designers and programmers work tightly together to design a brand new feature. Or Apple had to create its own Pencil that integrates with the glass under the iPad to outperform capacitive styluses.
3. Domain specific vs. domain independent UX
A third distinction we can make is between the knowledge and skills that improve UX in general versus for a specific domain.
Domain specific UX means understanding how the supply should fit the demand considering a specific situation and use case. For example, imagine a user of a task management tool is walking from their office to the parking lot and they suddenly think of a task for their team. They try to add the task on their phone before the forget it, but it takes so many steps to file correctly that they struggle to remember the task in the middle of the process. This is specific knowledge about a specific problem that would inform the UX of the mobile product design.
On the other hand, many aspects of UX don’t require knowledge about a particular situation. They‘re based on the common constraints of human sense faculties, memory and cognition or the net of ergonomic factors around the device and the setting where it’s used. These domain independent elements of the UX are important too. They make up much of what the early usability movement wrote about. A specific example would be using labels on icons instead of icons alone so users understand their meaning.
These types of UX problems are the subject of books like Norman’s The Design of Everyday Things or Tufte’s The Visual Display of Quantitative Information. Those examples are at the interface design boundary. For the back-end, Evan’s Domain Driven Design or Fowlers’ Refactoring show how to provide better UX to consumers and editors of the API.
Domain independent UX should absolutely pervade the organization. It belongs to the general skill and knowledge of each supplier at their link in the chain. It’s part of learning to be a good designer, programmer, marketer, salesperson etc. Looking at the firm as a whole, domain independent UX belongs to the supply side.
Domain specific UX is different because there’s a new cost to acquire it for each customer, product, or use case. If an interaction designer wants to increase their domain specific knowledge, they have to stop designing interfaces and go research for a while. Then they have to analyze what they learned and synthesize it into conclusions that are general enough to create requirements and design against. Looking at the firm as a whole, domain specific UX belongs to the demand side. It’s about understanding what to produce and sell.
Whether or not everyone in the firm needs domain specific knowledge depends on your architecture. A company with modular boundaries between teams will need to modularize the acquisition of that knowledge. In other words, specific people in the organization take the time to do research. Their requirements constitute the domain specific UX.
On the other hand a company with integrated boundaries could alternate how they spend time. Sometimes researching the customer’s situation, other times designing a fitting solution.
Which approach is appropriate will depend on the size of the company, the complexity of the use case, the complexity of the technology, and other factors.
Hopefully these concepts can help move discussion about UX to a deeper level, enable designers and researchers to think more rigorously about their place in the organization, and give companies tools to better apportion responsibility for different types of knowledge and decision making.
Update: See the discussion in the comments below for a more concrete example of how these concepts apply in practice.
We don’t ask ourselves this enough. Here are 6 critical questions to reflect on when considering if you should become a manager or not.
When we’re asked, “Do you want to become a manager?” we often assume there is only one answer.
“Oh, of course I want to be a manager.”
Right? Who doesn’t? Especially when becoming a manager is seen as the primary path of upward progression in a person’s career.
But do you truly want to become a manager? Management is not some sacred club reserved for the hallowed few. Rather, deciding to become a manager should be viewed as one might decide to become a garbage disposal collector or a parking meter attendant: If you’re doing it, you’re doing it for a reason. It’s not for everyone.
The title of this post is how Kenneth Coats described the feeling of leaving his office job to start his own business. After he unplugged from the Matrix, he simply couldn’t return—not even when a challenge from the Illinois Attorney General forced him to shut down his first venture, a service to help people expunge their arrest records. In this episode of the Rework podcast, Kenneth shares the story of how he pivoted, and the drastic move he took to make sure he couldn’t go back to his old work life. Listen below, or click “Keep Reading” for a full transcript of the episode.
All-hands support can be a touchy subject for customer support professionals. When you ask designers and programmers to reply directly to customers’ questions, doesn’t that imply that anyone can do our job?
At Basecamp, we learned the hard way that you shouldn’t expect other people to be able to do the work of your support team. The good news, which I shared at the Support Driven Expo Europe 2019, is that we’ve found new ways to leverage people’s existing skills into valuable work which helps improve things for our customers, our team, and the company as a whole.
If you’d like to learn more, watch my talk, “Everybody helps: the evolution of all-hands support”:
If this sounds promising, I have some tips on rolling out all-hands support at your company. And if you’d rather read my talk than watch it, click through to the full post.
As a leader, the most costly mistakes are often the most imperceptible.
I’ve never met you, but I’m going to make a guess about you: You’re making leadership mistakes you don’t even know about.
I don’t mean to sound presumptuous (or crass!). I’m in part reflecting on personal experience – I’ve made a boatload of leadership mistakes, myself.
More objectively, I’m citing probability: Gallup’s research on millions of managers over the past 7 years revealed that companies choose the wrong manager 82% of the time. And if that’s not disconcerting enough, they found only 1 in 10 managers possess what they describe “the natural talent to manage”.
It’s desperate times for those still clinging to their workaholic, exploitive ways. From Japan to China to even the US, there’s a growing understanding that working 70-80-90 or 130 hours per week is not glorious. Not virtuous. Not healthy.
So what’s a whoever-works-the-most-wins advocate to do? Sidestep the question of efficiency, of health, of sustainability, of course. Just press the pedal on fear and competition. Here’s your host of terror, Jason Calacanis:
Yeah, that’s it. Those who reject the wisdom of overwork is really helping the ENEMY. This is democracy vs communism!! What is this, 1950? Whatever year it is, it’s stupid.
Rather than support a grassroots rejection of the exploitive abuse of the Chinese workers under the 996 regime, Calanis is doubling down on the premise that to “beat” the Chinese, you must submit to their worst work practices. What?
This is at best a lateral move from “work harder or the kitten gets it”. A trope that’s meant to be a punchline, not a policy recommendation.
Besides being imperial paranoia, urging American companies to adopt Chinese abuses, lest they be left behind in the chase of growth uber alles, is the furthest away you could get from winning. Accepting the terms of engagement by your so-called opponent is a basic, rookie mistake in any form of strategic out-maneuvering.
You’re not going to “beat” the Chinese by one-upping 996 with 997. You’re not going to top Jack Ma’s calls for sacrifice by injecting nationalist fervor and clash-of-civilizations rhetoric into these base pleas for a deeper grind. This is madness.
If you define winning solely as “who has the greater growth”, you’ve already lost. If you dismiss the standard of living enjoyed in Europe – one without medical bankruptcies, crushing college debts, or falling life expectancies – as a “retirement society”, you’re the one who deserves to be dismissed.
The ideological underpinnings of capitalism are already in an advanced state of ethical decay. You don’t save the good parts of said capitalism by doubling down on the worst, most exploitive parts. Racing to the bottom just gets you there faster.
As we write in “It Doesn’t Have to Be Crazy at Work“, you should treat your company as a product too. To improve a product, you listen, learn, (re)consider, concept, and iterate. The same approach should be used to improve your company itself. How you work, how you manage, how you develop and communicate policies and procedures should all improve through iteration as well.
With that, we wanted to share how we’re improving through iteration on the inside. We recently updated our Employee Handbook (which anyone in the world can read) to clarify a few key points:
First, what are the different responsibilities of an executive vs. a manager vs. an individual? At some level the differences are obvious, but at the edges it’s not always clear. And where there’s murkiness, there’s often confusion and then conjecture. In the pursuit of clarity, we recently added a section to the handbook defining these responsibilities.
Second, what happens if an employee finds themselves in a situation where their performance has been called into question? Not knowing where you stand when there is a problem – or not even realizing there’s a problem at all – is an uncomfortable and unproductive place to be. You can’t do your best work when your mind is riddled with anxiety stemming from existential questions about job security. To clarify the process for helping identify and resolve such problems, we recently added a section to the handbook that details our newly formalized performance plan process.
Third, what does it look like to build a career at Basecamp? At many software companies, work is a job – and a relatively temporary one at that. The average tenure at Amazon and Google is only around 12 months. At Basecamp, our average tenure is 5 years (our team page shows how long everyone’s been here). Given that, it’s important for us to define what progress looks like at Basecamp. To help clarify those details, we recently updated our handbook page on making a career at Basecamp to include more details on progression, titles, pay and promotion, and the review process.
As you can see from the last updates times/dates on our Handbook, how we run the company, and how we explain how the company runs, is always being updated. Our Employee Handbook isn’t printed and forgotten. There’s no been there, done that. It’s not a project that ends. Rather, it’s continually updated updated and republished. And while some pages may be steady at a few years old, many have been updated within the last few hours, days or months. We’re always aiming to be clearer, fairer, and better, and we find that publishing our Handbook out in the open is an especially handy way to keep us improving – and honest about how we do it.
We believe publishing how a company works is a public good, not a private act. When customers choose to buy your product, they should know what kind of company makes it. We think that the more open we can be about our internal practices, the more comfortable the public – our customers – can feel about doing business with us. Spending money with a company is essentially voting for a company. We want our customers to feel proud when they vote for us.
I’ve always loved this kind of design. It’s clear, it’s colorful, it’s honest, it’s approachable, it’s folksy, it’s effective. ALL CAPS works. “NO JOB IS TOO SMALL” is impossible to improve on (it also says this in huge letters on the front of the truck). “Rain, sleet, or snow the gutters must flow” rhymes (and they’re right!). You could argue that the URL is too small, you could say it’s messy because there are too many colors, fonts, styles, etc. But I’d say so what? How does any of that make this a bad advertisement on the side of a truck? It’s beautiful – and ugly – in all the right ways.
Wouldn’t it be great if there really was just one secret you had to know, and all your professional or entrepreneurial dreams would come true? Then you wouldn’t have to bother trying what works for your or your domain. You’d just have to apply The Secret, and voila!
Needless to say, if there is such a unifying secret, I haven’t found or heard of it. And yet, I keep seeing this false hope powering one of the most common questions I get in interviews: What’s THE ONE THING that you’d tell your younger yourself/other entrepreneurs/new programmers?! This is followed by the breathless anticipation of whatever profound wisdom the questioner most wish they could glean from my life’s experiences.
The boring truth is that the big leaps are all the result of an interwoven tapestry of practices, each contributing a strand of progress or insight. If you pull just one, all you have is that thin, disconnected strand. It’s only together the colors come alive.
That’s why all the books Jason and I have written together really are just a collection of essays. Yes, there’s a theme, but no single, unlocking narrative. REWORK is 88 separate essays, It Doesn’t Have To Be Crazy At Work has 66.
As long as you’re stuck on a quest for that one super-power practice or North Star principle, you’re not going to make space in your brain for the fact that no individual secret is going to make the difference. Only compound wisdom will.