On the death of Steve Jobs

The death of Steve Jobs is a mirror into our own vanity. Designers — take heed.

Steve Jobs blah blah visionary blah blah design blah blah changed computing. It’s true, and I’m not going to rehash the accolades here.

But there’s a flip side to the innovation. I wrote this as a Facebook status following his death:

Steve Jobs in hell is working 16 hour days 7 days a week at a Chinese factory building the new iPhone 666.

It’s funny only because there’s a dose of truth to it. In all the technology we acquire, not just from Apple, much of the cost that went into creating those artifacts is hidden from our eyes unless something brings it to our attention.

Besides dead factory workers, we pay the cost of Apple products everyday. Have you ever gone to the Genius Bar without an appointment? Broke your iPhone and had to buy a new one? Or had your macbook stolen only to have the police shrug?

Some more jokes at dead Steve Jobs’ expense to drive the point home:

  • Steve Jobs in hell just had his iPhone stolen, and the police won’t do shit about it.
  • Steve Jobs in hell broke his macbook, so he went to the genius bar without an appointment where he’ll wait for his name to be called… forever.
  • Steve Jobs in hell broke his phone but can’t afford a new iPhone, so he had to settle for a free Nokia.
  • Steve Jobs in hell got a $5,000 cell phone bill this month because he’s roaming on his data plan.

The jokes practically write themselves. Let’s face it — Apple products are expensive and fragile. They are time sinks and pickpocket bait. And we suck it up because the products are so tantalizing — because owning an Apple product is a statement about you.

If you think I’m denigrating the name of Steve Jobs or Apple, I am, but only as much as it takes to make my point. If it makes you feel better, you could play Mad Libs with the text above and swap out the names of the companies, products, and executives; it would be just as true but the products wouldn’t look as good. Simply put, we pay more than money for the privilege of owning these magical amenities.

Steve Jobs was responsible for Apple’s meteoric rise these last decades because there was an audience desperate for Apple’s pretty products — me included. If there’s any lesson to take from Steve’s passing other than a life cut off in the midst of greatness, it’s that we greatly value the veneer of our possessions despite the costs.

You’re not agile (redux)

You might think your team does “agile development.”  You’re not agile.

At Infocamp Berkeley this weekend, I ran a session called “You’re not agile.” I fully admit it was inspired by my anger from organizations who claim they’re “agile” when they’re really not.  Here’s an alternate take on what I presented…

A photo of a whiteboard with lots of writing and drawings
The whiteboard from my InfoCamp session

A long time ago, waterfall development was the process used to create software.  Executives would make requirements, designers would make designs with the requirements, developers would build software from the designs, QA would test the software, the software would ship, and the cycle repeat.  Software development was treated like factory work because that was the only model of production they had.  Replace “software” with “bicycle” in that explanation and you’ll see what I mean.

However, waterfall isn’t ideal for software.  Requirements change, customers have limited input, and software simply isn’t hardware.  Using waterfall for software is like cooking a souffle using directions for grilling a steak — worst souffle ever.  Similarly, using a process that works great for manufacturing physical goods is a bad idea for producing software goods.

What is agile development?

As a backlash to waterfall, teams began experimenting with new methods.  These groups started with the premise that there must be a better way to produce software in a corporate environment.

For example, waterfall process is obsessed with documentation as the interface between steps of the process.  However, producing functional software is a far more important business goal, even if you skip writing everything down.  Similarly processes and tools are useful, but you can solve problems with communication way faster than following a checklist.

These values and principles are codified in the Agile Manifesto — a document well worth your time to read and understand.  It was written by a group of agile practitioners looking to forge a group identity for their new vision of software development.

Sadly, it lacks a concise definition of what “agile development” means, so here’s my take:

Agile development is a set of values and principles for improving your development teams’ alignment with your organization’s needs.

That’s a dense sentence.  Read it a few more times to make sure you get it.

Take notice that my definition and the Agile Manifesto do not say anything about specific practices that will make you agile.  Rather, agility is a shared mindset that you and your team use to solve development obstacles.  A team with this as a motivating goal is a powerful force for creating kick-ass-ness in the world.

The cargo cult of agile

News of successful organizational transformation with agile development methods started spreading.  Success breeds imitators, and other teams tried agile for themselves.  They started doing agile practices — like daily standups, iterations, and product backlogs — but never gained the benefits.

They became the cargo cults of agile.

The term “cargo cult” refers to a group who imitates another group’s processes but lacks the substance which makes those processes work.  The term was inspired by the actions of Pacific island inhabitants in World War II.  U.S. and Japanese troops would set up bases on these islands.  With these bases came regular shipments of goods, visits from planes, and formation marches by troops.

After World War II, the troops, planes, and bases left too, leaving the native inhabitants without their regular deliveries of goods.  To bring back those deliveries, some of them recreated the artifacts and actions of the visitors — building airports with dirt roads, airplanes and radios from bamboo and coconuts, and marching in formation as best as they could.

a bamboo plane
A cargo cult plane made from wood

Sadly, the natives were unsuccessful in making additonal cargo drops reappear because they didn’t understand the visitors’ airplanes, airports, cargo, and radios.

Similarly, many organizations put agile methods into practice without adopting agile values.  For example, a manager orders the engineering team to start doing daily standups. The engineers perceive this as “managers are spying on what we’re doing” and treat it accordingly.  By contrast, an agile team knows that standups are for the team itself — and not for the managers — because the team values communication, helping each other, and self-organizing.

