Building a Better Train to Brooklyn

Rosanna lives in Brooklyn so I take the train a lot.

More specifically, I take the 6 train to Union Square. Then at Union Square I transfer to the L train which brings me from Manhattan to Brooklyn.

A few days ago I was walking to catch L when I started thinking: how could I build a better train to Brooklyn?

As you might imagine, this isn’t a simple question to answer. The problem is huge. You’re not just designing trains – you’re designing stations, signage, schedules – a whole system. I don’t even know much about trains – it seems like I couldn’t get very far.

If I wanted to design a better train I might do something like the following:

First I would think about the trains that I take every day. I would think about all of their features and start writing them down because I would probably need those features in my train as well.

I’d write down the name of the train. The way its logo looks. I’d write down how its seats look, and maybe estimate how many passengers could fit in each car. I’d think about what the railings will look like for people to hang on to when they’re standing on a crowded train.

After copying the basics I might add a few new features – twists on the traditional train concept that will make my train different: What about if, instead of sliding out, the doors, like, slid up when they opened? Kind of like one of those DeLoreans. These will be my key differentiators from other trains out there on the market.

Then I’d start sending out emails with phrases like, “Groundbreaking,” “Innovative,” “Dent in the universe,” and my personal favorite, “All I need is to find someone to build it for me.”

I know this is a tempting way to go about it because I have done this. And I’d be willing to bet most anyone who has ever tried to build a product has done it too.

The problem is: it doesn’t work.  If you’re working alone you feel lost a lot. It feels like there’s a huge gulf between what you’re trying to accomplish and the tools you have to accomplish it.

If you’re working as part of a team you tend having long, heated arguments about which features to include that are mostly won by the person who’s most convincing – not the person who’s right.

So, obviously we need a better way to figure out questions like:

How do I decide which features to include in my product and which ones to leave out? How do I know if one of the new features I’ve come up with is a good idea?

That’s what I’m going to talk about in this blog post. What I want to do is explain exactly what’s wrong with the process I described above. Then I’m going to propose a better way of looking at things to make designing high quality products easier (but not easy.)

Then I’m actually going to show you how you might start building a better train to Brooklyn.

Let’s get started
If we want to build a better train to Brooklyn, the first thing we have to do is think about this: what is a feature? What is this thing that I’m copying from someone else?

Often when we talk about a feature we think about what it does:

“The doors should slide up.”

In product design we might also call this a requirement. And, as I mentioned before, a common way to build products is to compile a list of requirements and then start building.

But if we start by just thinking about features we’ve already lost. When we debate at the level of features we’re often not doing product design at all – we’re really just playing what I call product mad-libs.

Product mad-libs
Suppose we were writing novels instead of building products. Slaughterhouse Five begins with this paragraph:

All this happened, more or less. The war parts, anyway, are pretty much true. One guy I knew really was shot in Dresden for taking a teapot that wasn’t his. Another guy I knew really did threaten to have his personal enemies killed by hired gunmen after the war. And so on. I’ve changed all the names.

Suppose that I want to write my own novel. I could take the basic structure of Vonnegut’s prose, and put my own spin on it by replacing his nouns with my nouns, and his verbs with my verbs. I could write something like the following:

All this happened, more or more. The war parts, anyway, are pretty much blue. One storm I knew really was flown in Alice for taking a dream that wasn’t his. Another storm I knew really did threaten to have its friendly enemies killed by peaceful gunmen below the war. And so on. I’ve changed all the games.*

Although my version is totally grammatically correct, it doesn’t mean anything. There’s no reason behind the structure.

When we debate at the level of features we’re basically saying to ourselves:

“The doors could slide ‘sideways,’ ‘up,’ or ‘down.’ How should I fill in the blank?”

We then answer ourselves with: “Well, the L train’s doors slide sideways so maybe mine should slide up.”

But when we do this we forget that just because a feature is grammatically possible – just because you can fill in the blank and have it make sense – doesn’t mean it benefits or improves the end-product that you’re designing.

Which one is better?
Think about it this way. What if I asked you:

“What’s better, a hammer or a shovel?”

You might say hammer, and I might say shovel. We could debate for hours over the merits of the particular tools.

But that’s not useful because the correct answer to this question is:

“What problem are you trying to solve?”

If you’re trying to dig a hole, then a shovel is better. If you’re trying to pound a nail, then a hammer is better.

Instead of playing mad libs with your feature list there’s a much better way of deciding what kinds of features your product will ultimately have – but it doesn’t involve talking about features at all (at least at first.)

