Wilson Miner

Wilson is a digital product designer based in San Francisco. Formerly head of design at Rdio and a product designer at Facebook, Wilson is now creative director at The Factory. In 2011, he gave a talk called When We Build, which was widely recognized in the design community as a source of raw inspiration. Wilson was the original designer of EveryBlock, a neighborhood news and community site he co-founded in 2007. As an interactive designer for Apple in 2006, Wilson worked on the first comprehensive redesign of apple.com in more than 10 years. In 2004, Wilson was one of the four people who helped create the original version of the Django Web Framework.

Wilson posts texts of less than 140 characters @wilsonminer.

Published Thoughts

When I first started out as a designer, I was insecure about my taste. It seemed like a critical part of my identity to know — immediately and decisively — what was good and what wasn’t. I felt like I needed to build an impenetrable wall of judgement and very carefully monitor what passed through and what didn’t. After a while, that behavior that started out of insecurity just turned into habit. I couldn’t turn it off. I was the guy at a party who had an opinion about movies he’d never seen and books he’d never read.

As I got older, things happened in my life that broke some pretty big holes in my carefully constructed wall. Once my defenses were weakened, things started streaming in all over the place — new experiences, emotions, Fleetwood Mac albums. After my son was born, I would sometimes find myself tearing up just walking out of the subway because the light was a certain way and some song I’d never even heard before was playing in my headphones. It was weird, and unexpected, to be open to all these things I’d been so carefully unaffected by before, but it wasn’t threatening. I was still me, just with less of a filter. Less discerning. And a little happier?

One of my favorite things about building things is taking things apart. View Source was the only way I ever learned how to build anything on the web. Taking anything apart and trying to put it back together (or build something else with the pieces) is a great way to understand the thought process that goes into making something in the first place. Instead of learning about individual pieces in isolation and then working out how they might fit together, you start with the complete system and work your way backwards. It’s like learning to swim by getting thrown in the deep end of the pool. It can be messy and overwhelming, but once you get it, it sticks.

As I’ve spent more time designing native interfaces and relatively less time with the web, it’s gotten harder for me to reverse engineer how other people have built things by taking them apart. Even when people do go to the trouble of sharing some process stories after a project is released, or release some reusable pieces of code to the community, it’s not the same as being able to crack open the whole machine and figure out how it ticks.

I miss being able to dismantle things I love to learn how to build things I don’t know how to make yet.

Like a good boy scout, I’ve spent most of my life going out of my way to be prepared. Before I could start a new project, or leave on a trip, or sometimes just leave the house, I instinctively started running through worst-case scenarios and tried to make sure I was prepared for them. Delays, weather, miscommunications, conflicts, anything I could preemptively turn from an unforeseen problem into a solved one. But the dark side of trying to prepare for every situation (besides spending a lot of unnecessary anxiety on situations that never happened) is that when I did run into a truly unexpected situation, I was immediately aware that I was not prepared for it, and that was often paralyzing. Instead of responding to the situation and improvising with whatever was available, I just froze in the realization that I had not prepared for this.

Becoming a parent for the first time is slowly unraveling my lifelong obsession with preparedness. Before my son was born, I had to get comfortable with the fact that I had no idea what to expect. Like so many others, from the first moment we became parents, my wife and I have had to react and respond to situations we aren’t prepared for. We can’t possibly anticipate every situation, and even if we could, there’s no way we could prepare for them all. Every parent is a MacGyver in training. We just have to respond to the situation and improvise with whatever is available. Slowly, I’m getting used to being unprepared.

When a conquering general returned to ancient Rome, he could request a special ceremony from the state to publicly honor his achievements. If the Senate voted to award this honor, called a triumph, the general would be carried through the streets of Rome in a lavish procession with his army and all his captives and spoils of his successful campaign on display.

On the day of the triumph, the general himself wore a laurel crown and a toga lined with purple and gold, all signifying his near-divinity. He would paint his face red, the color of Jupiter, the supreme god of the Roman pantheon. But while the general sat in his chariot clothed in symbols of the gods, a slave walked beside him and from time to time whispered in his ear “memento mori.” Remember, you are mortal.

Traditionally, triumphs were exceptionally rare events, granted only for the greatest victories. But towards the end of the Roman republic, a series of lengthy wars produced a surge of triumphs, with each general competing to outdo — and outspend — his predecessors. Pompey the Great was granted an unprecedented three triumphs in his lifetime, the first when he was only 24, each one more lavish than the last. In his second triumph, after a conquest in Africa, his chariot was pulled by elephants. In his third, he sprung for a second day and a giant bust of himself covered in pearls.