Because the cargo cult agile teams don’t internalize the changes their making, they don’t get better.  As a result, there’s been a backlash against agile development from the people who’ve had bad experiences where “we tried to do agile, but it just didn’t work.”  They give agile development a bad name.

Lessons learned

In my session, I went over a few agile practices and how they represent the values and principles of agile development, but I’ll leave it up to you to find additional resources on how to be agile.  Instead, I want to touch on a few motifs that ran through the conversations and questions I heard at Infocamp:

  • Agile UX — How does design fit into agile?  In short, agile UX means “stop drawing pictures and just start building.”  Organizations are very uncomfortable with this; many UX designers don’t have coding skills to build prototypes, and managers and executives are wary about committing development resources when designs are incomplete.  It will take a real sea change to make this catch on.
  • Becoming agile — How do you begin agile development in your organization?  It takes lots of things — a willing development team, executive buy-in, strong values, reasonable tools, and a great agile leader to guide the team.  But what’s even more important is this — start small.  Do one project “agile.”  Remove organizational impediments one by one.  Bring in new practices little by little.  And one more thing — don’t be afraid of failure; just keep trying.
  • Management skills — Most schools don’t teach agile.  Hell, most schools don’t teach management skills at all.  The people I know who do agile well learned it themselves or from someone who kicks ass at agile.  In other words, agile development needs better marketing and education to spread the word and knowledge.

Another way to paraphrase the questions is this — “How can I learn more about agile and apply it to my organization?”  I’ll give you three next steps:

  1. Learn about agile development.  Read blogs and books about it.  Find people who know about it and pick their brains.  Go see a kick ass agile team and how they work.
  2. Decide what you value.  Then start looking at how your team runs. What are you good at already?  Where are the biggest gaps?
  3. Start making small changes and close in on those values.  Share your successes, and keep trying to get better.

It’s lots of work, and there’s every risk of failure.  But it’s better to try and improve your situation than be stuck with something that’s broken.

The perils of asking “why?”

“Why?” is possibly the worst question you can ask someone when you want to understand the reason for their decisions.

I’m sure you’re perplexed by that statement.  You say, “I already know I shouldn’t take answers at face value.”  My point is that in your quest to find the reasoning behind the answers, you may unintentionally lead yourself astray from the real information you need.

I often have the need to ask “why?” in my work during usability testing, interviews, or getting design feedback.  “Why do you like design A versus design B?”  “Why does pink not work here?”  “How did you know to click on that button?”  Answers to those questions really help me do my job.

Unfortunately, humans are bad at introspection, so the explanations we give are not always valid.  You can usually believe someone’s decision (ex. “I like the blue socks better than the red ones.”). But when you ask for an explanation for why she made that decision, the reason may not be related to this specific incident (ex. “I like blue better than red.” versus “The red is too strong for my white shoes.”).  In fact, believing someone’s explanation could lead you down the wrong path altogether.

What underlies this conundrum?  And what should you use instead of “why?”  I think a little experiment will help you understand the trouble “why” can create.

A little experiment

Let’s say I ask you to take part in my little experiment.  I bring you into a room with two ropes hanging from the ceiling, like below.

“Your task,” I say, “is to tie these two ropes together.  Go.”  Instinctively, you try the naive solution.  You grab one rope and pull it towards the other, but it’s just not long enough for you to grab both at the same time.

You can’t quite figure it out.  I walk by the ropes, accidentally causing it to swing just a little.  A few seconds later, you get an idea to start swinging one of the ropes.  While it’s swinging, you grab the other rope and pull it towards the first one.

When the first one swings back, you catch it and tie the ropes together.

Then I ask you, “how did you know that was the solution?”

Time-out for science

This was a real experiment conducted in the 1930s and reanalyzed in a famous paper “Telling More Than We Can Know” by Nisbett and Wilson published in the 1970s.

There’s only one reason that explains how you got over your mental hurdle to solve the rope puzzle: I nudged the rope just a little.  That means I’m expecting to hear only one answer from you when I ask my question: “I saw the rope swing just a little bit, and that sparked an idea.”

Unfortunately, people in this experiment gave anything but that answer:  “I thought of monkeys swinging through the jungle.”  “I was reminded of a trapeze act I saw at the circus as a kid.”  “When I was in Hawaii, I did a rope swing into the ocean.”  After being pressed, about a third of participants mentioned seeing the rope move.  That means two-thirds of them had no idea what really triggered their answer.

This was one of several experiments that Nisbett and Wilson re-evalutated.  Their conclusion was that we have little or no introspection into our cognitive processes.  Further experiments proved that we have some introspective capabilities but it is very limited.

The impact of our limited introspection

As much as we think of ourselves as rational, self-aware beings, we are not fully aware of our decision making processes.  The extent of this awareness depends on the individual and the circumstances.

To oversimplify, the kinds of answers people give in response include:

  • The real answer – It’s possible that you’ll get the true justification for that person’s decision. In the rope swinging experiment, you would hear this as, “I saw the rope swinging, and that triggered an idea.”
  • Shared knowledge – A plea to information or theories that are public knowledge or known to the group.  “Everybody knows that you swing a rope, so that’s what I did.”
  • Personal experience – The person will use their own beliefs, knowledge, or experiences as their answer.  “I remember swinging on a rope swing as a kid.”  That might have actually happened, but it’s not what triggered his answer.

When someone answers your “why” question, it could be the real answer, it could be something they pulled from their memories, or it could be something else completely different.

And this gets to the heart of the dangers of asking “why.”  The response you get could send you down the wrong track.  For example, take this (fake) usability test snippit:

You: Did you have any trouble filling out the form?