Mapping the context
In his book Notes on the Synthesis of Form Christopher Alexander, an architect and scientist, describes a method of attacking design problems that helps to reduce the gap between our limited cognitive capacities and the difficulty of designing complex forms.

He starts by telling us that every design problem is really a process of creating good fit between two things: the form you are designing and its context.

The language may seem confusing, but he’s actually talking about two very simple things. By form he means the thing that you are designing. By context he means the environment in which the thing you are designing is going to exist.

Alexander believes that the context is made up of many interacting forces – some of which compliment each other and some of which contradict each other. The goal of the designer is to create a form that brings into harmony the conflicting forces in the context within which it exists.

What he’s found in his work as an architect is that by deliberately mapping these interacting forces that make up the context, you can create a picture of the design problem that makes a solution much easier to find.

If you think of the context as a question, then the ultimate form you come up with is the answer.

He writes, “The form is the solution to the problem; the context defines the problem.”

Alexander likens this concept to that of well-adaptedness in biology: just like an organism is fit when it is well-adapted to its environment, an object is well designed when it fits its context.

The obvious next question is: how do we find good fit? Alexander’s explanation is strikingly similar to Nassim Taleb’s concept of via negativa: rather than trying to create good fit itself, you create good fit by identifying and eliminating instances of bad fit.

Alexander believes that the key to good design is not coming up with an endless list of requirements, but instead to identify and list all of the areas which are likely to result in bad fit.

If we think about things this way, it becomes a little bit easier to represent a design problem more formally. For example, consider a list of potential misfits for riding a train to Brooklyn:

  1. I don’t want to have to walk far to get to the train
  2. I want to transfer as few times as possible
  3. I want to to be able to use my phone while in transit
  4. I want to be able to sit down on longer journeys
  5. During rush hour I don’t want to be delayed
  6. During rush hour I want to be able to have personal space (not be crammed like a sardine)
  7. I don’t want to spend more than a few dollars per trip
  8. I don’t want to carry around cash in order to get on the train

Now that I have a list of misfits, my train design process just got a lot easier. Every time I solve misfit I cross it off my list. When everything’s crossed off, I’m done.

But hold on a minute, things aren’t that simple. A lot of these misfits are interdependent. For example, one misfit is “I want to be able to sit down on longer journeys.” Another one is, “During rush hour I don’t want to be delayed.” And yet another one is, “I don’t want to spend more than a few dollars per trip.”

Clearly there are contradictions here! How can you expect to be able to sit down, not be delayed during rush hour, and not spend more than a few bucks? What we’ve found is that many misfits are interdependent. So if we go around solving each misfit in random order, we’re certain to cause new misfits in other areas. It would be like playing whack-a-mole with your product design.

What Alexander suggests is, instead of solving misfits at random, it’s best to group the misfits together.

The way to do this is to find potential misfits which are interdependent and make sure they’re in the same group. The ideal result is to break up your long list of misfits into little groups each of which are insular and interconnected, but not highly connected between each other. Then go to work optimizing one group at a time.

The groups that you come up with are roughly analogous to one part of your product. Sometimes they represent one feature, and sometimes they represent a group of highly interrelated features.

Once you’ve optimized these groups of forces you can build the components together to form the completed design.

Getting back to product design
So, how do we relate Alexander back to our original question of building a train to Brooklyn?

Well it seems obvious now, that before we can think about the form we’re creating, we have to first understand the context it lives in.

In the case of our requirement that the train doors slide up, we would ask ourselves: “What problem does this solve?” And the answer is quite obviously:

“Nothing – it just seems like a good idea.”

So when we’re building our train what we should do instead of compiling this list of requirements is to ask ourselves:

“What do I want when I ride a train?”

Again, the answers to this question can’t be:

“Doors that slide up.”

That’s just coming up with solutions before we’ve defined the problem. The answers to this question should instead deal very directly with the experiences of the people who ride, maintain, and conduct the train every day – and those things that are most likely to cause friction (misfits.)

Once all of those things are clearly listed out you’ve set up a system that asks the right questions of yourself. The next step is to break that list apart into somewhat independent groups of concerns. And only then – once all of those things are clear – can you begin the process of answering each group of questions with a feature designed specifically to resolve it.

Building our own train

Now let’s go and try to design a train.

