Design Process

Choking People Made Me A Better Designer

Some days I run out of work at 5 PM to go choke people. Not to be rude. I let them choke me, too. I am a student of Brazilian Jiu-Jitsu, a martial art that promotes the idea that a smaller, weaker person can beat a larger, stronger person through skill and technique. And yes, sometimes chokes. I love the art. I love the science. There is so much to understand and it keeps me fascinated. I often see the similarities between my 9 to 5 and my version of happy hour. My job as a designer at Amazon is challenging. What I do for fun is equally challenging. Work hard, play hard. There are so many lessons in fighting that are relevant to my life and to my job. But three in particular stand out for me.

Lesson number one: calm down. When I first started training, I would physically exert myself to the point I would burn out in a matter of minutes. Like pushing against a brick wall, all my effort was getting me nowhere. You’ll never learn to control other people if you can’t control yourself. Early on, my instructors told me many times to slow down. What they were actually telling me to do was to think more about the problem at hand. Take time and analyze the opportunities as they arise. So in time, with the right direction, I began to understand how to slow down and apply pressure only where there can be forward movement. Attack the weak spots and defend with minimal effort.

As a UX designer, I am sometimes pulled into conversations where someone has already framed the problem and is telling me how to solve it with their solution. I know an impulsive response when I see it. This is where I take a step back and consider all angles before deciding how to solve the problem, because I have learned that when you get in a hurry and allow someone to press you, you make mistakes.

When you’re tired and a 225-pound athlete is crushing down on you, trying to pull your arm out of socket, it’s easy to lose your wits and give in to the pressure. But I find that if you steady your mind, you’ll be better equipped to defend yourself. You focus on survival first, slowly working your technique to get back to a position of neutrality. Then you attack.

Lesson number two: seek efficiency. So often we hear this message. The idea seems easy enough to grasp, but often slips through our fingers. When fighting, efficiency is a matter of applying the appropriate leverage at the appropriate time. Anything else becomes a waste of your energy, the most precious commodity you have in a fight. Worse, inefficient movement exposes you to counter attack.

When designing an experience, our principal goal is to create an efficient experience. Any online task we ask a user to complete should contain the minimum number of steps they can cognitively manage. Sometimes there is an argument about needing to add more things to a design. But more often in my experience, I find people wanting to take too much away. There are essential steps you can’t combine or remove. Try cutting out a few essential steps in a Jiu-Jitsu technique, and you’re going to lose. Too few steps is just as inefficient as too many.

Lesson number three: learn to fight by fighting. When I was much younger and training in Karate, I thought I was learning to fight by punching the air. There were all these theories about how to defeat your opponent in a given situation. Yet, no one was regularly testing these techniques, and no one seriously questioned them.

Brazilian Jiu-Jitsu techniques can only be fully understood when you learn to use them on someone who is fully resisting. You find some things work for you and others that don’t. It is a test-based mentality. When something fails, you ask, “What did I do wrong? Are there details I am missing?” The challenge is that you are reacting to a living thing rather than just the air, and not everyone reacts the same way. So you adjust your technique and try again.

Creating a user experience is no different. It’s easy to get lost in a world of theory and opinion without testing and feedback. Even the most educated guess is still a guess. But seeing how people react to a situation will keep you headed in the right direction. I am fortunate that I practice two disciplines that pursue a higher truth through testing. For me, it’s a cornerstone of both.


I train at the Gracie Barra Ballard academy just north of Seattle. Stop by for a free intro lesson!


Land of Confusion



Have you ever been told your design is confusing? Personally, I hear that from time to time. Someone reviews your work, and since they didn’t understand it for whatever reason, they think no other human could possibly understand it. It’s imprecise feedback, but they are entitled to their own opinion, and opinions aren’t wrong. Or are they? To begin, it’s more judgment than opinion. I often wonder what the process is for judging design when coming from someone who’s never designed an experience. Regardless of whom it’s coming from, design is easily misjudged. Sadly, it leads to misdirection, poorly designed experiences and, at best, wasted time. You have to know what the situation is before easing the problem. The first step is to understand what the word “confusion” means.

As a word, “confusion” seems to stand in for a lot of other issues. For me, though, I see confusion on a scale of difficulty in cognition ranging from minor hesitation to a fully broken experience. Walking into a closed door because you thought it was open would be confusion. Jiggling the handle because you don’t know if the door is locked is a lack of clarity. Fixing an unclear experience can be as easy as changing a word in a label. Fixing a confusing experience could have you scrapping your design altogether. Still, you’ll hear the word as a catch-all for any friction in the user experience. Your work could very well be confusing, but it could also be a matter of perspective.

How is the critic viewing your work? More than once, I have had someone look over my shoulder at a design and tell me what’s not working. Being told a button is too small from someone standing six feet away from my screen is undoubtedly an incorrect judgment. I once had a VP who refused to view any mobile design unless it was on a mobile device. Seems obvious, but I have been in meetings where mobile designs were being judged while projected on a wall at 20X their actual size.