Subject: Yeah, the button was a problem.

You: Why?

Subject: It wasn’t clear what it does.

Actually, the reason why is that the button is blue, and the subject secretly hates blue ever since his third grade soccer team lost the city finals to a team wearing blue jerseys.  But there’s no way to know that from his answer.  His comment sends you on a wild goose chase to redesign that button due to someone’s vendetta against blue.

Similarly, imagine you’re getting feedback about your research into a new product:

You: …and based on our interviews with customers, they want a mobile version of the app.

An executive:  I don’t think that will cut it.

You:  Why?

An executive:  That didn’t work for our competitors, and it won’t work for us.

It’s more likely that the executive has other priorities in mind or that he is biased against mobile apps, but the answer that came to mind first was “it didn’t work for the competition.”

Yes, you shouldn’t take answers at face value, but many people use “why” as a way to cut to the real answer.  The answers that people give to “why” may take yourself off the path towards the real answer due to these limits on our introspection.

If I can’t ask “why,” what should I do?

First, you can usually believe the person’s initial decision.  Imagine you’re choosing two pairs of socks and you immediately like the blue one more than the red one.  You can give any reason you want for liking the blue one; nothing will shake your conviction that it is the superior pair.  Same thing goes for other decisions.  If someone dislikes your design, then they don’t like it.  Accept their decision that your design has problems regardless of the reason.

Next, be careful not to ask justification-seeking questions.  The questions, “why did you click on the games tab?” “how did you choose games next?” and “what drew you to click on games?” are really the same question.  Any answer when asking about a person’s internal state during a decision is suspect by default.

Instead, try asking questions related to the action just taken.  For the person who chooses “games” among several options, the most likely reason is because he likes games.  “Do you like games?  How much do you play them?”  Questions of that sort will quickly prove your assumption and provide valuable information about your subject.

Similarly, if someone doesn’t like a design, you could ask questions like ,”what were you expecting to see?” or “how does this compare with [some other design the person liked]?”  You could even try a more open-ended prompt like, “tell me more about that.”

Also, you can ask the individual to give an example or tell a story instead.  For example if you’re researching video editing software users, you might be tempted to ask, “why do you need video editing software?”  A much better question would be to ask for a specific time when they used it.  “Tell me about the last time you used video editing software.  What prompted you to use it?”

Stay on your toes, and think hard about the information you want to get back from your next question.  You can usually come up with a better question than “why?”

This means something

I find great solace in these results for a few reasons.  First, it justifies the need for psychologists and psychiatrists.  These sciences are concerned with helping people live better lives by understanding our thought processes.  Humans are poor at introspection, so it’s helpful to have someone objectively look at your actions and help you understand how you chose them.

Also, it’s good for your relationships.  Say you’re arguing with your significant other and spout something mean like, “at least I’m not towheaded!”  Then she gets all weepy and says, “why would you say something as horrible as that?”  You can answer, “I don’t know, but I know why I don’t know.”*  Be thoughtful when trying to understand someone’s justification for a decision.  Nobody is fully aware of why you do the things you do.

Finally, this research justifies the work of designers, ethnographers, and similar professionals.  Much of what we do is based on our understanding of the individual(s) we study.  It’s hard work;  asking good questions is just a small part of what we do.  That’s why capable professionals in these fields are worth every cent you pay them.

Take this to heart the next time you start a new project or when you’re interacting with a friend.  Even though humans suck at self-reporting our justifications for decisions, you can still get the information you need without asking “why.”


For my final project at UC Berkeley, a group of us studied Berkeley freshmen and how they used technology in their lives.  Among the many topics we covered, we asked about their habits using file sharing software.  No surprise — nearly all of them did it.

The next logical question we asked is, “why do you use file sharing software?”  The answers were all over the map.  “I don’t want to help the big music moguls.”  “I don’t have the money to buy it.”  “It’s free!”  Reflecting on that now, “why” was a poor question to ask.

I hope your endeavors in your own research are better for this tidbit of thought.

*Don’t try this in a real argument.  It doesn’t work.

Knowing your users isn’t enough

You may think you know your users, but that’s not good enough if you want to design great products for them. *cough Google Buzz cough*

I think this clip from The Simpsons where Homer gives Marge a bowling ball for her birthday epitomizes the problem.

Buying a present for someone is very similar to designing for someone. You’re not that person, so you can only guess what that person might like — a bottle of perfume, a bowling ball, a new man, an awkward social networking system. You often get it wrong, to the anger and disappointment of the recipient.

Why does this happen? Here’s an interesting study that gives us one insight. Researchers brought in couples and separated each pair. One person was asked to rate 30 items of furniture, and the other was asked to rate 30 different items.

Then each person was shown 30 new items — the items their partner just rated. Each partner rated the new items based on either 1) how their partner would rate them or 2) how a stranger would rate them. After rating an item, the person would see the other’s rating, helping them predict future ratings.

How well did each partner predict the other’s preferences? Since these people are couples, you might guess they did pretty well on this test. Actually, it depends on how similar the two partners’ tastes are.

When the two people in the couple have similar tastes (as determined by how they rated the same items), their prediction accuracy was around 40% — whether or not they were in the “rate your partner” or “rate a stranger” group.

When the two people in the couple have different tastes, the “rate a stranger” group was about 23% accurate while the “rate your partner” group scored a whopping 5% accuracy rate.

In other words, if your tastes are different from your partners, you’re better off treating that person like a stranger than trying to guess what he or she really wants. If your tastes are similar, your guesses for the other person will still be so-so.

How does this apply to design?