First, I listed about 115 potential misfits – mostly from the perspective of a passenger. I’ve included a few of them below:

  • I don’t want to have to walk far to get to the train
  • I want to transfer as few times as possible
  • I want to to be able to use my phone while in transit
  • I want to be able to sit down on longer journeys
  • During rush hour I don’t want to be delayed
  • During rush hour I want to be able to have personal space (not be crammed like a sardine)
  • I don’t want to spend more than a few dollars per trip
  • I don’t want to carry around cash in order to get on the train
  • I want to be able to track how many people are using the train
  • I want to be able to track where people are going
  • If I’m rushing to make a train, I don’t want to be held up by having to buy a metrocard
  • If I’m rushing to make a train I don’t want to have to fish through my wallet to get a metro card
  • If I have a large bag I want to be able to get into and out of the boarding / track area easily and quickly
  • I don’t want to have to lift a large rolling bag to get into the boarding or track area
  • If I’m handicapped I want to be able to get into the track area easily
  • I don’t want to steal if I can (I don’t want to feel forced to jump a turnstile to make a train)
  • I don’t want to break the rules of the subway if at all possible
  • I always want to know the best route / train to take without having to memorize the map or know very much about the city
  • If I have to get off I don’t want to have to fight through lots of people to get to a door
  • I want the train to always run on time
  • I always want to know how long it will take to get where I’m going
  • I want to feel safe
  • I never want to feel like I’m in danger from other passengers
  • I don’t want to be hit by a train
  • I don’t want to feel like I’m in danger of getting hit by a train
  • I don’t want my train to get stuck / stranded somewhere other than a station
  • I don’t want other passengers to mess with my personal space

Then what I did is, for every misfit, I went through the whole list and marked which other misfits it was interdependent with. If you’re counting at home, that’s over 5,000 misfit relationships to categorize.1 Yes folks, this blog post was written in non-linear time – eat your heart out Buzzfeed!

Then I threw it all into D3.js so I could visualize the relationships that came out of it. Here’s what it looks like:

Mouseover a node to see which misfit it represents. Play around with it by dragging nodes to pin them. You can also double click a node which will highlight all of the nodes that it is directly connected to.

But what exactly are we looking at here? Well, it’s a rough outline of a small piece of the context of a train. I use the term train loosely because it really goes beyond just a train – there are misfits there that could relate to other forms of transportation (like buses or helicopters) and there are other ones that relate to things like how to find a train station, or how to get inside of the track area. You’ll notice that there are some nodes with lots and lots of connections (we call that a node with high degree) and there are other nodes that are much more peripheral.

For example, take a look at this graph which eliminates all nodes except those that have lots of other nodes connected to them:

What you see here is that the three nodes with the highest number of connections are the nodes for being able to travel anywhere in the city quickly, being able to travel at low cost and and being able to travel safely. That means that there are lots and lots of things that interact in some way with my feeling of safety on the subway, how much it costs to ride, and how quickly I can get places. From a product perspective this is interesting for two reasons:

  1. We’ve just found – in a bottom up way – three of the most important characteristics for a subway system
  2. We’ve just identified the three biggest leverage points in the product

Because these nodes are the most connected to the other parts of the graph, a change to those three will have massive effects on everything else.

If your goal is to think about how to significantly improve or change transportation for a group of people, a good place to start is by playing around with a few of these really high-level factors. For example, if you want to replace subways the first place to start is by finding a solution that’s significantly faster, runs at low cost, and has low safety concerns.

Something else we could do is attempt to find a different niche by emphasizing or de-emphasizing some of these factors. For example, what does it do to our options if we get rid of the requirement for low cost? What does that solution look like? How about changing the requirement for getting around the city easily to getting around the entire country easily?

Changing the constraints on these very highly connected nodes will have a dramatic effect on the form we end up designing, and the kinds of people we’re designing it for.

Now let’s take a look at some of the smaller clusters of nodes of lower degree. For example, check this one out:

Here you’ll see a cluster related to cleanliness. It’s all misfits concerning smells and gunk on the seats. And if you look at its connections you’ll find that it’s related to things like: allowing train cars to be taken in and out of service easily, being able to throw stuff out easily, and having bathrooms available to be used.

Representing things in this way is useful because it allows us to look at how a particular type of passenger experience, like cleanliness, relates to lots of other behind the scenes things that produce those experiences, like having trash cans and bathrooms available.

Another interesting (and surprising) cluster is one below:

This one is basically about how the system communicates what’s going on to you and how that makes you feel.

This surprised me when I saw it because if I had to ask myself prior to doing this exercise, “How can I improve my experience on the subway?” I probably wouldn’t have thought about how the system communicates with me. But approaching the problem in this bottom-up way, it becomes clear very quickly that the way the system communicates is highly connected to lots of other aspects of my experience.

One last one to look at is what I’ll call the MetroCard cluster. A MetroCard is how New Yorkers swipe into the subway. You can pay for a card with a certain amount of money on it, and then you swipe the card at a turnstile in order to enter the station.

