Web Design: The Design of People

Excerpted from New Perspectives on Web Design (Smashing Media)

Article by Nishant Kothary


I am going to get you fired!” yelled Prakash1, the heavyset, smoothtalking and very politically savvy engineering manager, so loudly that I could feel my desk vibrate. I’d just returned from lunch and was clearing out my inbox when he marched in looking like Mount St. Helens right before it erupted. He was livid that my executive status report (a weekly report that I sent to all the stakeholders of our project, including the vice-president of the company) announced that the overall project status was “red”, compliments of Prakash’s team letting a few critical milestones pass. In other words, we were going to miss our launch date, again. We were over six months behind schedule now.

My brain flashed back six months to a conversation with my manager, John. “We need to chat,” John began cautiously. I instantly braced for bad news. Thanks to his lackluster bedside manner, it went south pretty quickly from there. In the next thirty minutes he delivered a message in almost undecipherable corporate-speak that amounted to: You really suck at your job, it’s making me look bad, and if you don’t get your act together soon, I’m going to have to fire you.

It hit hard because I had been working 70–80 hours a week and giving it my all in an environment that was as dysfunctional as a chimpanzee community with two alphas. We were understaffed, overspent, under tremendous pressure from the market, in the crosshairs of the CEO and, to make matters worse, I was fresh out of college and learning the ropes. And I was pretty green: that’s software industry-speak for naive. In a nutshell, the project had gone to hell, and I was the perfect fall guy.

“I don’t know what I need to do to fix things anymore. I need you to walk me through this,” I said with resignation to John. Begrudgingly — after all, he was burning the candle at both ends, too, and really didn’t have time to deal with his pesky employees. He started making a list of action items for me on the whiteboard. One of them was: Fix ownership column for each milestone in status report. Each milestone in the status report was to have one clear owner. One could debate the true owner for many of the milestones, and my default in such situations was to list myself as the owner. I was, after all, ultimately responsible for getting the project out the gate. So, when we missed a milestone, it was generally seen as my fault. And I didn’t care.

“You don’t own anything. You have no control over when one of those items is late or on track. You only have influence. Ultimately, someone else is responsible for each of those pieces, and you simply need to report their progress toward completion of their line-item,” said John matter-offactly. He instructed me to remove my name from the owner column for approximately twenty-five of the milestones my status report tracked.

I cringed.

It wasn’t the first time I’d heard this. In fact, I’d rejected these words from the leading project management books. I philosophically disagreed with the tactic because, from a practical perspective, I reasoned, it simply shifted blame and generally ignored seeking out a solution to the overarching problem: the project had gone off the rails. But things change when you have a gun to your head.

I transferred the commandments from the whiteboard to my notepad and left John’s office that day determined to save my job.

And now here we were.

As I watched Prakash — the key to many of our critical organizational problems and, in fact, the true owner of the most critical milestones on the project — hyperventilate, I couldn’t help but smirk. Success, even when it comes in this deranged form, still releases the same happy hormones into the blood stream. My amygdala (the most ancient part of our brains that, among other things, is responsible for the fight or flight response) slowly crossed its arms across its large pectorals with a smug grin on its face, leaving my imminent response in the capable hands of my neocortex: the newest part of our brain responsible for some of our most complex decision-making.2

“Dude. I’m just the messenger,” I shrugged with deliberately practiced nonchalance. “You gave me these dates a few weeks ago. You didn’t hit them. Now, if you’re telling me that we can still ship on time irrespective of your items being late, then let’s talk!” He just stared at me with rage and wonder for the next few seconds as his mind tried to work out how the tables had been turned. Then, abruptly, his amygdala took over again. He yelled some incoherent gibberish, swore at me one last time and stormed out of the office.

The product eventually shipped three months later, a full nine months behind schedule3, to lackluster reviews and angry customers. Reeling from the epic death march, most of the team quit and left for other jobs. I received a good performance review at the end of the project, and was then assigned to one that was even more visible and important to the company. I had, after all, done my job “well”.

I quit a few weeks later.

The Goal of What Follows

My account, even if a little extreme, is hardly unique. We’ve all been there in one capacity or another: a hard-to-deal-with co-worker, an incompetent boss, a micro-managing client, seemingly deranged leadership, design by committee... the list goes on.

There are myriad ways to slice and analyze my story. Some will empathize with it and express anger over dysfunctional work environments. Some will point a finger at bad leadership. Some will focus on the alleged worthlessness of middle management. Some will attribute the failures to the process — perhaps you should have used Agile methodologies. And some will suggest that I was, in fact, the true culprit and should have been fired; after all, I had led the project.

None of these analyses are wrong. In fact, they’re all right. And there are many more I haven’t mentioned that would apply as well. But no matter how much we analyze such situations in our postmortems and vow to avoid them at all costs in the future, we just can’t help but frequently find ourselves in similar predicaments. While we have amassed a tremendous number of tactics and patterns that often help us narrowly avoid dysfunctional situations, we have a poor understanding of the root of the problem and, as a result, very little control over our destinies.