Most product designers think they know their users. This experiment reminds us that you suck at guessing what they want even when you know them:

  • If you know your users, your guesses about their preferences will be awful if your preferences are different than theirs (5% accurate)
  • If you’re similar to your users, your guess about their preferences will still suck (40% accuracy)
  • In any case, you’re better off imagining your users as strangers (23% and 40%) versus people you know (5% and 40%)
  • Getting feedback on your guesses doesn’t help you guess more accurately in the future

Let’s say you’re a large software engineering company based in Mountain View, CA building a new social networking product. You only test it internally, and everyone seems to think it’s ok. Then you unleash it upon the masses, resulting in all kinds of strange backlash that you never imagined.

I say that nobody should be surprised about these results. Even if Google is the golden child of Silicon Valley, they were bound to make this mistake because of their culture.

Why does this happen?

I can think of at least three reasons why people mistakenly think they have the same tastes as their users. These causes are often tied to the culture and processes in a company.

Not accounting for differences

Your users don’t think the same way that you do.  However, because of this nasty thing called projection bias, we mistakenly believe that other people have the same knowledge, ideas, experiences, and feelings as we do.

While that seems pretty obvious as a statement, I’m sure you encounter it all the time in the form of, “it’s great! The users will love it,” or “I know what they’re thinking. They want more social features!” That usually indicates you’re making decisions based on what you think rather than what your users think.

In-house experts

The real killer is when you think that “we’re users too” even though the people at your company aren’t characteristic of your user base. Because of availability bias, we base our decisions on information at hand rather (like our coworkers) instead of seeking out alternative points of view (like our users).

The people at your company aren’t very representative of all users of your product; your coworkers are usually product experts (top 1%) while most users are intermediates or beginners. If you decide on features based on internal feedback, then you’re building for the experts rather than the other 99% of your users. In other words, “we’re users too” leads to products aimed at the wrong audience.

Not asking first

Sometimes you can design something and be right about your user’s preferences.  However, there’s only one way to be sure — ask your users. Because feedback doesn’t improve your accuracy, you have to ask up front — before you lob the new features at your users.

Are you doing any user acceptance testing? With real users who work at other companies and do their work outside your company walls? How do you close the loop with your users after you release new features? It’s the difference between “honey, would you like a bowling ball for your birthday?” versus “honey, I bought you a bowling ball for your birthday.”

Back to the Buzz

So why did Buzz mess up? I hope it’s now clear that Google was playing Russian roulette with its product:

  • Google employees are vastly different than their overall user base
  • Google designed the product for themselves
  • Google only tested Buzz internally before making it public

And presto — Google just gave all their users bowling balls for their birthdays. You get a bowling ball! And you get a bowling ball! You ALL get bowling balls!!!

In summary, knowing your users isn’t enough to build great products for them. If you know them, you can still be horribly wrong at predicting their preferences (like the 5% result). Even in the best case, you’re still in coin-flip territory (the 40% result).

If you want to make better products, start by becoming aware of the biases that affect your decision making.

On jury duty

Being in jury duty is like forcing twelve people to order a three topping, extra-large pizza where the three toppings must be different and everyone has to agree on all three toppings before you can order.

Sometime during the course of the proceedings, I realized that the drama in front of me was the manifestation of everything I knew about cognitive science and social psychology. The lawyers are scientists and the courtroom is a laboratory. The lawyers use witnesses and evidence to mix up a verdict through persuasion, rhetoric, and storytelling.

I decided to put on my ethnographer’s hat and record my observations — the action in the courtroom, the drama in the deliberation room, and everything else relevant to life as a juror. Below is a scattershot list of my interpretations.

It’s long and poorly organized, and I’m not apologizing for it. And I’m being intentionally vague about gender and case details.

Backseat lawyers

As a jury, we were extremely dissatisfied with the lawyers for how they argued the case. Following a particularly awful exchange by one lawyer, a juror said he/she wanted to jump out of the jury box and yell at that lawyer for being such an idiot. (That’s almost a direct quote.)

As we went forward in our deliberations, we uncovered essential evidence that both lawyers missed. We often complained that the lawyers could have made a more compelling case by asking questions about X or grilling witness Y.

During one complaining session of that sort, I wanted to get the jury back on track. I said, “let’s hold off on the backseat lawyering.” Someone quipped in response, “Monday morning lawyer.” Exactly.

On a side note, I think a courtroom drama with an MST3K-style commentary track has the potential for extreme humor.


In case my previous attempts at jokes weren’t funny, we tried hard to maintain our sanity through humor during the deliberation process. This often came out as jokes about the witnesses, lawyers, the court personnel, or even ourselves.

Yes, we were a bit disgusted with ourselves given the seriousness of the courtroom events. I think it was necessary to crack a joke every so often; for me, it kept me from taking the deliberations too seriously — avoid making it personal.

One time while we were commenting on the courtroom antics, I said, “this would make a great screenplay — all twelve of us deliberating in the room. Co-starring the bailiff as our comic relief. And with special guest stars the judge and court clerk.” It was much funnier in the deliberation room; you just had to be there.

Someone said that jury deliberations would make a great reality TV show. “You could film a different jury deliberating every week.” I definitely agree.

I finally understand how someone got a cell phone in my name

About a decade ago, someone fraudulently opened a cell phone account in my name with a major wireless provider. That person racked up hundreds of dollars in calls, then the phone was shut off for non-payment. This showed up on my credit report when I went to get my own cell phone, resulting in countless hours lost as I tried to ressurrect my good credit.