The main misfit is “I don’t want to be held up by having to buy a MetroCard.” And that’s connected to other obvious problems with the current MetroCard system:

  • If I’m rushing to make a train I don’t want to have to fish through my wallet to get a MetroCard
  • I don’t want to be able to use my MetroCard (either in my wallet or in the world)
  • I don’t want to be able to swipe my MetroCard the wrong way (and hold other people up behind me)

But it’s also connected to some other problems that swiping into a turnstile has:

  • If I have a large bag I want to be able to get into the boarding track easily
  • I don’t want to have an unusable amount of money on my MetroCard

Knowing that there’s a lot of potential friction in the way MetroCards are used tells us that there’s a lot of room for improvement in that part of the system. And knowing how the different misfits are connected gives us an easy framework to think about how to improve the process of actually getting into the station for everyone instead of just blindly thinking about features.

It’s not supposed to be perfect
Now that we’ve look at the context a little bit, let’s take a step back and think about what we just saw. It’s important to note what we’re looking at here: it’s very a rough, totally imperfect approximation of 100 potential misfits. And it was put together by someone that doesn’t know very much of anything about trains except what it’s like to ride in them.

If I was a train design veteran I would have been able to add hundreds or maybe even thousands of more misfits. And, crucially, I would have had a much better idea of which misfits are interdependent. But just because this isn’t 100% right doesn’t mean it’s not really useful. It’s a starting point.

One thing that’s really important to understand is that the goal is not to first map out the context fully and only then build the product that fits the context. The goal is to help us set a research agenda – and to do it in an unbiased way. It’s to help us to understand the leverage points in a product, find places where the experience can be improved, and give us a framework to think about how those improvements could be made. It’s an iterative process. And it has to be, because it’s impossible to fully know the context (both the misfits and how they’re related) before you’ve actually started creating your form.

Alexander agrees:

“What [makes] a design problem in real world cases is that we are trying to make a diagram for forces whose field we do not understand. Understanding…the context and inventing a form to fit it are really two aspects of the same process.”

This echoes Paul Feyerbend’s sentiment in Against Method that:

“Creation of a thing, and creation plus full understanding of a correct idea of the thing, are very often of one and the same indivisible process and cannot be separated without bringing the process to a stop.”

Trying this at home

What I’d like to get across is that I’m not suggesting you actually have to go through this exact process to the letter every time you’re designing a product. You don’t have to come up with 1,000 misfits, and then check each misfit to see if it depends on any others, and then feed it all into a graphing library to see what the structure of the problem looks like.

The point of this is not to feed you a system that has to be followed in order to achieve good product fit – and if you’re looking for a system that a priori spits out 100% perfect product designs every time, you should be looking somewhere else.

What you could do though, is next time you’re designing a screen, or thinking about how a feature should work and you feel a little lost do the following:

1. Create a list of misfits.

2. Decide which ones interact and should be grouped together.

3. See which ones are really important to you, and which ones aren’t.

4. Then try to build a feature that resolves them.

As you build and test your feature, go back and add new misfits or redo the misfit groupings you came up with. You’ll find that your list will change significantly as you learn more about the context you’re designing for. You’ll also learn which misfits are important to you, and which ones aren’t so important. This will help you make decisions when tradeoffs are necessary (and they will be.)

This process is helpful, because what it does is allow us to see past the feature list and into the system of interacting forces that create the context that a product lives in. Because once you’re looking for that, it changes your approach to building tgings. You’re no longer just looking at the surface level – you’re going a level below that to understand the lives, needs, and desires of the people who make up the context of your product.

The simple beauty of this approach is that it ends up allowing you to produce a highly differentiated product without really trying to.

That’s because building a product in this way requires you to write out a world-view – it requires you to make explicit the things you care about, write down the places you believe there is likely to be friction in a particular product experience, and make explicit decisions about which misfits are most important to solve.

And because your experiences are unique, the way that you understand the context of the design will be different from the way the people around you understand it. And not only that but the way you balance and resolve misfits through your ultimate form will also be different.

And that’s the first step to designing anything worthwhile.


Thanks to Mark Bao, Nathan Bashaw, Jesse Beyroutey, Vinay Trivedi, Tony Diepenbrock, Chuck Moyes, Paul Singman, and Rosanna all of whom read drafts of this and provided amazing feedback.


It’s actually n(n-1)/2 because I only categorized the misfits one way, e.g. given a misfit pair (1,2) if I marked the pair as interdependent I also counted the pair (2,1) as being interdependent. 


22 Feb 2015, 8:23pm | 16 comments


Never miss a new post