Sometimes when I see a new wave of funding announcements or a PR cycle touting the latest startup milestones, I imagine a postscript tacked on to the end of every one: memento mori.

How many people need to use your product for it to be worthwhile? How much of each of those people’s lives needs to be spent using your product for it to be successful? How much of their attention during that time does your product need to be useful?

Instead of measuring successful products by number of users, time spent or engagement, could we consider products successful according to how efficiently they utilize the resource of other people’s time and attention?

I’ve heard it said about politics that “a country gets what it celebrates.” In our industry, where we lately see a lot of celebration of data and metrics and growth, we say “you make what you measure.”

Does that mean if we don’t measure anything, we can make whatever we want?

Lester Freamon — the “wise old cop” in The Wire — is one of my favorite characters of all time. One of the roles he plays in the structure of the show is to remind the other characters (and the audience) that the job they’re doing is important, and they have a responsibility to do it right.

This is especially clear in the first season, when they’re setting up the wiretap that gives the show its name. Throughout the drawn-out process of getting the administrative and legal clearance to set up the wire and actually monitor the calls, Freamon is the one advocating for doing things by the book.

One of the rules is that they can’t legally monitor the calls unless they know one of their targets is using the phone. So in order to listen to the calls, they need somebody on the roof nearby to confirm who is talking. When Herc, one of the younger cops starts complaining about spending hours on the roof of a building waiting for drug dealers to make phone calls, Freamon cuts him off:

“Detective, this right here, this is the job. Now, when you came downtown, what kind of work were you expecting?”

I love that line. I think about it every time I’m sitting around with a bunch of designers and we end up complaining about everything we have to put up with to do our jobs. Whether it’s implementation issues, software annoyances, client headaches, or just putting in long hours, we all sound like Herc sometimes. “More bullshit,” we complain.

That’s when I hear Lester Freamon’s voice in my head. “This right here, this is the job. What kind of work were you expecting?”

Technology in its nature is subject to decay. We haven’t advanced beyond bit rot.

Technology in its nature is subject to instability. We haven’t advanced beyond bugs.

Technology in its nature is subject to failure. We haven’t advanced beyond obsolescence.

All the technology I use and depend on will change and disappear.

These are crass paraphrases of some of the “Five Daily Recollections” from the teachings of Buddhism. Based on my shallow understanding, contemplating these facts is meant to lead us to abandon our “destructive attachments” to our illusions about the way the world should be, and more peacefully exist in the world the way it is.

I don’t mean to be disrespectful by repurposing them here (“Top 5 Ways To Achieve Technological Zen!”), just to point to the obvious but sometimes invisible fact that what is true of our lives is also true of our digital lives.

Recently, a snippet from David Foster Wallace’s commencement address to Kenyon College in 2005 has been recirculating in a video called “This is Water”. If you never had a chance to read or hear the original, you owe it to yourself to at least watch the video.

He starts with a story:

There are these two young fish swimming along and they happen to meet an older fish swimming the other way, who nods at them and says “Morning, boys. How’s the water?” And the two young fish swim on for a bit, and then eventually one of them looks over at the other and goes “What the hell is water?”

In his singular, electric, messy human way, he digs away at the same “capital-T Truth” that the Five Recollections are getting at. That we have to keep reminding ourselves, over and over of what is hidden in plain sight all around us, all the time.

The fifth and final recollection is different from the rest. No adaptation necessary.

“I am the owner of my actions, heir to my actions, and supported by my actions. Whatever actions I take, good or bad, that is my inheritance.”

We can’t change the nature of technology, but we choose what we do with it. Day in, day out, each action is a choice. Every click, every tap, every line of code is another drop in the water we swim in every day. “This is water.” That is our inheritance.

When I was 16, I worked for a designer who gave me this advice: “If you don’t A-S-K, you won’t G-E-T.” Yeah, it’s goofy how he spelled it out like that, but it stuck with me.

He was talking about asking for money, getting paid for my work. The idea that I was doing work that had any value to anybody even though I was 16 years old and had almost no experience was hard to get my head around. But it was 1996, and I was building web pages for some of his local clients. I had as much experience as anybody else they could hire to do it.

Later on in my career I started to think about that advice in a different way. Sure, it’s about taking responsibility for valuing your own work, but it’s also about taking responsibility for the kind of work you want to be valued for.

One piece of advice I’ve given designers starting out is don’t put work in your portfolio that you don’t want to do again. It’s easy to feel pressure to “round out” your book, and make your skills look as broad as possible. But it’s a self-fulfilling prophecy — the work you show is the kind of work people will ask you for. Typecasting is just human nature.