Thanks to the expert witness testimony of a cell phone company employee at this trial, I now know why it’s so easy to do that. Unlike banks or credit card companies, cell phone companies do not extend credit to individuals; you’re bound by a contract to pay for the service every month. Because they don’t extend credit, those companies are not required to check the ID or verify any of the information (like address) that a person provides when getting a cell phone contract.

In St. Louis, a Sprint store employee gave a cell phone to someone who used my name and SSN along with a fake address (“Wadaba St” — seriously, that alone should be a red flag) when I was living a thousand miles away. And Sprint is under no obligation to verify that it was really me (or in this case, not me) who did it. And due to some arcane laws, I would have to go to St. Louis in person to press charges.

Words cannot express my outrage.

Technology (or lack thereof)

Our courts are technologically inept. Most of the evidence could have been trivially scanned and made available to the jury digitally if they had wanted.

Instead, we got 100 pages of phone call records, 50 records a page. (Oh, how we would have loved to build a pivot table.) We had to request special equipment to view a DVD. Every photo had to be passed around to each member of the jury, wasting countless hours. Testimony had to be printed (for some witnesses, hundreds of pages long) or, if the written transcripts weren’t ready, read aloud by the court reporter.

We opined about how much faster we could get through the information if we could get everything digitally. Instead, the prosecution lawyer pushed a cart full of boxes and binders, each full of pages and pages of paper, to court every day. Those poor trees…

The pool

The jury selection process is awful. It starts with 24 jurors being selected randomly from a pool of over 100. Then the judge and lawyers begin asking a series of questions that you’re expected to remember whether or not you were selected. Some jurors are booted, then a new set are called up to fill in the empty seats. More questions are asked, and the process repeats until both lawyers decide to keep the 12 jurors in the box.

It was the most boring three days of my life. Sure, there was the occasional interesting character or curious story. I spent my time devising ways that the courts could accelerate the process and get a suitable jury faster and make it more fun.

But no — the boring ways produce a fair jury of the defendant’s peers. I think the (long, boring) pooling process is the primary reason why people hate jury duty.

The negative opinion of jury duty

Here are some reasons why people dislike jury duty:

  • You spend three days in a jury pool but never get picked to be on the case — total waste of time
  • You end up on a trial and have to put your life on hold or have to work 20 hour days (8-9 hrs at court + your real job)
  • Sitting in the courtroom is boring. Everything moves as slow as possible
  • Deliberations take a long time and are very mentally taxing
  • You get paid almost nothing ($15 a day plus $2.50 for transportation in SF)

But I think the main reason why people dislike jury duty is this:

  • They’ve never been on a jury before

When I told people that I was on jury duty, most people said, “aw, that’s too bad,” or something like that. The only people who said good things were ones who had been on a jury before.

It’s really not that bad. Give it a try sometime.

It’s no [your courtroom/police drama of choice]

It’s no CSI. It’s no Law and Order. In the courtroom, a real trial is much more boring than you think. Lots of questions and answers. No magic technology to reassemble events of the incident. No outbursts by witnesses. No need to restrain the defendant.

I guess courts shouldn’t be exciting or dramatic, given the gravity of events that occur there. On the other hand, they shouldn’t be boring either, given the gravity of events that occur there. I’ll think about ways to improve that.

What the witnesses saw or didn’t see

Because the events in this trial occurred over a year ago, lots of witnesses had trouble remembering the events of the incident. In several cases, the lawyers had to remind the witnesses about statements they made to police on the night of the event; at court, the witnesses often misremembered or didn’t recall details.

Even more interesting — the key eyewitnesses (the defendant and a victim) recalled completely different versions of the incriminating event. It’s a form of motivated recall — that is, you’re motivated to remember events that portray yourself in a positive way or in a way that makes you seem better. In this case, the victim wanted a conviction, and the defendant wanted to be released; they testified as such.

As a jury, we were left with the tough decision to decide, individually, whether or not we believed the witnesses in part or in whole.

Everyone needs something a little bit different

As we were deliberating, we discussed the points that brought us to a reasonable doubt or brought us to believe the defendant was guilty. While it was good to air our thoughts, it did little to convince people one way or the other.

The reason why that doesn’t work is because of projection bias — that quirky cognitive bias that leads you to believe (incorrectly) that others share your beliefs or thoughts. The evidence that convinces you of your verdict probably won’t convince another juror of your verdict; in fact, more than once during our deliberations, someone would bring up evidence that obviously pointed to guilt while another juror would use that exact same evidence to point to innocence.

Every juror needed something a little bit different to get to a conclusion — a timeline of events, a read-back of certain testimony, an alternate explanation for a witness’s observation. If there’s any lesson from the trial that I’ll apply to my life, this is it — it may be perfect to you, but it does nothing for others (whatever “it” is — evidence, love, designs, hamburgers, Charlie Sheen movies).

The hardest part of the deliberations, by far, was finding that “little bit different” for each juror. How do you convince people of your opinion? I still don’t know the answer to that. All I know is that we deliberated for 7 days and didn’t agree on all the charges.

(Speaking of projection bias, in deliberations a few jurors said, “I would have…” or “If I was there…” If the witness did something that you wouldn’t do, the witness must be lying, right? Don’t assume others think or behave the same as you.)

The sounds and the smells

The Hall of Justice at 850 Bryant is smelly because it’s the home of the San Francisco parole and probation offices. Every day there would be interesting odors while waiting in line for the security check, going up the elevator, or, most interesting of all, in the stairwell.