After years of working my way through more dysfunctional situations than I’d like to remember, I have firmly settled on a belief (in fact, it is the only belief I hold sacred anymore): almost every problem we face at work (and play) begins and ends with one or more people.

While we run off to fix processes, hire experts, solicit feedback from users, increase the number of code reviews per week, switch our programming methodologies, churn out more mock-ups, get blue in the face explaining our strategies to stakeholders, and implement a thousand other makeshift fixes, the real solution continues to elude us. Creatures of habit that we are, we simply shut our eyes and swim harder upstream until we find ourselves spent and jaded, ready to quit our jobs. But as someone wise once said, “The definition of insanity is doing the same thing over and over and expecting different results.”

The goal of what follows is simple: to introduce you to the human being as the center of every success or failure in our lives. But not in that tired way we’re all guilty of where we commiserate and vent on Twitter. Or the way where we publish blog posts about the bureaucratic deadweights that are the true bottlenecks to innovation. Or even that way where we write articles, chapters and books that disseminate best practices for dealing with said deadweights. We’ve done it all before, and we’ll surely do it again. But right now, let’s resist the convenient cover of insanity. Let’s stop putting more lipstick on the pig, and instead explore why the pig is so darn ugly in the first place. That is, let’s talk about the root of the problem instead of the symptoms.

Grab a seat (and a drink).

Too Many Cooks Don’t Spoil the Broth

A few years ago I happened to find myself in charge of the redesign and consolidation of a set of very popular developer community sites, a project we’ll dub Project Unify. We were combining five different sites, each of which had been serving a different target audience, and run by a different internal team. Together, the sites served thousands of unique types of media: everything from HD videos to short blog posts. Some organized their content in the form of shows; others featured live streaming content. The media came in all shapes, formats and sizes. The visual tone and information architecture of each website was different. By most measures, it was a complicated redesign.

To make matters worse, there were a ton of stakeholders across the company who were going to be involved in this project: hosts of the various shows, developers working on the different sites, the founders of the sites, managers, and even a few executives. And most of them weren’t very happy about the existence of this project, for it meant that their day to-day lives were about to change. Not to mention, they liked how things were.

I had tried to limit myself to smaller projects with fewer stakeholders after my experience with Prakash and team, and this was my first big project since then. I was nervous — after all, swimming with sharks and coming out alive is hardly a good predictor of your ability to survive the next expedition. But I was also excited. Thanks to an initial book recommendation from a friend, I’d ended up immersed in the world of human behavior — cognitive psychology, behavioral economics, neuroscience, anthropology, evolutionary biology and so on — and had amassed enough knowledge to warrant an experiment with a larger sample size.

Project Unify was a good opportunity for my career, but an even better one to put some of my newfound knowledge to the test.

The Psychological Effects of Fair Systems
In Sway: The Irresistible Pull of Irrational Behavior, Ori and Rom Brofman wote, “A group of researchers asked hundreds of felons from Baltimore, Detroit and Phoenix to fill out a survey. The first part of the survey consisted of factual questions, such as the nature of their conviction and the length of their prison sentence. In part two, the survey moved on to the questions about perceptions of fairness: How were you treated? How did you like the judge? Were the lawyers nice to you?” The researchers were attempting to deduce what factors affected inmates’ perceptions of the fairness of the justice system.

What factor do you think most affected their perception the most? The length and severity of the sentence, right? Not quite.

The researchers found that respondents placed as much weight on the legal process as they did on the outcome. “One of the factors weighed most heavily by respondents was how much time their lawyer spent with them. The more time he or she spent with them, the more satisfied the respondents were with the ultimate outcome,” wrote the authors. This is surprising because one would expect that inmates who were slapped with longer sentences after having spent a great deal of time with their lawyers would be more disgruntled. But the exact opposite was true. “Although the outcome might be exactly the same, when we don’t get to voice our concerns, we perceive the overall fairness of the experience quite differently,” concluded the authors.

Designers are prone to hiding from their stakeholders. Each of us has our reasons, but most of them are grounded in the fear of being told how to design something. But researchers have found time and again that fulfilling someone’s need to be heard has more influence on their perception of the outcome of a situation than the actual outcome.4 And if you’re smart about it, you can both influence stakeholders into cooperating and create the design you believe to be right for the project at hand. On Project Unify I forced myself to make time for one-on-one conversations with around twenty stakeholders. I wanted them to meet me and get to know me. The meetings ranged from getting lunch together to letting developers wireframe their vision of the website on their whiteboards. I always kicked off the meetings with, “So, tell me what you think we should be doing for Project Unify?”

And boy did they.

Some vented about politics and bureaucracy (I joined in). Some vehemently disagreed with the project’s existence (I empathized and reminded them about our pay grade). Others felt it was time for a professional designer to take this on (I hid my imposter syndrome5 symptoms). Some focused on a specific aspect they really cared about (I took notes). And there were those who were just happy to be out getting a coffee during work hours (my type of people). It was an intense week.