Recognizing that actually gives you a kind of power. By shaping the image you put out there, you can shape the work you do in the future. Tired of people coming to you as the “illustration guy”? Take the illustrations out of your book. Want to do more UI work? Put some spec UI work in. Pull out all the stops, write a case study, build your own app, push the details, make it thoughtful. If the work leaves an impression, it doesn’t matter who the client was, or if there even was one. As a designer, you always have the power to (re)invent yourself.

“If you don’t A-S-K, you won’t G-E-T.”

My favorite part of any new video game is the tutorial. Let me explain.

One of the magic tricks that good games have to pull off is how to pace complexity. The amount of time a player spends with any one game is usually pretty long. The low end of gameplay time for big commercial games is about 8–10 hours, and it’s not hard to spend hundreds of hours with certain games. To keep you interested for that long, a game has to be relatively complex. But if a game dumps all that complexity on you in the beginning, you’ll never make it. They have to introduce it gradually.

Games used to do this with separate tutorial levels. Before starting the real game, you’d be strongly admonished to play the tutorial first, which usually took the form of separate levels with guided steps along the way to introduce the interface and the core mechanics.

Modern games have started working the tutorials into the first few levels of the real game, sometimes so deftly that you hardly know you’re playing a tutorial.

Weaving the tutorial into the first few moments of the game makes for another balancing act. Not only does the game want to teach you how to play it, it wants you to get a feel for what playing the game is going to be like for many more hours. It wants you to say: “whoa, this is going to be good.”

In this way, game tutorials have started to behave more like pilot episodes in television. Pilots have a similar magic trick to pull off. In the first episode they have to introduce the characters and the rules of their world while at the same time convincing you that this is a place you want to come back to for many more hours. A pilot is a promise to the viewer: “this is going to be good.”

Some shows are better at fulfilling this promise than others. If you go back and watch the first episodes of your favorite shows (as I have done more times than I’d like to admit), you can see which ones stuck to the rules they set out in the beginning and which ones wandered from the path.

In the first episode of one of my favorite shows, The West Wing, there’s a sequence of vignettes that visits each of the main characters in a moment of their lives. Each one establishes some essential aspect of that character’s personality and gives you a sense for the role they play in the world of the show. The remarkable thing about these scenes is that, watching them after spending more than a hundred hours with these characters, they still ring true. These first sketches of these characters, presented so confidently and economically in the beginning—each one lasts just a few minutes—was a promise kept for the rest of the show.

It’s that same confidence and economy that makes a great tutorial for a great game. There are no wrong choices during the tutorial, and each step forward introduces a core mechanic that you’ll hopefully spend the rest of the game using. Is this fun? Do I want to get to know these characters? Do I want to spend time in this world? By the end of a good tutorial or a good pilot episode, you should have your answers.

When we design digital products, for the most part, we’re still building tacked on tutorial modes. Step by step introductions, a few popups to show you where the important buttons are. Did you get all that? Good, because now you’re on your own.

But beyond just instructions, what are the promises we want our products to make? And how do we present them confidently and economically in the first few moments? How do we get people to say: “whoa, this is going to be good”?

We can be fickle on the Web. We jump from thing to thing. We give up on things quickly, or write them off as failures because their timing was wrong. We pin our hopes on the next unproven thing before our last great hope even gets off the ground.

The window of opportunity for something new to succeed can seem so small. But we can’t understand the capacity of new materials — or new circumstances — without experimenting with them. And that takes time.

Technology is like a language that’s always changing. We’re always new speakers, always resetting and relearning. It’s hard to say something profound with a limited vocabulary.

This is a reminder to myself: It’s OK to revisit things. It’s OK to compete with established players, and to try again where we — and others — have failed. It’s OK to build “yet another” solution to the same problem. If we’re lucky enough to find a few questions that matter to us, we should follow them ruthlessly.

The real treasures aren’t shiny and new. They're ancient, crusty and deeply buried. To uncover them, we have to pick a spot, and keep digging.

Here’s Richard Feynman describing the scientific method to his students:

First, we guess. Then we compute the consequences of the guess to see: if this is right, what would it imply? Then we compare the results to nature. If it disagrees with experiments, it’s wrong. In that simple statement is the key to science. It doesn’t make a difference how beautiful your guess is, how smart you are, who made the guess or what his name is. If it disagrees with experiments, it’s wrong.

Every product is a hypothesis. We start with a guess: I think this will work, I think this will be better, I think this is true. And we build something to test that guess. Then we learn something, and we try again. This formula doesn’t preclude art or creative choice or instinct or boldness at any point along the way. But it’s a place to start, and it’s a method to return to, to ground what we’re doing.