Now consider the difference between the process of design versus an actual experience. In the design process, we sometimes look at printouts of different screens that are tacked up on the wall. This is not the user experience. It’s a replica, an approximation of what the user will experience. Some things are lost in translation. Compare an architectural drawing to what it’s like walking though a real structure. The user experience is nothing short of what the user is doing while interacting with your actual site or application. We have certain tools to create a vision. We use static mocks, wireframes, and prototypes. Occasionally with these tools, the context and continuity are misread. That confusion is a result of the inherit inadequacies of the tools we use.

I have seen people perplexed by how to navigate a four-way stop. Does that mean a four-way stop is confusing? More likely, the confusion is the result of a distracted driver, one that isn’t in the mindset to navigate it properly. A user can be in the wrong mindset, as can the person judging the experience. But when designing, you have to assume some level of focus from the user. You cannot account for when they are off in dreamland. Designers attempt to remove as much friction from an experience as possible, but nothing is truly effortless. A user has a task. They are attempting to accomplish that task. I have been told a design was questionable because it took a couple seconds for someone to find the thing they wanted to click on. In this case, it was a tertiary action, something most would do infrequently. To ensure that action would have more immediate discoverability, it would have to compete with the primary action that most used frequently. What’s funny is, they complained about a task they were still able to complete in a reasonable amount of time.

The hardest issues to deal with are cognitive biases. This is the curve-ball judgment I fear the most. A cognitive bias can easily lead to an error in judgment based on one’s own perception. To illustrate a bias of my own, I can tell you about the video of the twirling models that plays automatically when a customer clicks a garment on Having been a Flash animator in the advertising industry, I was drawing on an experience that proved to be bad for the user. Principally, it was having unexpected movement on a page when the user first landed on it. On, I argued against having video automatically play. I thought it should be user-initiated, allowing them to acclimate to the page layout first. The counter argument was that the video was a key differentiator, and that we should lead with a “delighter” feature. But based on my heuristic, it wasn’t going to do well. Fortunately, we agreed to test it with a large internal audience. We lead with the auto play video and waited for negative feedback. No one voiced a concern. Then we released the product and waited again for negative feedback. Nothing. I was happy we tested it first, and happy I was proven wrong, because I learned a very tricky lesson about how your own experiences can mislead you. My perception of a confusing experience was proven false. Unless all factors are exactly the same, you cannot predict with a high level of certainty what will be successful. Your biases may lead you in the right direction, but can just as easily distort rational thinking. The process for good judgment should lead us away from our own biases. Getting past them requires listening to other people’s concerns, seriously questioning yourself and, above all, user testing.

The perception of a confusing experience needs to be dissected. There may be a legitimate concern. Take it seriously, but question it. Often, it’s less of an issue than what someone believes. As a designer, you control how a design is viewed and how it is communicated. If you take the time to appropriately frame the experience with the right amount of context, there are a lot of problems you can avoid. For the issues that communication can’t handle, do user testing. Get a broader perspective, and base your decisions on broad and deep information. Be aware that the one person you prove wrong may be yourself.

It’s 2010, so why are we designing sites like it’s 1999

Having a process is a nice thing. It helps you to understand what you typically need to do and when it needs done. Someone once explained to me that a process is like a woman’s dress. It should be long enough to cover the subject, but short enough to be interesting. I agree, not too much and not to little. What I find all too often is that interactive, when ran by outsiders (you know who you are), always looks to sell a design first while ignoring the majority of the work they should have done to get to that design. I guess who needs a process when you just can just wing it. As long as no one looks at the reporting, we can all do whatever we want, right?

I say it’s designing like it’s 1999, but now that I think about it, we had a process at in 1999 thanks to Patrick Garrett. Maybe, it’s just the path of intellectually lazy people who don’t care if their work actually solves a business problem. They complain that the clients want to see pictures, but then that’s what they give them whether or not they asked for it. It’s like complaining your kids are fat as you pack chocolate milk and candy bars in their lunch.

I’ve read it a million times, start with a problem you want to solve. Then define strategies that solve the problem. Next, tactics that support the strategy. Simple. Online we deal with site, content, and technology strategies. These are expressed through information architecture, interaction design, usability design, information design, navigation design, and brand standards. Once you understand all that, THEN you design an interface. And yes, I understand that in the case of a competitive RFP response, you need to show creative, but you should develop the thinking behind it too. I promise if you can justify every pixel of your design and someone else can’t, you will have something that will be more successful as both a pitch for new business and as a Web site.

If you were designing a print piece, you wouldn’t begin to think it was okay to show creative before developing the concept. Interactive content is like the concept in the advertising industry. A site’s content and features are “the big idea.” No concept, no creative. Assuming you can have an interface without the content or idea is seriously narrow minded and insulting to anyone who has ever produced a good Web site that people have adopted. If you somehow got a job at Yahoo! or Google and said hey, we’re gonna design this site but we don’t know what the content is or the scope or who the audience is, you’d be fired, on the spot, that day.

The shame of it is we just did this for AB it got us nowhere. The entire conversation focused on information architecture and content strategy. Then we got grilled over having no user center design research. At least we had our pretty pictures to take home and hang up on the fridge.