But by the following week, the timbre of Project Unify was a solid positive. Stakeholders were cautiously optimistic, even excited to launch into such a contentious redesign. The turnaround in attitude far exceeded my expectations, so much so that informal one-on-ones have become an indispensible part of my designer repertoire.

A tremendous amount has been written about stakeholder interviewing on the Internet. I trust you will be able to search your way to the articles. But before you start creating checklists of interview questions about brand strategy, success criteria and user personas, consider for a second that while we need information from stakeholders, they need security from us. They need to be heard, and this need, when left unfulfilled, justifiably jeopardizes the project at hand in unfathomable ways. And the worst way to treat someone hoping to be heard is to walk in with a clipboard and a checklist. There will be time for that later. First, focus on what’s important: the little things.

It is the little things, after all, that can have the biggest effects.

Anchoring Good Behavior in Design Reviews
Getting stakeholders to feel optimistic about a project is one thing, but translating that optimism into useful and favorable feedback is entirely another.

There is a fascinating concept in psychology known as anchoring. Anchoring is a psychological phenomenon whereby humans rely heavily on the first piece of information they’re offered (known as the anchor) in making subsequent decisions.6 Dan Ariely, behavioral economist and author of a few of the most fascinating books on human behavior, provides a fundamental example on anchoring in his first book Predictably Irrational: The Hidden Forces That Shape Our Decisions: “A few decades ago, the naturalist Konrad Lorenz discovered that goslings, upon breaking out of their eggs, become attached to the first moving object they encounter.

Lorenz knew this because in one experiment he became the first thing they saw, and they followed him loyally from then on through adolescence.”7

Over the past few decades, researchers have confirmed the role of anchors in all walks of life through seemingly bizarre findings: we are more likely to marry people whose names start with the first letter as our own, pick products whose brand names share the first three letters with our own, give favorable reviews to people who share our birthdate, and more.8 In fact, the effects of anchoring extend even into the moral realm as Ariely demonstrated in his latest book, The (Honest) Truth About Dishonesty: How We Lie to Everyone—Especially Ourselves. Ariely conducted a study showing that you could almost eliminate cheating on tests — that is, you could literally make people more honest — by simply having students sign a simple honor code right before they took a test.

A regular exam bubble sheet (top) and a modified bubble sheet with honor code signature slot (bottom).

Back on Project Unify, I wondered to myself if I could use the power of anchoring to shepherd a very large and diverse group of stakeholders through the design review process without the drama and conflict we’ve come to expect in such situations. Was there anything I could do or say that would anchor the individuals in the group to focus on providing logical feedback rather than reacting from the emotion that they (and all of us) would naturally feel from looking at new colors, shapes and patterns that would be part of the new design? I thought it was worth trying and came up with a simple solution.

Right before my design team started working on the new design, I sent an email to the entire group of stakeholders. The email was structured as the customary piece of correspondence that explains the design process, but within it were hidden several anchors.

Let’s walk through this email together.

The Email: You Are Getting Sleepy, Very Sleepy
I’ve tried my best to reproduce the email in its original form but, inevitably, a few names and details need to be changed to protect the privacy of all involved. That said, none of the changes take away from the discussion at hand.

Notice that the email was sent after hours on a Friday. This may not be an option for all projects, but I’ve found it increases the odds (unscientifically, of course) that your recipients will read the email in a positive frame of mind (first thing on Monday before the stress of the week kicks in).

I also note here that stakeholders are encouraged to not designate others at the company as stakeholders. That decision needs to be made by me. However, in return for this, they get to be part of the limited group of core stakeholders. A fair trade.

There is one tiny element of anchoring here — “and this includes feedback loops”. It set the expectation that the act of providing feedback would be bound to a tight schedule (much like the act of actually designing the site).

Next, an FAQs section as shown above: Again, I’m emphasizing fairness. The takeaway is that we are all part of the team and we all have to contribute equally.

This is a message of support for anyone who happens to be feeling anxious about the process. There is an escape hatch, but it has constraints (I’ll help you over email).

There are several anchors hidden within this section: reviewing designs individually isn’t feasible; providing written feedback is important; design is often subjective; the big picture is more important than individual features; “trust me”; and more.

Next up, a milestones section, but not just for various stages of design, but for providing feedback as well.

Holding stakeholders to milestones for providing feedback is not a new concept, but one we often stray away from because we generally don’t know how to argue for it. The best argument is generally simple arithmetic. The design timeline itself was extremely tight for Project Unify. The design team had nine days (counting the weekend; this was definitely a burn the midnight oil project) to produce the wireframes for the new site. In comparison, the stakeholders had three full days to provide feedback. All in all, this proved to be another excellent anchor, and also a way to control scope.

Finally, the most important section: how to provide feedback. While most of this section is process-oriented, the final bullet point — “Your feedback must be actionable, rational and reasonable. In other words, focus on specifics of the wireframes and not wishful/nice-to-have things” — stands out. While it wasn’t equivalent to an explicit signature (remember, Ariely had subjects physically sign an honor code before they proceeded to take the test), I hoped that this final point, combined with written and verbal acknowledgements from all the stakeholders in the following days would nudge the stakeholders to behave more rationally.