The odors included pot, crack, alcohol, and smelly homelessness. Often I would see the security guards put on rubber gloves when dealing with homeless people. The security guards also kept a wooden walking cane near the x-ray machines to be used when a homeless person’s bags got stuck in the x-ray machine.  (They would use their hands on others’ belongings.)

And about the stairwell… it reeked of pot. Every day, without fail. My only wish is that the parole and probation officers have noses, because I bet lots of the people who show up are breaking their terms of probation — as determined solely by the odor.

The grammar

Having been through this trial, I’m much more grateful for my education. I’ve now heard the phrase “I seen” more times than I ever want to in a lifetime.

Court lingo

You learn lots of new terminology while in court. Words you thought you knew like “robbery,” “murder,” and “intent” have specific definitions while you’re there. Here are some favorites:

  • Dixied: to steal. See also: boosted
  • 6 pack: a photo lineup used by police to identify suspects
  • Green vegetable matter: marijuana, when entered into evidence and not yet identified as weed
  • Stipulate: an agreement between the prosecution and defense about the facts of the case
  • Intent: I’m still not sure what that means

Reinventing the wheel

Even though jury trials take place all over the country, most jurors are inexperienced and perform jury duty infrequently (less than once a year). That means juries are reinventing the process for deliberating over and over all the time. In my jury, nobody knew the right way to run the deliberations, so we made it up as we went along.

Said differently, everyone is a beginner in a jury. My user experience instincts tell me that you need plenty of hand-holding as a beginner in a complex process that you go through infrequently. Courts should help juries as much as possible to get through the deliberation process. Instructions would be great.

Instead, we were left with “1) deliberate. 2) vote. 3) if unanimous, tell the judge. else goto 1.” If we had some rules or advice for how to deliberate, I think our task would have been completed much faster. A different presiding juror (foreman) might have shortened (or lengthened) our deliberations by a day; I want to know what process juries can use to shorten deliberations by days.

The instructions

At the end of the closing statements, the judge gives the jury instructions for how to decide the case. For example, “robbery” has a very specific meaning including dispossessing someone of an item, using force or fear to deprive the person of the object, and intending to keep it permanently.

In our case, the instructions were over 50 pages of the dry, difficult legal jargon. As non-lawyer people, we could only decide among ourselves or ask the judge what they mean. And because it’s over 50 pages worth of dense stuff, there’s no way to keep all that in mind when deliberating.

The definition of “robbery” included a 5 step process with special rules and exceptions, and it refers to other definitions that have their own steps and processes. The criteria for believing or not believing witnesses was 5 pages by itself. Circular references were common. One juror joked that the instructions should be in a wiki.

The output is only as good as the input; simpler instructions would help juries come to better decisions faster.

The missing pages

Even though you’re not supposed to assume or concoct ideas, you can’t help but do that, especially when you find the witnesses’ testimony to be dubious. We tried to reconstruct what really happened, sometimes taking liberties with the evidence we were given.

In a more amusing moment, someone suggested that a victim inflicted his wounds on himself.  I said, “you mean this is like Fight Club?” It got a laugh.

As humans, we have an innate drive to finish stories — a drive for completion. Trying to reassemble the real story of a court case is like reading a novel with every other page torn out or watching a movie in a language you don’t understand. You invent your own story; you have to.

Small potatoes

During our casual chats, we often talked about how the case was impacting our lives. Several people reported that they had trouble sleeping, including one who thought a person was standing in his/her bedroom (it was a shadow). A couple of folks said they started noticing suspicious characters in their neighborhood. A couple of people were at the trial during the day then left to work a full time job at night.

As the trial went on, the impact started getting more severe. One person said his/her manager was getting annoyed about when that juror would get back to work, including veiled threats about his/her employment status. Someone had a family member undergo surgery during the trial. Another had a close friend with a death in the family. Another a dying relative.

Someone suggested we ask the judge for a day off to tend to our lives. One of the jurors put it into perspective. “Whatever issues we have in our lives that are affected by this trial, it’s small potatoes compared to what the defendant, the defendant’s family and friends, and the victims’ families and friends have gone through. As much as we have a duty to our lives, we also have a duty to see this case to its end for those people.”  Small potatoes indeed.

Reinterpreting everyday life

Someone said they noticed a strange car driving by his/her house and got suspicious. Another juror said that he/she was being more argumentative in everyday conversations. Someone else mentioned that he/she is trying to be more observant during activities in case that moment ever became the subject of a trial.

Another juror said that the process had made him/her more thankful for life and the privileges therein. I definitely agree; many countries don’t have jury trials or the disposition of innocence that we have in the USA.

I think we were all transformed by this process, and I think my comments above only scratch the surface of the impact it had on our lives.

Closing Statement

It wasn’t easy being a juror, but I do feel satisfied with the process, the quality of my fellow jurors, and the results of our effort.

I feel like I need a mental vacation to recharge myself.

And I have tons of other observations about the trial that I haven’t even gotten to yet.

I might need another blog post to tie this one off…

Making the most of time

Here are some tips for how to use time to your advantage when working on projects.

Time is often the enemy of a project, but I believe that’s because most people do a poor job managing their time and effort.  The lessons below are ones I’ve learned by approaching time management through the lens of cognitive science.  Use them to help you make the most of your time, no matter how big or small the task.


To maximize your productivity, you need to avoid all interruptions to your work.  Interruptions cost the time it takes to handle the interruption plus much more.

When you start working on something, it takes a good fifteen minutes to become fully absorbed in that task.  Once you’re in that flow, any kind of interruption — such as talking to someone or checking your email  — takes you out of that zone.  After you handle the interruption, you lose another good fifteen minutes re-absorbing yourself back into your work.