A better solution, in hindsight, would have been to have stakeholders individually respond with a digital signature of sorts to pledge their rationality; some email software like Microsoft Outlook allows you to enforce a binary response (“I accept” or “I do not accept”) from each recipient upon receipt of the email. Also, if the Brafman brothers’ report on inmates’ perceptions of the legal process had broader applicability, then not only would this kick-off email succeed in inspiring fruitful participation in the process, but stakeholders would feel positive about the entire experience irrespective of the outcome.

So, the question is: did it work?

The Results

Simply put, yes. But it was the process and not the outcome that left me in admiration of the research that enabled the outcome. Sure, we successfully designed the website in three weeks. By any reasonable measure, this bordered on impossible given its scope. But what I found most fascinating was that the stakeholders not only provided feedback on time, but also offered incredible insights in a way I hadn’t witnessed earlier in my career.

Many stakeholders went above and beyond in explaining their rationale when they disagreed with design team choices. Some provided helpful historical information to aid us in making the right design decisions. Others used their deep subject matter expertise to provide context for the changes they suggested. Developers specifically focused on the feasibility of implementing certain aspects of the proposed design. And a non-trivial number of stakeholders voluntarily pulled themselves out of the process. You got the sense that everyone was not only invested in the project, but also focused on moving the process forward. Particularly when the times got a little hairy.

For instance, at a later phase of the project, the art direction — specifically, a shade of teal that was a part of the art board — was met with some resistance. In such cases, stakeholders (even the best designers) often focus heavily on their personal feelings towards the art, as in “I really don’t like this!” But, there’s no way to truly weigh such feedback, and such situations typically tend toward heavy contention. The Project Unify group members, after acknowledging their visceral distaste for the color, focused on providing actionable and rational feedback: everything from suggestions on tweaks to the color, to its disconnect from the company brand. The stakeholders acted like ideal designers.

Now, you’re probably wondering what was the essence of the email — what can you take and apply to the next project kick-off email that you send? There are obvious no-brainers that we’ve all picked up along the way from basic project management books; for example, by outlining the process clearly I reduced uncertainty, provided actionable next steps and, in turn, improved the chances that this project was going to succeed. While it’s impossible to know exactly else what really helped and what had a neutral effect on this specific project, here are the core principles that I personally took away:

  1. Anchoring: The email set expectations about the design process with an eye on encouraging desirable behaviors among participants. It did so by employing the power of anchoring repeatedly.
  2. Fairness: The design process framed in the email employed what we know about the effect of fair systems in inspiring positive human behaviors.
  3. Honor Code: The phrasing and choreography of the email capitalized on the anchors that specifically influence short-term human morality.
  4. Social Coordination: The email unified the team by making the style of the feedback something that all stakeholders shared in common.
  5. Social Norms: The email removed me from the top of the accountability hierarchy and instead replaced my position with the project. If one person were to ignore the directions, they would be hurting the project instead of me.

It is worth mentioning that it wasn’t an entirely smooth ride. There were a few stakeholders who turned in feedback far past their deadlines. When I rejected their feedback on the grounds that the time had passed, they escalated to the executive sponsor (and original founder of the sites). Fortunately, thanks to past experience, I had put some air cover (support from the most senior influencer on the project) in place before the project kicked off. He dismissed such escalations, in turn adding another strong psychological force to the forward momentum of Project Unify.

At this point, we’ll stop talking about other people and start looking at our problems’ roots from another angle. After all, there’s a hard limit on what you can learn from even the best observations and discussions about other people. As the old proverb goes, “Nothing ever becomes real until it is experienced.” Sure, we’ve used the word we throughout this discussion, implying that we — you and I — are prone to fall prey to all of the same psychological traps. But let’s admit it, we aren’t as cuckoo as others. Right?

You may want to refill that drink before you proceed.

Designing for Designers

A few years ago I co-founded a little community website for Web designers and developers. Our community published articles by invited guests (not unlike Smashing Magazine) about everything from UX strategy and the Web design process to management and philosophy. We also built open source software and shared it on a section of our community site.

Over time, the website gained some popularity with the Web community. The incoming traffic was enough for our team to consider redesigning the website to better handle our future plans. The original website was something I’d designed and coded over a couple of weekends. It wasn’t very maintainable, and in the first year of running the website, we’d learned much more about our own brand, goals and identity. So, we set a deadline for ourselves, and I agreed to lead the redesign project. We shall dub it Project Redo.

I determined pretty quickly that I needed some help for this project. I had many other responsibilities at my job; the website redesign was simply one of them. But, I wasn’t about to hand over my baby to just anyone. I needed someone I could trust, someone who’d give their life before letting my baby get hurt.