That’s why it’s essential to make your work environment as interrupt-free as possible.  Close your email, your IM clients, and your web browsers.  Put on your headphones.  Move into a conference room.  Do whatever it takes to get away — far away — from the interruptions and impediments keeping you from concentrating on the work at hand.

Evenly spaced deadlines

The best way to use deadlines is to spread them evenly over time because it maximizes the quality of your effort and likelihood that you’ll finish on time.  Committing to any deadline improves your chances of getting a task done on time and done right;  to improve those odds further, give your self several deadlines with regular intervals.

This observation comes from science.  A 2002 study researched the effectiveness of deadlines.  Three groups were asked to complete a task using one of three strategies: use a single end deadline, use three evenly spaced deadlines, or set your own deadlines.  Of the three groups, the evenly spaced deadline group had the fewest delays in completing the task and also submitted the best quality work.

If your project only has a single deadline, break it up into shorter deadlines for yourself.  And if your project is large enough to have several deadlines, spread them out as evenly as possible.  That way you’re maximizing your chances to create quality work and hit your deadline.

Impossibly short timeframe

If you want to try something a little bit different, reel in your deadline to a timeframe that you feel is unrealistically short.  The brevity of the timeframe keeps you focused on the essential parts of your work.

Plenty of great works have been created in amazingly short periods of time.  For example, Gershwin wrote Rhapsody in Blue in less than one month.*  Check out the awesomeness of Beck’s Record Club; each album is recorded within 24 hours.  Similarly, a friend of mine wrote a 50,000 word novel in 30 days for National Novel Writing Month.

When you work with strict constraints like this, don’t expect your effort to be fully polished.  Gershwin finished writing Rhapsody after its first performance; he improvised the piano solo at the premiere.  Beck’s recordings are really rough, yet it’s the roughness that makes them fun.  Also, my friend’s novel needs some editing work 🙂  You can create great things in a short time; time becomes a healthy constraint on your effort, making you focus on the parts that matter.

In short

Give these a try sometime, especially that last one. Find a task that you can’t quite get off the ground, then give yourself an unrealistic deadline for finishing a rough version of it.  Or if you’re more of the planner type, set up a project plan with several deadlines along the way.  And always, always remove any distractions that might get in your way.  I bet you’ll be amazed at the quality of your output.

*Rhapsody usually takes about fifteen minutes to perform.  My favorite recording of the piece, made in 1927 with Gershwin at the piano, was stripped down to nine minutes so it would fit on a single record (the longest recording medium of the time).  IMO, it sounds much more joyful and lively than the best modern recordings.

Seven plus-or-minus BS

If someone ever cites the “magic number seven” rule at you, most likely they don’t know what the hell they’re talking about.

You’ve probably heard the rule before.  If you give people a list of items to memorize, most people will recall between 5 and 9 items, hence it’s often called the “7 +/- 2” rule or “magic number seven” after the academic paper where the finding was published.

Lots of people, designers and non-designers alike, cite this in web design as the maximum number of categories you can have at the top level of a website.  I’m sure it’s used in other places too.

Unfortunately, those are bullshit applications of the rule.  The rule refers to only one thing: memorizing the exact sequence of digits like a phone number.  Most people can remember seven numbers in order before running out of short term memory.

But when you’re memorizing words instead of numbers, recall goes down to 5 plus-or-minus 2 (or less for long words).  And again, this is a very limited application of short term memory — exact, ordered recall.

Thankfully, web pages are different than phone numbers, and other researchers have done experiments that test the limits of memory. Let’s try this one; I hand you a list and give you a minute to memorize it:

trombone grammar spatula sparks heart look lab
quill radar aardvark antenna lamp share spare
wink noodle spout tan overt wall value
wild greet draft energy video statement contact

Then I ask you to recreate the list as best as you can.  You might get half of them right; you’d definitely get more than 5 +/- 2.  In fact, you would probably remember a clump of words at the beginning and a clump at the end, with some others scattered in between.

This is due to how our short term memory works.  We remember the first items we encounter (“primacy”) and the most recent items we encounter (“recency”) better than the middle crap.

Let’s try a slightly different experiment.  Instead of asking you to recreate the list, I ask you to recall where specific items showed up.  “Where did ‘trombone’ appear in the list?”  You would remember even more than the previous test.

I’d say this kind of prompted recall is the closest to how people use web pages — “where is that logout button? “I think I saw ‘checkout’ over here.” “The search bar was somewhere at the top of the page.” If that’s the case, then “7 +/- 2” is total BS as a design rule because people are capable of memorizing much, much more with the right help.

Put memory to work for you

This leads to an interesting question.  What can you do to improve experiences by taking advantage of how memory works?  Here are a few good tips.

Awesome beginnings and endings

Because we remember the first and last items we’ve encountered better than other stuff, you should put your best effort into creating awesome beginnings and endings.  Your audience will remember the beginning and end long after they’ve forgotten all that crap in the middle.


When you need someone to remember something, like a specific series of steps to accomplish a goal, use prompts to nudge them along.  A little prompt (i.e. “Where is ‘trombone’ in the list?”, “Step 1… Step 2…”) can invoke a chain of memories that people would have otherwise forgotten.


I bet you can recall all the lyrics to your favorite songs you listened to over and over again as a teen. People recall items better after they’ve been repeatedly exposed to them.  As time goes on, those items migrate to your long term memory. After a while, you’ll have the lyrics to “Mexican Radio” embedded in your brain for life.


Memorize this list:

lions tigers bears cowboys redskins eagles packers