I reached out to a friend and local designer who fit the bill. Let’s call him Dave. I called him on the phone and we chatted about the goals of the project. The stakes were high, I told him. “You have an incredible amount of freedom on this project. I am, after all, the only stakeholder. I want you to pretend like you’re redesigning your own personal website. I want that care and energy. You game?” Dave signed up. In that moment, I became not only a friend and peer designer, but also a client.

We split the work between ourselves. I would be responsible for the information architecture. He would be responsible for visual design and front-end markup. We agreed to collaborate through it all. With that, I went to the drawing board to work on the information architecture. A week or so later I posted the wireframes to Basecamp. Dave reviewed them, we had a quick phone call, and he set out to turn the skeleton into a fullcolor being. A few days later he posted a color composition of one of the pages to our Basecamp project to give me a quick peek at the art direction. Needless to say, he really liked what he’d created. It’s only natural, right?9 Unfortunately, I could not see what he saw. Where he saw beauty, I saw the opposite. It was almost as if he was functioning in a reality entirely different from mine.

And, as the ingenious Sally–Anne test illustrates, he was.

The Sally–Anne Test
I first came across this gem in Kathryn Schulz’s excellent book, Being Wrong. The Sally–Anne test is taken by children between the ages of three and four. It involves staging a simple puppet show involving two characters, Sally and Anne (figure a below). Sally places a marble in a basket, closes its lid and leaves the room (figure b). Shortly thereafter, the very naughty Anne flips open the lid of the basket, pulls out the marble (c) and places it in a box sitting in the corner (d). Now, the child who has witnessed all of this is asked a simple question: when Sally returns, where will she look for the marble (e)?

Almost every child in this age group exclaims with confidence, “In the box!” This answer is baffling to adults for the obvious reason: there’s no way Sally could have known that the marble was mischievously displaced by Anne because Sally wasn’t around to witness that. But the children don’t care about this detail. To them, reality and their minds’ representations of reality are one and the same. Sally thinks the marble is in the box because, well, it is in the box.10

The children provide an incorrect answer because they have yet to develop what is known as the theory of mind (ToM), a differentiating feature of human beings when compared to most other mammals. We develop ToM by the time we’re five years old. In fact, if you were to administer the test to five-year-olds, you would be greeted with sheer bewilderment for having wasted their time before they gave you the right answer.

Theory of mind bestows on us two critical pieces of knowledge that, when wielded properly, have the ability to bring out the best in us:

  1. Our mind’s version of reality isn’t true reality: it’s just one interpretation of reality.
  2. Everybody has their own mind and, thus, their own interpretation of reality.

But as David Eagleman, author of Incognito: The Secret Lives of Brains writes, “There can be a large gap between knowledge and awareness”.11 Back on Project Redo, I was completely unaware of the vicious cycle of irrationality I was about to enter. I called Dave.

It’s My Party and I’ll Cry If I Want To
I gave Dave my honest feedback. “I don’t think this is the right direction, Dave. I don’t know what else to say other than, it’s too expected. The design is not bold.” My Dan Ariely bobble-head was staring at me, and I admitted to Dave that I could be under some irrational spell. It was his call on how to proceed (but I had my fingers crossed behind my back). Seasoned as he was dealing with clients like me, he didn’t flinch. “Let’s try a completely new direction. It’ll be fun.” He went back to the drawing board, but his first design had already done the necessary damage in the form of setting a very negative anchor for me.

I just couldn’t shake the fear that Dave was in over his head on this project. And by the time he posted the next color comp, a beautiful and entirely fresh direction for Project Redo, I was well into a psychological tailspin. What’s worse was that I was completely unaware of it.

When I first opened the newly posted design, I was pleasantly surprised. It was definitely different. But after a few minutes, my limbic system — responsible for emotions such as fear and anger, and also the home of the amygdala that I mentioned earlier — took over. I concluded that this new design, while better, was simply a cousin of the first one, which, I was convinced, was truly horrible. Knowing well that I may have been under the spell of irrational biases, I decided to sleep on it. The next day, I pulled the design up on my monitor and nothing had changed. In fact, it’d gotten worse. I showed it to my wife, a teammate and a few others. Nobody shared my reaction. Most people said, “It’s nice. But I’m not a designer.”

I reasoned with myself, “OK, I’m a designer. I’m someone who’s very aware of irrational behavior. I know how it works. I’ve read so much about the brain and psychology. I’ve followed the advice of many of my favorite authors: everything from getting a devil’s advocate to letting my initial reactions simmer. But I still feel that this is the wrong direction. I must be right. Right?” Of course, I concurred with myself.

I then quickly decided that I had to save the day, and committed the ultimate designer faux pas: I started working on a color comp myself.

Eagleman was twitching somewhere in the distance as, in one swift moment, all of my knowledge escaped my awareness. But what’s truly frightening is that this occurs far more often than most of us know, and this is by design. It is quintessentially human.

And nothing exposes this elegant flaw better than a seemingly unrelated fact about ourselves: most of us can’t draw.

In Order to Learn to Draw, You Must Learn to See
“I can’t draw,” said my wife plainly. “Well, I can draw stick figures, but that’s about it. But sure, I’ll give it a try.” I had suggested that we work our way through the world’s most widely used drawing instruction book, Betty Edwards’ modern classic, Drawing on the Right Side of the Brain. Most of us can relate to my wife’s words because most of us can’t draw any better than the neighbor’s kid. And the prevailing belief around why we can’t draw is that the ability to draw is an innate gift: something we’re born with. But Edwards vehemently disagrees with this theory.

Instead, she believes that anyone can learn to draw realistically with a little instruction. She’s proven this an infinite number of times through her books and courses. Edwards writes, “A beginning drawing student asked to draw a frontal view of a chair often distorts the retinal image of the chair seat into a fully round or square shape, even through the retinal image of the seat is a narrow, horizontal shape.” She identifies the culprit behind this phenomenon as a core neural process known as size constancy: a process that ensures that our perceptions of objects are relatively constant irrespective of their true distance from the retina. Without size constancy we wouldn’t be able to identify an elephant on the horizon from its tiny silhouette. “Size constancy can muddle perception by actually overriding direct information that hits the retina, causing us to ‘see’ images that fit pre-existing knowledge,” continues Edwards12.

A chair drawn with proper perspective (left); a chair drawn under the influence of size constancy (right).

The key to Edwards’ drawing instruction method is that she focuses on teaching her students how to temporarily turn off visual processes like size constancy. Put another way, Edwards teaches her students how to see what is rather than what their brain thinks is. There’s a subtle, but profound difference between the two, one that some individuals often stumble upon naturally. For the rest of us, there’s Edwards’ method. It is so effective that my wife was able to dramatically improve her self-portrait after following just a few pieces of advice in Edwards’ book.

My wife’s first attempt at a self-portrait (left); my wife’s attempt at a self-portrait after 15 minutes of instruction from Edwards’ book (right).

Now consider that size constancy is just one of thousands of silent neurological and physiological processes that are involved in the proper functioning of the human being. And, unlike size constancy, we don’t have the ability to access them or turn them off. In fact, our proper functioning relies on these processes working non-stop behind the scenes. When combined with our own personal experiences, these processes play a major role in shaping our reality: a reality that, even if we pass the Sally–Anne test by the time we’re five, often remains unfathomably distorted and, more importantly, uniquely our own.

Unfortunately, Project Redo was a runaway train at this point, and there was nobody around to help my brain make the cognitive shift it needed to see reality for what it truly was.

Saving the Day
In The Honest Truth About Dishonesty: How We Lie to Everyone—Especially Ourselves, Ariely writes about the prevailing economic model for cheating and lying known as SMORC: simple model of rational crime. He writes, “We all seek our own advantage as we make our way through the world. Whether we do this by robbing banks or writing books is inconsequential to our rational calculations of costs and benefits.” But this doesn’t quite paint the entire picture. “How can we secure the benefits of cheating and at the same time still view ourselves as honest, wonderful people?” he challenges. “This is where our amazing cognitive flexibility comes into play. Thanks to this human skill, as long as we cheat only a little bit, we can benefit from cheating and still view ourselves as marvelous human beings. This balancing act is the process of rationalization, and it is the basis of what we’ll call the fudge factor theory.”13

Along these lines, when I posted my own design to the Project Redo Basecamp a few hours after I started working on it, I titled the message with the auspicious and rather obnoxious, “A Fresh Direction.” In it I waxed poetic about the strengths of this new design and why it was the right way forward (acknowledging, of course, that I could be completely wrong with my assessment).

By now, my brain had constructed an elaborate story about the entire situation, and thanks to the fudge factor I had given myself the part of the protagonist. I was the hero who, after much contemplation and tribulation, was going to save this project. I had to do what I had to do, but it was for a good cause, I reasoned.

In hindsight, the six hours I spent working on my concept didn’t hold a candle to Dave’s entire week of hard work. Dave must have seen that immediately when he held my design up next to his, but decided to remain silent. Instead, he did what we often do when faced with confrontation in the design process: he tried to salvage the situation by suggesting that he take a crack at combining our designs. I didn’t particularly like the idea, but didn’t quite respond with that. I avoided confrontation as well. The neocortex had stepped in for us both, but it was a little too late. I said, “OK, let’s give it a shot.”

We didn’t make it past two Frankenstein versions of the design. By then, there was a tinge of undeniable awkwardness in the air, and we both knew that the project had gone off the rails. We decided to chat on the phone. I finally admitted, “Dave, I don’t think this is working out. No hard feelings, but I think I’d like to take over the visual design.” But this time Dave surprised me by pushing back. “Nishant, I think my second concept was the best one. I even showed another designer the two designs side-byside, and he agreed,” he said. He shared the name of the other designer, a well-known veteran whom I respected.