I bet you could easily do it.  Our brains “chunk” similar kinds information together.  We can memorize chunks that we already know, like movie lines or NFL teams, faster and better than others.

If you remember anything from this post…

By now, I’m sure you’re wondering what to tell your boss when he insists that you need to cut your website’s categories down to “seven plus or minus two.” I’d say the limit is based on how many you can lay out without overwhelming the user. Try something, test it, try something else, then test it again. Repeat until all people – users and bosses alike – are satisfied.

If all else fails, just do what Amazon does. (They have 12 top level categories.) And if that doesn’t work, show that person the hundreds of other interactive items on your website. People remember how to use the site just fine despite the fact that “hundreds” vastly exceeds our short term memory limit of “seven plus-or-minus two.”

Have any memory tips appropriate for design? Please add them to the comments on this post.  In the mean time, don’t be afraid to tell someone that they have no fucking idea what they’re talking about if they spew that magic number seven crap at ya.

Like my blog?  Try my twitter feed!

The Love

One of the lynchpins of my office is leaving.  After hearing the news, a coworker asked me if I knew why.

I said, “there’s an intangible force that runs through every person in every company.  I call it ‘The Love.’

“The Love comes from two places.  There’s Intrinsic Love — that’s the love of what you do.  When you wake up in the morning, excited to get in the office and do the thing you were hired to do — that’s Intrinsic Love bubbling over.

“It also comes from Extrinsic Love — that’s the love other people give to you for doing the thing you do in the office.  They give it to you in the form of thanks and accolades.

“The Love is a finite thing, and you use it up little by little.  You have to refill it, and that refill comes from Intrinsic Love or Extrinsic Love or both.  If your work or your rewards can keep refilling The Love, then you’ve got a great thing.

“But if you’re not getting enough of The Love for your effort, then The Love runs out.  Maybe it’s because you don’t like what you do.  Maybe it’s because others don’t appreciate what you do.  Regardless of the reason, the effect is the same.

“His Love ran out.  That’s why he’s leaving.”

“I see,” my coworker said.  “It’s like a relationship.  Sometimes they go great.  But sometimes she’s a cranky bitch and the bitch wears you out little by little until you don’t ever want to see her bitch face again.”

“You got it.”

“Where are you going?”

“I need to go to the bathroom.”

And that’s the story of The Love.

Own your problems

If solving a problem is like throwing a punch, then owning a problem is like going jujitsu on its ass.

Once in the past, I was lucky enough to see a competitor’s “kill sheet”* for a product that I was involved with.  It was full of lies — blatant, demonstrably false lies.  We dealt with it internally, but that didn’t make me happy.

What would have made me happy?  Posting the document on our website and tearing their arguments to shreds.  At worst, we would address the complaints and FUD about our app.  At best, the competitor would send us a takedown notice, thereby proving they wrote that crap.

I call this philosophy “owning your problems.”  Anytime someone complains about you or does something to piss you off, turn it to your advantage.  In my case, we solved the problem but we never owned the problem.

Another example is the Palm Pre vs. Apple iTunes battle.  Palm hacked their Pre cell phone so it would sync with iTunes.  In response, Apple modified iTunes to stop syncing with the Pre.  Next, Palm updated the Pre to sync with iTunes again.  It went back and forth for a bit until Palm gave in to Apple.

If I was Apple, not only would I allow the Pre to sync with iTunes, I would let any phone sync with iTunes.  Palm’s attempt to leverage iTunes is a concession that iTunes is superior to any sync application Palm can make.  Apple may feel good about their solution, but they missed the opportunity to own the problem.

At its core, this is an issue of control.  Are you going to let your competitors control the conversation?  Or can you make the conversation your own?  There’s money in it too; Get Satisfaction and Brands in Public built businesses where you have to pay them to own your problems.

The next time you’re facing a problem caused by some external entity, ask yourself if you’re solving the problem or owning the problem.  Are you fixing it or turning it to your advantage?  Chances are you’re missing an opportunity to leap a mile instead of crawling an inch.

One last example.  A Jets player twittered about his lack of play time.  The coach responded by benching the player for a week.  Problem solved.

If I was the coach, how would I own this problem?  I would have twittered back:

@davidclowney work harder and you’ll get more play time. Now put your phone down and get back to practice.

That’s owning your problem, and with 34 characters to spare.

*A “kill sheet” is a list of points you can use to eliminate a competitor during a sales process.

Google Voice is super creepy

I signed up for Google Voice.  Mostly I wanted to see how it works.  I paired it with my cell phone, but I haven’t used it since.

Meanwhile, a friend of mine replaced his cell number with his Google Voice account.  I sent him a text from my cell phone to his Google Voice number a few days ago.

And the text showed up in MY Google Voice account too.

I tried it again to make sure.  Screenshot is below (phone number is obscured to protect my friend):

google voice flaw

Why is the message I sent from my phone to my friend’s Google Voice account appearing in my account?  That means Google decided that messages received by and sent from his account should appear in mine too.

To be clear, I didn’t use my Google Voice account when sending or receiving the message.  Google looked at the phone number, matched it up with my account, then stuck it in my inbox.  To date, the only messages in my Google Voice inbox are the welcome message and the texts to that person.

This is a ridiculous security and privacy hole.  If you swiped someone else’s phone for just a minute, you could attach it to a Google Voice account then receive all texts between that person and any Google Voice user.

I’ve been a big fan of Google’s past products, but this is the first time I’ve ever been freaked out by something they’ve done.  I hope Google realizes the flaw here and fixes it quickly.