I felt like the wind had been knocked out of me. In an accidental moment of clarity, I responded, “I think I should take myself out of the decision-making process.” Dave, shocked, agreed. We hung up. Dave had stuck his neck out, and I respected that. But I still couldn’t see what he could see. I could even admit that maybe my design wasn’t the right one. But I couldn’t see how his was.

As it turns out, willing ourselves to see the world differently has some unfortunate hard limits. And it provides the final clue to the source of our woes.

Seeing is Believing isn’t Seeing

Optical illusions provide a great example of our limitations.14 My personal favorite is the checkershadow illusion first developed by MIT researcher Edward Adelson.15 The illusion here involves deciphering the colors of the squares marked A and B in the left image of figure 7. When asked, participants (including you) will indicate that A is dark gray, while B is light gray. The squares, in fact, are the same shade of gray. And this becomes clear as day when you connect the two squares with a solid gray rectangle as shown in the right image. But the best part of this illusion is yet to come.

If you take the gray rectangle away (look back at the left figure), it’s as if we’re stupid again. No matter how hard we try, we see the two squares as entirely different shades of gray.

Despite the fact that our visual system — more than thirty different parts of the brain dedicated to helping us see — is about the most anatomically sophisticated part of the human body, we are predictably fooled over and over again by optical illusions like Adelson’s checkershadow. In Predictably Irrational, Ariely wonders how often, then, must we be predictably fooled in areas where the brain provides no specialized help? Like making financial decisions? Or, a little closer to home, recognizing a great design as great?

Ariely’s research deals with discovering and documenting these so-called illusions of the mind, more formally known as cognitive biases. Anchoring is but one of hundreds of cognitive biases that exist in human beings. Once you’ve read these findings, it becomes virtually impossible to view the world, and yourself, the same way again. In one sense, it’s a relief to have scientific explanations for some of life’s troubles. But in a different sense, you are confronted with how much you don’t know about the world, how much you take for granted, and how fallible we are as human beings.

Back on Project Redo, I was starting to get convinced of my own fallibility in the situation. I sent the two designs for a blind vote to the rest of my team adding no context other than, “Here are two options for the design. Pick the one you like the most.” All five of my team members voted for Dave’s design. The decision was clear to me even if I couldn’t understand it. I was Adelson’s smirking revenge. I couldn’t see the squares as the same color no matter how hard I tried, yet I knew they were the same color. So, I made the call.

“We’re going to move forward with yours, Dave. Thanks for sticking your neck out there,” I posted on Basecamp. Dave was elated. Three weeks later we finished the website and it received much fanfare. It was a hit with the community, was featured on several design showcases, and even won a few prestigious awards. Dave maintains that it remains one of his best portfolio pieces even today.

And for me, it remains an undying reminder of my own irrationality.

And… Scene

As I look back to my first true encounter with workplace dysfunction — my episode with Prakash and team — I can’t help but wonder what I would have done differently then had I the knowledge I have now.

Over the past few years, I’ve had the pleasure (and pain) of discovering a whole new side of humans. By applying the work of folks like the Brafman brothers, Ramachandran, Eagleman, Gigerenzer, Edwards, Ariely and many others to the world of design collaboration, I’ve been able to navigate through many tricky situations, and have also been able to develop a whole new set of seemingly counter-intuitive rules of thumb to help me along the way. To list a few (and most of these are from experiences that I haven’t specifically mentioned here):

  • Don’t try to educate clients and stakeholders about design. Rather, spend time priming them to realize that it’s not their domain.
  • Never conduct a design review in a conference room with all stakeholders present together. Social conformity studies have firmly established that this approach is destined for failure. When you succeed, it’s simply because statistics can be forgiving.
  • If your client demands multiple versions of a design, you will improve your chances of a quick sign-off by creating three versions: two that are similar (the one you would like the client to pick needs to be better), and another that’s obviously the worst and dissimilar to the pair. That said, you might be better off firing the client.
  • Getting even great designers to collaborate will generally produce a design that isn’t as good as that produced by an individual great designer (unless, those designers can really function as one; rare, but certainly possible). This is because you are attempting to converge independent realities and average independently great visions.
  • Trying to convince someone of something that’s contrary to his or her existing belief generally worsens the situation. You have to look for a subtler solution to deal with the individual.
  • In most circumstances at work, praise and positive reinforcement are far better motivators than monetary or other in-kind payments.
  • Stakeholders generally want to be upstanding citizens of the design process even if their behavior may seem to indicate otherwise. Learn to read between the lines to influence the natural propensity of humans to want to do good.
  • The worst goal you can set for yourself is to be the best. The best goal you can set for yourself is to (always) be better. There’s a subtle, but profound difference.
  • Nobody is immune to irrational behavior. And no matter how much you try, you will never eliminate it in yourself or others. The best approach to dealing with irrationality is to set checks and balances in place to detect and manage it (especially for yourself). Learn to self-monitor and along the way ask yourself questions like, “Am I unknowingly in my own optical illusion right now?”
  • People discount the future. That is, we are wired to be short-term thinkers. This is why promises of the long-term benefits of a design generally never serve as convincing arguments.

I have many more heuristics that I haven’t listed. And it’s worth pointing out that my intention for listing the above is certainly not to make you feel cheated; after all, I haven’t provided relevant experiences and arguments for over half of these. Rather, my intention is to make a critical point: while the above heuristics have served me well, they are not hard and fast rules, and I often need to break them.

In the past few years I’ve become particularly passionate about spreading what I’ve learned. In my own little way, I’ve written about certain perspectives on my blog, and presented some of these concepts at conferences. During this time, I’ve been approached by a number of people, including a few publishers, urging me to write articles, even books about the topic. But most of these conversations quickly converge on one question: what are the best practices that can resolve these problems once and for all?

My answer has consistently been, “There aren’t any.” Admittedly, it’s an answer that disappoints. And it may disappoint you as well. It certainly disappointed me the first time I found myself uttering those words in a Q&A after one of my talks. But this disappointment — particularly in light of what we’ve learned about ourselves in this chapter — is as ironic as it is paradoxical.

We don’t have static best practices that always work in creating a perfect design or writing perfect code. Instead, we take all of our knowledge, skills and experiences, and apply them creatively on our projects. Each situation is different from the next. The reality is that our field — really, our world — is grossly imperfect and nothing, not the combined intellect of all its experts or the power of a thousand firebreathing dragons, will ever change that. We are constantly updating our best practices, from those dealing with structuring markup to designing for a seemingly infinite number of devices — often finding ourselves exactly where we started. As frustrating as this is at times, we’ve all come to appreciate it as one of the things that make our work interesting.

In fact, it may even be the source of our happiness. As Mihaly Csikszentmihalyi suggests in his book, Flow: The Psychology of Optimal Experience, setting goals that are just out of reach and working towards them is the true secret to happiness. Or as Gandhi put it, “Glory lies in the attempt to reach one’s goal and not in reaching it.”

All that remains between you and glory is a goal.

Next Steps
I believe our need to find a silver bullet for people problems stems from the very cognition that paints forgiving self-images and constructs elaborate theories about the world. But if we’ve learned anything in this chapter, it’s that our theories and ideologies are often built on shaky foundations, informed by very little real information, and choreographed by biology beyond our conscious control. The sooner we can accept that people are like our technologies and systems — irreversibly imperfect — the sooner we can start dealing with people problems the way we deal with all our problems in life: by acquiring knowledge, practicing, analyzing and repeating.

Here are some next steps to help you on your journey:

  1. Acquire knowledge: I maintain a list of books and articles that have helped (and continue to help) me. This is a good place to start: http://rainypixels.com/ thereadinglist.
  2. Practice: Aggressively look for opportunities to apply your acquired knowledge in situations at work and at play. Push yourself to step outside of your comfort zone.
  3. Analyze: Make a note of what worked and what didn’t and thoughtfully analyze why. Look at the situation from all angles, including your own behaviors and motivations.
  4. Repeat: Make this a habit and an integral part of your life.

1 All names have been changed to protect the guilty.
2 Bruce Schneier, “Risk and the Brain”, 2008
3 Underestimating the time estimated needed to ship a product is a cliché as old as the software industry itself. Among the many factors, one that weighs heavily is known as optimism bias. Tali Sharot’s TED 2012 talk is a great starting point to learn about it.
4 Ori Brafman, Rom Brafman, Sway: The Irresistible Pull of Irrational Behavior, 2 Jun 2009, pp. 121-125.
5 The Impostor Syndrome is a psychological phenomenon in which people, despite external evidence of their competence, remain convinced that they’re frauds and don’t deserve the success they have achieved. 6 Daniel Kahneman, “Anchors”, Thinking, Fast and Slow, 2 Apr 2013, pp. 119-129.
7 Dan Ariely, “The Fallacy of Supply and Demand”, Predictably Irrational, Revised and Expanded Edition: The Hidden Forces That Shape Our Decisions, 2 Apr 2013, p. 27.
8 David Eagleman, “Mind: The Gap”, Incognito: The Secret Lives of the Brain, 15 May 2012, pp. 55-75.
9 The tendency to fall in love with our own work is quintessentially human. It’s beyond the scope of this to deconstruct all the factors that go into this behavior, but a significant contributor is something known as the Ikea Effect.
10 Kathryn Schulz, “Our Minds, Part Two: Belief”, Being Wrong: Adventures in the Margin of Error, 4 Jan 2011, pp. 87-111.
11 David Eagleman, Incognito, 15 May 2012, p. 58.
12 Betty Edwards, “The Constancies: Seeing and Believing”, Color: A Course in Mastering the Art of Mixing Colors, 23 Sep 2004, p. 8.
13 Dan Ariely, “Testing the Simple Model of Rational Crime (SMORC)”, The Honest Truth About Dishonesty: How We Lie to Everyone—Especially Ourselves, 18 June 2013, p. 17.
14 Dan Ariely at EG ‘08 Podcast, FORA.tv.
15 Edward Adelson, Checkershadow Illusion.