Interface Inconsistency is Killing You

Kaylee the Frug puppy

My puppy Kaylee is worried about your interface.

Consider this an intervention.

There are a lot of reasons your interface can become inconsistent.  That ONE page needs to have a 24pt headline because it just doesn’t look right in 22pt. Designer 2 doesn’t like the loading spinner that Designer 1 made for their section of the site, so Designer 2 makes a new one. Designer 3 doesn’t know you already have a progress bar design, so they make a new one. There’s a new and awesome technology that’ll save you a ton of time so you implement it on new features and it’s got some UI baked in. You’ve redesigned and all the new pages are going to use the new look. Etcetera, etcetera, etcetera. (Yes, I wrote that in Yull Brynner’s voice.)

But just stop it.

You see, interface inconsistency is bad for ALL THE REASONS.  It’s tech debt. It’s cognitive load. It makes your site look unprofessional. It’s hard to QA. It’s embarrassing, for Pete’s sake.

So, how do you correct it?  And once you’ve gotten your site clean of this poison how do you prevent a relapse?

One step at a time

Think of inconsistency as an addiction. Addiction to form over function, or quick over quality – it doesn’t matter. You need to approach it the same.  First, admit you have a problem. Tell everyone who will listen (internally – let’s not air our dirty laundry!) and get them to help you take stock of the problem.  How many button colors do you have. How many font sizes?  How many types of popups?  How many ways do you say “buy”?  How many shades of grey are you using?  (I kid you not, I once worked for a company that was using 23. We narrowed it down to 6)

After you’ve made your list, you’ve got to start cutting back. Who should be the head pruner depends on the organization, but I tend to feel it’s the owner of the overall design – so, a director of UX or a lead designer or whatever your company has that serves as a Design Poobah. They’re going to add another silly Silicon Valley title to their skillset – Consistency Czar. If they’re smart, they’ll involve other designers and maybe even a product manager or two in the process, so that they’re not shoving decisions down peoples’ throats later.

Pruning usually goes one of two ways: You can either choose the few versions of each thing that make the most sense for your brand, or you can choose the version that’s used most often. If one version is more usable than another, choose that one. Be ruthless. You don’t need 23 greys. You probably only need 3.

Once you’ve decided what’s canonical and what’s apocryphal, you need to communicate it like crazy. Remember how you told everyone you were an inconsistency addict?  Now you need to tell them you’re in recovery. You need to push the consistency agenda like it’s an election year and wealthy donors are standing by. If you have multiple designers, make sure the whole design team knows what you’re moving forward with and what you’re sunsetting. While you’re at it, make sure the engineering team is in on the fun too. You’re about to ask them to retrofit some code.

Once the communication is done, you need to start acting. This is where your partnership and good relationship with your developers comes in handy, so I really hope you’ve built one.  This is truly where the withdrawals hit in my addiction metaphor, because it’s the painful phase.

How you structure cleaning house into your roadmap will be unique to your organization, but the devs will ultimately be deleriously happy to be able to get rid of extra stuff.  If you have a hard time selling them on the idea, tell them three things:

1. Consistent sites have reusable widgets that can be maintained and shared.
2. Consistent sites load faster and that helps everything from SEO to performance scores to bounce rate.
3. Consistent sites are way easier to upgrade later.

Put your ego away

Once you’ve started the process of pruning out the apocryphal versions of your widgets, text, icons, colors and other code noodles, you automatically enter the next phase: relapse prevention.

When you’re designing a new feature, refer to your styleguide, pattern library, UI library – whatever you use to document your design decisions. When in doubt, just go click around your own site and talk to people who are designing stuff too.  Before you add a progress bar, check to see if you’ve got progress bars anywhere already.  If you do, USE THAT ONE.

If you don’t like that one, DO NOT design a new one unless you first get agreement from everyone including developers to change the original too.  You heard me right.  Use stuff you hate unless you’re willing to make changes to all instances of a thing. It’s better for everyone involved, because your developers are not going to trust you if you make them go through a big consistency project every two years. Not to mention the executives, who will wonder why they have to keep spending money to fix something they already fixed.

When you do design a new feature, make sure you share it.  “Hey everyone! We didn’t have a slider widget so I designed one. Here it is for you to use!” is not only a great way to ensure consistency, it also saves other people future work and plays a PR role in letting people know what you’re doing. Never underestimate the value of good internal PR.

Everyone is a sponsor

From the moment you realize your site should be more consistent, every single employee of the company should be deputized as a consistency sponsor. While ultimately, it’s the designer’s call whether to introduce new styles and elements, every product manager, developer, executive, and admin should speak up if they think they’ve seen an inconsistency. The designer will either justify it as necessary, or fail to justify it and need to change it.  Either way, users win and engineers don’t waste time building bad things.

Today’s Interesting Link:

How much to make – This is all about the broad strokes, of course, but it’s fantastic as a way to get you thinking about whether or not you should be building a mobile app, vs making a properly responsive site.

 Today’s Usability Quote:

“Know the rules well, so you can break them effectively.” – His Holiness the Dalai Lama

Today’s Music To Design To:

I’ve lately found that Erasure’s Wonderland, from 1986, is amazing for driving you through heavy workloads and crushing deadlines. It’s high-energy electro synthpop, in case you’ve been living under a rock and don’t know this seminal album.


5 Ways To Make It Safe to Fail

“The biggest risk is not taking any risk… In a world that is changing really quickly, the only strategy that is guaranteed to fail is not taking risks.”
-Mark Zuckerberg

“If you want your team to succeed, create an environment in which they are encouraged to fail.”

Today I want to talk about something really, really important.  I want to talk about screwing up.

I do it.  You do it. Everyone you know does it.  We all make mistakes, forget things, try things that don’t work, or otherwise fling poo at our batting average. It’s important that we admit that, and accept it, and plan for it. That “plan for it” part is the hardest one, and it’s the one I want to focus on.  Because you should be focusing on it too.

People in a creative role are not flawless.  Whether that’s a design role, product management, or development, they miss little details from time to time.  They work long hours and forget to close a tag.  Or they try something that research or instinct tells them will work, and it doesn’t.  It’s only through these mistakes that they learn and get better.  And it’s only through taking risks that they can discover the insights it takes to win big.

So, if people aren’t flawless, and you want them to do great work, then you need to make it ok for them to mess up.  Here’s how to create an environment that fosters calculated risk-taking:

1 – Turn off the bozo switch

We’ve all been in companies where there is a “bozo switch” with a hair trigger.  If you do one thing less than perfectly, they’re going to think you’re an idiot for the rest of your life. Screw up once, in a small way or a big one, and you’ll never be given the chance to succeed again. How did you feel there?  Were you energized, enthusiastic and ready to take the risks needed for big successes?  No, you were downtrodden, over-cautious and looking for the first opportunity to leave the company.  And I guarantee the company suffered for it, because they didn’t get your best work.

I’m not saying that someone who is wrong every time they make a statement should continue to get the benefit of the doubt.  But allow people to be wrong, let’s say, up to 33% of the time without assuming they’re incompetent.  No one has a hundred percent success rate at anything – even Bobby Fischer lost games sometimes.  If someone is wrong so often that you find yourself having a hard time believing in them at all, then maybe they haven’t got the tools they need to succeed. Ask them.  If they’re wrong less than a third of the time, they have a good track record and you should give them the benefit of the doubt.

2 – Determine causality, not blame

When something breaks, it’s important to know who broke it. That way, they can feel good about themselves by fixing it. Also, you can identify issues with process or opportunities to improve skillsets. However, it’s not important to assign fault, shame the person who made the mistake, or levy consequences.  Again, if every time a person touches your code it crashes the website, maybe you want to see if they have all the tools and knowledge they need to do their job.  But if a person writes code for you for a year and then one day breaks the build then you should figure out why and help them, not ridicule them.

3 – Take blame

The best way to create an environment where it’s safe to mess up occasionally is to show that you aren’t perfect. When you make a mistake, own up to it in front of the team. Take responsibility, and be an exemplar. Don’t lose confidence in yourself, either. It takes a strong person to admit they’ve messed up, and a stronger person to follow through on the fix.  Your team will admire your courage and honesty and they’ll know that they are safe to do the same.

4 – Laugh it off

I’m not saying that you should create a “Most failed experiments” trophy or anything. But the best way to create a close, trusting environment is to bring a little humor in.  It’s ok to laugh when something flops. It’s ok to gently tease each other, to have friendly competitions and chuckle while you’re cleaning up the mess.  Laughter is, after all, the best medicine.

5 – Budget some wiggle room

When you’re planning, plan a fudge factor in. I tell my team to use the Scotty Principle – multiply the time you think it’ll take by 3 and that’s the estimate you give. In every sprint, add some points for fudging.  Have multiple people check your work.  Have a backup plan.  A/B test.  If you assume that some experiments will fail, then you’ll be ready with alternatives. Be like the Buddha, and accept failure before it even happens.  Heck, count on it and figure out what you’ll do WHEN it happens.

If you apply these principles to your product organization, and maybe even to your life, you’ll find that it’s less scary to take risks.  After all, as long as the risk is a calculated one, and you have a disaster mitigation plan, there’s a ton of upside and the downside is manageable. Life is really just a series of iterations, day after day. Some of the iterations are improvements, and some aren’t.  But the universe didn’t give up on you when you didn’t get the relationship with your high school sweetheart just right.  It gave you endless second chances, and you’re clearly still getting second chances since dead people don’t read my blog.  (Or maybe they do.  If you’re dead and you’re reading this right now totally give me a call so I can write a book about you!) Create an environment full of second chances, and your product and your users will ultimately thank you for it.

Today’s Interesting Link:

Random User – Such Tool! Much Helpful! Many Fun! And other Dogespeak! This is an elegant little API that generates random user info for use in your designs.  The applications are only limited by your imagination.

 Today’s Usability Quote:

 This is an age of experiments. – Benjamin Franklin

Today’s Music To Design To:

Another oldie but goodie is Deep Forest’s Boheme.  It makes me think of browns and oranges, and makes me want to use rich textures. It’s smooth but just energetic enough to make it hard not to sway around.  Apply at very high volume for best effect.

How to Win an Argument About Design

This is my new desk fish, Pixel.I get asked – a LOT – how to persuade people to accept a particular design.  It makes sense.  Design, especially visual design, is a very subjective… subject.

I don’t win them all.  There are designs out there, even at my current position, that I’m embarrassed about. In the end, you can’t win them all, because if you do, you’re a dictator and you’re not doing it right.

However, in most cases, the designer should win any argument or discussion about design.  Why?  Because this is their area of expertise, that they have trained in and are paid to provide.  I’ve said it before and I’ll say it again: If the designer is consistently being overruled, they are not the right designer for the company.  Or maybe the people having the design discussion just don’t know how to do it right.

There’s one way to always win a design argument:  The designer can say “I’m the designer and I say so.  The end.”  However, I wouldn’t want to work with that person, and I don’t think you would either.  Pedantic is not teamwork.  Nobody wins, not even the user, because the designer might be missing out on better ideas than they could have come up with.

So here’s how to win an argument about design, in six not-easy steps:

  1. Genuinely listen to the other perspective.
    Maybe this isn’t an argument you should win.  Maybe the other side has merit you haven’t considered.  Maybe the other solution is equally beneficial to the user experience and the business case and when you examine it, maybe you win because you are won over.  There’s no shame in that, really.
  2. Apply statistics and standards to the other perspective.
    Really look at it analytically.  What do other sites do?  What’s the accepted standard?  What do studies say?  If statistics or known user behavior don’t support the other method, but do support your point of view, present them.  Depending on your company and team and how much they trust you, you might need to cite sources or show examples.  Be prepared to do this – don’t make stuff up.
  3. Apply your past experience to the other perspective.
    What have you done in the past?  Has their way failed or succeeded in the past and what factors were different?  Share this respectfully, and show examples.  Show numbers if you can.  Explain why you tried it and echo the person’s motivation so they know that you, too, thought that way.
  4. Explain your process in arriving to the conclusion that you arrived at.
    Often the other person is suggesting something because their process is different than yours, so they don’t know a piece of information you know.  If you can’t explain your process, then you probably shouldn’t be defending your position.  This leads to one of my key UX principals:

    If a position is hard to defend, you probably haven’t thought it through very well and it might not be the right position.  Stop and do your homework before you argue.

  5. Weigh the design position against the business needs.
    The number one source of design arguments is a conflict between business needs and friendly user experience.  Sometimes the business really needs to get something out of the user, or the business won’t be there to serve the user tomorrow.  Startups especially run into this conflict.  Weigh it carefully.  If the business needs are winning over good design principles more than 20% of the time, you’re making short-term decisions and will pay a long-term cost when it comes to keeping customers and word of mouth.  Maybe you’re looking for a quick exit, and that’s the right thing to do.  Or maybe you’re looking to build long-term relationships and parlay them into further business, so it’s not the right thing to do.  Your position will vary, but know what it is and act accordingly.
  6. If it’s just a matter of personal preference, be willing to admit it.
    There is NOTHING wrong with saying “I want it to be green because I like green.”  Nothing.  However, I’m going to say that it’s CRUCIAL for you to admit that it’s only preference, and if this is your only support for the position, you absolutely MUST realize it’s the weakest of all possible arguments.  Be willing to back off and swallow your preference for the greater good, if there’s even one data point against it.

There you have it.  That’s how I win the majority of my disagreements on design.

Of course there’s a few critical attitude components too.  You have to respect the other person’s opinion and thoughts and method.  You have to remain unemotional and cooperative.  You have to keep your mind open.  And in the case of an impasse – I sometimes run into these with people who outrank me organizationally – be willing to explore in tandem to find a third option.  After all, whenever it looks like there are only two options, it’s because you are being pedantic and closed minded.  There are always more than two solutions.


Today’s Interesting Link:

Practical Typography – I love type so much.  It’s pretty and it carries words to our eyes and through our eyes into our brains. Type is an art form.  This site is a great primer if you’re curious to learn about type, and it gives you just as much as you want to know.  That’s great UX.

 Today’s Usability Quote:

I am convinced the solution is always in the problem. You could do a design that you like, but it doesn’t solve the problem. Design must solve a problem.
– Massimo Vignelli

Today’s Music To Design To:

I can’t tell you how much I’m digging Blackmill.  It’s melodic dubstep – just what you need for crisp, outside-your-rut (come on, we all have them) designs and Gettin’ S— Done.  Check out Miracle, you can thank me later.

Don’t make your users repeat themselves

There are basic principles and pillars that make an app usable. The very most basic is “Follow standard practices whenever possible.” Directly following that, I think, is:

Don’t ever make your users enter the same piece of information twice.

Image from

We live in the digital age of computers. One of the primary functions of computers is REMEMBERING things. If a user has ever entered something, you should remember it and carry it with them, across pages, across functions, even across applications if need be. If you want to be successful, you should be customer focused. If you are customer focused, the value proposition of saving information for a user and prepopulating forms or shortening workflows for them is fairly evident.

We have all had the experience of having to fill paper forms out in triplicate for government organizations. We’ve also had the experience from the meme above and been impatient.  Why would you put that on your users, when a few lines of code can avoid it?

I once worked for a fortune 500 company where 12 different applications (And a team of 5 people working in tandem) were required to order a single product. The tools were all built by different teams in the company, with different backends and different data output. They didn’t share data between themselves, so at each step, the user would be required to export data and then (in the best case) import it to the next tool.  Sometimes the user had to enter the data manually, and they would literally print it out and set it next to their monitor so they could type it in exactly the same.  I am not kidding you.

Probably, you’re not doing anything quite that bad.  If you are, hang your head in shame, and then fix it.

But you might be asking them for their name in one place, and then for first name and last name somewhere else.  Parse that bad boy out.  Maybe your phone system uses the phone number to look up the customer to see what tier of support they qualify for.  Then make sure your CRM is tied into the phone system so that when the customer is routed to the appropriate representative, that rep has the customer’s info and doesn’t have to ask for it again.

Google’s autocomplete is a prime example of this principle in action.  When you’re typing a search into the form, Google will autocomplete first with things you’ve searched for before, then with the most likely guess.  This is also one reason that Facebook sign ins are so popular – you use Facebook to sign up for a site and your info is there without you having to enter it in the new site. It’s like magic!

In the end, remembering things is probably one of the easiest tasks you can ask your software to do.  As users become more comfortable with computer interfaces, they will begin to expect this basic courtesy, as surely as we expect someone to respond “hello” when we greet them.

Today’s Interesting Link:

SVGeneration – This site is so much fun your head might explode. It’s got a ton of wonderful, tiled backgrounds that you can customize and then generate as SVG files. Go ahead, try not to get addicted. You’re welcome.

 Today’s Usability Quote:

It takes considerable knowledge just to realize the extent of your own ignorance.  – Thomas Sowell

Today’s Music To Design To:

Silent Shout, by the Knife. With a mysterious, slightly dark groove, this is synthesizer-based music that manages to be futuristic and uplifting and tickles your creative bones in all the right places.  The vocals even have that sort of airy but ominous feeling that lives somewhere between german synth pop and Lords of Acid.  Seriously, it’s worth a listen.

Design your back door

I keep company with architects and the children of architects, and I love buildings. I often think of my UI design process much the way architects think of the building design process.  You design your pages around the content.  You design a building around the primary space.  You ensure there are enough bathrooms for the number of people likely to be there at any given time.  You build in the features your users are likely to want just before, and just after your golden path task.  You make it accessible to anyone, regardless of physical ability type.

And I notice, that in much architecture, just as in much design, the back door becomes an afterthought.

Have you ever been amazed at how beautiful a building is, and wandered around it in awe, only to find yourself in a plain white hallway that leads to a mass-produced back door with chips in its paint and dirt pushed up against the doorjam?  Did you question it, and did it make you sad, or did you just accept it because it’s not the face of the building?

I got to tour the Pixar campus a while back.  It’s gorgeous.  And you know what?  Their architect even thought about their back doors.  Sure, they’re functional and not as beautiful as the rest of the building.  But the one I passed out through was Pixar-crisp.  A detail that the designers of the interior spaces looked at, thought about, and assigned.  It fit.

Why am I going on about architecture?  Because I want you to think about your back doors.  I want you to think about the alt tags and titles on your images and links.  I want you to think through the way your emails look with images off.  I want you to think about how your website looks with ads turned off ( does the neatest thing – they have a placeholder behind their ads that suggests you donate to have an ad-free experience).  I want you to DESIGN the voice browser experience.  I want you to think through your error pages and 404s and make them build your brand and help your customers in some meaningful way.  And I especially want you to think about your unsubscribe process.

I have a checklist for QAing and specing and even designing.  When I think I’m done, I go down the list and there’s always one thing I missed.  It includes things like

  • What does it look like in mobile?
  • How does it interact for touch?
  • What’s the SEO impact?
  • Does this affect other areas of the site/app?  Should it?
  • Are there emails associated and what do they look like?
  • What needs to be tracked?
  • What are the alt tags?
  • How does it share socially?
  • What’s it like to print it?
  • What does it look like when logged in? Out?
  • How do they get help?
  • What’s the back-out plan for the user if they’re not happy?

There should be no aspect of your app that’s accidental, or arbitrary, or forgotten.  Sure, you can have a perfectly successful website  without thinking about these things.  I’d say 90% of the successful websites out there do.  I once worked at a company that had a net promoter score of 93 (that’s astronomical, in case you don’t know) and they sucked at so many of these things – but the users were perfectly happy.

However, there is no downside to thinking about these things.  No one ever said “I liked that building until I saw that it had a beautiful back door and now I hate it.”  But maybe, just maybe – one person was on the fence about the building until seeing that beautiful back door gave them just the perfect subconscious feeling of elegance, refinement and conscious design.

Remembering your alt tags is a small investment for gaining one more delighted customer.

Today’s Interesting Link:

Trask Industries – This is the best movie promotional site I’ve ever seen. Even leaving aside my bias to immersive multi-channel entertainment experiences, and just pretending this is only some company’s brochureware site, it’s freakin’ awesome.  CSS animations build as you scroll, the page reacts and feels alive.  This is good design.  And it has Peter Dinklage.  You can’t get much more win than that.

 Today’s Usability Quote:

“Not having confidence will lead to bad decisions”  – Dave Mott

Today’s Music To Design To:

Coco Part 2 by Parov Stelar is, like much of what I recommend, at once exotic, energetic, and ambient enough to not distract you.  I love how it makes me sway while I work, and I think you will too.

Death by a thousand bugs

I have never met a company that wasn’t in a hurry.

Whether you’re a startup rushing to push product so your board of directors doesn’t get antsy, or a huge multinational corporation fending off the startups who move ten times faster than you – every company is in a hurry to get product out the door.

In that hurry, certain tradeoffs get made.  Bugs are allowed out there into the wild. They have to be, because if we are waiting for perfect, nothing will ever ship.  Only best-selling authors like George R. R. Martin can wait until their art is absolutely polished and perfect before it goes out into the world, and I’m willing to bet even he sees bugs in his stuff.

I’m a fan of bugs, anyways.  They’re often cute and they come in shiny colors like beetle green and butterfly blue.

But what happens after you let that buggy product go live? When do you go fix those bugs? And what’s the threshold at which there are too many bugs?

Everyone knows that if there’s a huge bug that stops people from being able to use the most basic feature of a product, that’s a showstopper and it’s not going to go live.  Engineers fix those as if their hair was on fire, and sometimes it is. But what about the hex value that is just a few letters off?  Or the corners that are square instead of rounded?  Those, we can let slip through, because they’re not, in isolation, going to significantly harm the user’s experience.

Where you have to be careful is in two places.

A thouand papercuts will kill you.

Although none of those little bugs in isolation are the cause that your users aren’t engaging, or your learning curve is high, or your bounce rate is high – a ton of them add up.  Three tiny bugs in this project, three tiny bugs in that project, three in this other one…. now you’ve got nine tiny bugs in your UI.  Remember that your users don’t see your app in terms of projects.  They see it in its entirety, and those little inconsistencies start to add up.  And let’s face it, you are WAY less likely to go fix that hex color bug than you are to build the next new project.  So every one of those little guys is going to join together on a million bug march against your users eventually.

  • Establish a maximum number of little bugs, per project and for the whole app.  Be faithful to this max
  • Have a commitment that every engineer fixes three tiny bugs in every sprint or dev cycle
  • Foster a culture of pride in workmanship in every employee, from the janitor to the CEO – so that everyone is eager to fix even the small imperfections.

It’s more fun to look forward.

If you work at a software company, you have probably either lamented the inability to go back and iterate on that project you just did, or you’ve gotten sick and tired of staring at the same screens of the same code for months and months and you never want to look at it again. Most likely, both at different times.  It’s crucial that you put out your minimum product, and then do sweeps through it again.  You MUST revisit the product, if not to update features, at least to fix bugs.

  • Have a plan for when medium-sized bugs will be fixed before the product even launches.  Be faithful to the plan.
  • Either dedicate one engineer to cleanup, or have every engineer fix one medium to large bug in every sprint or dev cycle.
  • Consider having a sprint just for cleanup and bug fixing, and let your devs and designers choose the bugs to work on.  This feeds into a culture of ownership and pride.

It’s important to understand that quality is a usability measure. It’s obvious why the big bugs hurt usability – they stop the user from doing what they need and want.  However, the little bugs add up and cause your users to feel like you’re not as professional as your competitors, or like you might not be trustworthy.  Credible research has shown that how attractive, consistent and brand-loyal a web site or application is significantly affects user’s opinions of the site – the exact same steps can feel totally different depending on the presentation.

Instill a pride of craftsmanship in every employee.  Empower people to take the time to fix bugs. And don’t let the little bugs pile up to take over your world.

Today’s Interesting Link:

Photoshop Secrets – This site is like my candy store.  Sometimes there’s stuff I already know, but most of the time the tips are super-awesome power tricks that I would never have known without it.

Today’s Usability Quote:

“My goal is to omit everything superfluous so that the essential is shown to the best possible advantage.”  – Dieter Rams

Today’s Music To Design To:

Ayurveda Buddha Lounge #2 – it’s largely ambient, energetic music that soothes you without distracting you. I don’t know how to describe it beyond that. It’s not particularly unusual music, it’s just really great for creative endeavors.  I also listen to this when writing, so it’s probably great when you’re doing a lot of copy-intense work.

What’s Your Ultimate Goal?

IMG_20130107_150314People who work with me hear the same questions over and over again, almost to the point of shellshock.  One of my proudest moments was when a VP sheepishly told me that in a meeting she had channeled me and asked those questions.  She felt guilty, but I thought it was the best thing ever.  It means she’s internalizing them!

What are these questions, and why am I so obsessive about them?  These are the questions that get the conversation moving in the direction I need it to, so I can understand the intent of the product or feature.  Without intent, you’ve got nothing and you’ll waste everyone’s time with design and spec cycles that are never right.

1.  What’s the goal for this project?

You have to ask this to get the conversation started.  You’ll get a complicated, detailed answer, probably.  It might involve metrics.  It will probably involve the name of an executive.  All that’s fine – it’s your starting point to dig deeper.

2.  Who is going to be using it?

Even if the goal answer told you this, you need to ask this question to get them thinking deeper about the end-users and the end-user result.  The answer is almost always slightly more complex than their initial response, so you should ask about other types of users and dig deeper to make sure you don’t miss those incidental, corner-case “other users”.

3.  So what, ultimately, do you want that user to do?

Follow this question out several steps.  So often the answer is “click the button.” but that’s not the ultimate goal.  The reason they want them to click the button is to proceed to the form, because they want the user to submit the form, because they want the user to sign up and take classes at a university.  So ultimately, what they want the user to do is to become a student, not click a button.

4.  What user problem or pain point are we addressing here?

Be cautious of a company that consistently does projects that don’t address a user issue.  They won’t be around forever.  However, understand that sometimes, the perfectly valid answer will be “This isn’t something that bothers users, it’s something we have to do to remain profitable.”  In those cases, use your past and current research to find user pain points you can address in the course of this project.  Never do a project without some tangible benefit to the user, if you can avoid it.

5.  So what’s the ultimate philosophic goal here?

No metrics allowed in this answer.  Make them talk about how the user should feel, what they should do, and how that affects the user’s relationship with the company.  Those are the key things that will influence your product design, whether you’re making the pixels, writing the code or penning the spec.

Sometimes, as you uncover intent, you discover an entirely new way of approaching the problem.  Sometimes you realize it’s not a project worth doing.  Sometimes you realize it’s way bigger than you previously thought.  But in every case, you’ll be able to approach it with a stronger understanding of the requirements and conviction that you’re doing the right thing.

Today’s Interesting Link: – There are so many ways to view your site across multiple devices out there.  This one is nice because it’s very quick, and it’s not bad to send clients to.

Today’s Usability Quote:

“For, is it not written the Holy Manual of Style :  “Lo, and the goddess of Eeuu Ayee did come forth down from the hill.   She did look upon the masses and Spake Thus to all.  ‘THOU SHALT NOT COMMIT THE CRIME OF BLINKING BUTTONS’ and lo it was so.”  – Martin
Bogomolni, referring to me.

Today’s Music To Design To:

I’m frankly surprised that I haven’t mentioned these guys yet, so if this is a duplicate recommendation. Soundtracks are so good for working, and Lagaan: Once Upon a Time In India is brilliant like that.  It’s exotic but familiar, sweeping and dramatic.  It’s hard not to be both soothed and energized when listening.  Check it out.

What Do You Do?

In social settings, this is one of the most common questions.  Especially in America, we tend to define people by what they do for a living.  With UX people, that’s actually quite apt.  Like teachers, we don’t leave our work at home.

However, the answer to the question, “What do you do for a living?” is a faceted truth for a UX person, and we should apply the principles of user experience to it.  Not everyone will understand what we mean when we say “I am a user experience designer/researcher/evangelist” and it’s unkind to make people look at you with that head-cocked-to-the-side-puzzled-dog expression.

So, to each type of person, you can give a different answer without in any way being dishonest.  After all, they don’t really NEED a treatise on the entire umbrella of UX.

  • To a layman who knows nothing about computers, you might say “I work with computers. I try to make them easy to use.”
    I also say this if I don’t know anything about the person I’m talking to, since this is the safest of the answers.
  • To an artist, you might say “I’m a graphic designer.”
  • To a psychologist, you might say “I’m a software usability researcher.”
  • To someone who doesn’t know much about computers, or isn’t interested in them, you could say “I make software/websites.”
  • To Cory Doctorow, when getting a book signed with a long line behind you, you might say “I’m a UI Designer.”
Simplifying what we do down to a single bite-sized sentence might seem self-deprecating, but it’s really just a kindness.  If someone demonstrates knowledge of or interest in the field, you can expand on it.  If they don’t, you’ve done them a favor by not listing off a ton of things that make them feel stupid by comparison.
There  is one exception.
  • To a person who might possibly hire you someday, you say “I’m a [give your exact title].  I do [brief list of the things you do].”

Why?  Because this might be the only time you ever get a chance to talk to that person, and they should have all the information they need to know whether they want to continue talking to you.  You should keep your description of what you do to two sentences, and only expand if they ask you to. My own example:

“I’m a Director of User Experience.  I do usability research, interface design, information architecture, evangelism and ux team management.”

I hope this helps you have smoother conversations, and helps you see that the principles of user experience apply to everything you do, not just software design.

Today’s Interesting Link: is a useful PNG compressor for those who have trouble using other tools.  It’s easy to use and does a darn good job.

Today’s Usability Quote:

“Our role goes beyond just making visible products; we need to make objects that are relevant, meaningful, and empowering.”  — Stuart Karten

Today’s Music To Design To:

Flamenco Arabe by Hossam Ramzy is exactly what it sounds like – Flamenco music performed by an Arab musician.  If you enjoy either style of music, you are certain to love this album.  I find it evokes warm colors and intricate designs when I listen.

User Experience goes beyond your website

From time to time, I find myself inspired to remind a company:  User Experience is the ENTIRE experience your customer has.  It’s not just the clicks and pixels on your website.  It’s how your customer feels that you, as a company, feel about them.

With this in mind, there are a few rules you should follow on your website, even though they might seem counter to your business needs:

1.  Make sure it is easy to contact you by email and phone.  Make sure this contact information is displayed on your home page at LEAST.  Better is that it should be displayed on EVERY page of your website.  Most users will look to the footer of your site, so you can either put the contact info right there (best) or have a “Contact Us” link (not bad).
I know that there’s an objection to this because if you give customers a way to contact you, you’ll have to pay someone to answer emails and phones.  Expenses go up.  However, if you do NOT give customers a way to contact you, they will choose to do business with your competitor who has a prominently displayed 1-800 number.  Trust me on this.
By not giving them a way to speak to you, you are essentially saying “We don’t care what you, the customers, want or have to say.”

2. Make it easy to unsubscribe.  In emails, have the word “unsubscribe” be a link to an instant unsub. Don’t use some funky sentence that beats around the bush but makes marketing people feel comfortable.  Use the word “Unsubscribe”, because that is what users are looking for.
On your website, have an unsubscribe link in your megamenus or your footer.  My rule of thumb is that a completely new user should be able to find the unsub link within three seconds.
The objection to this is that if you make unsubbing easy, your unsub rate will go up.  I won’t lie; it might.  But honestly, the RIGHT way to get unsubs down is to improve your offering.  Make it better, and people won’t even look for the unsub link.
By making unsubscribe hard to find, you are trapping users into a subscription they don’t want.  They will resent your company, which does harm to your brand – and they will either delete your emails without opening, or set up a filter so they never have to see them.  Worst case scenario, they’ll mark you as spam.

3. Don’t make your users pay for basic support.  If they paid for your product, it’s in your best interest to give them basic support for free.  The more they use your product, the more they will want to buy the next version, and the more they will want to  tell their friends about it.  If they have a problem, and you don’t support them, then they will give up on you and tell everyone they know that your app doesn’t work.  This is most especially true in the first week of a user’s acquisition.

3a. A knowledgebase is not enough support.  Unless you are an open source application, then you need more than a knowledgebase.  You should have some version of live chat capability, a support phone number, and a good support ticketing system.  Don’t make your users rely on FAQs and poorly edited form answers to get help.

There are plenty more rules for making sure your customers have a good all-around user experience.  What are some of your favorites?

Today’s Glossary Term: 
Multivariate Testing – Everyone knows that A/B testing is when you show some of your audience one version of a page, and the rest of the audience another version of the page.  This is great for testing drastically different designs to see which one performs better.  Multivariate testing is what you use next – once you pick a design, you start to tweak things.  You will run five, ten, maybe twenty MV tests at once, changing a tiny thing here, a tiny thing there.  It’s a very rigorous, scientific test that allows you to learn that the combination of headline A with button color B and button placement C and image D works best for your audience.

Today’s Interesting Link: is a fascinating look at A/B tests and what did better.  The author of this blog has a great understanding of the fact that every audience reacts to things in a unique way, and there’s no best practice that works for everyone.

Today’s Usability Quote:“Things should be made as simple as possible, but not any simpler.” – Albert Einstein

Today’s Music To Design To:
Have you heard the TRON: Legacy soundtrack?  The incomparable Daft Punk does classical.  And it’s brilliant.  It will totally put you in the creative mood.
Download the MP3 Album or Buy the CD

Finding a UX Job – In a Recession

We’ve all heard the lines – if not delivered directly to us, delivered to someone we know:

“We’re tightening our belt right now, and User Experience is not core to our business model”

“We’re taking the interface in a new direction, and we need fresh eyes to do that.” (and then they hire someone at half your salary)

“The product managers have learned so much from you, they’re going to take over your role.”

Whether you’ve been laid off, or you’re just looking to move on, job hunting for UX people in a recession is HARD.

Eight months ago, my employer (at the time) and I mutually decided it was time for me to move on.  I spent two months looking, and in the end I found what I love to refer to as a “pony” job – the perfect job in the perfect company, working with the perfect team.  I’ve never been happier.

Unlike the dot-com crash of 2001, when there simply WEREN’T any jobs out there, there are still plenty of UX openings for the taking.  I still get 3-4 emails a week from recruiters who have opportunities that are great matches, in my area.  The challenge comes from the fact that there are a lot of really excellent candidates out there, hunting for good opportunities.  The competition is stiff, my friends.

But it’s not hopeless.  If you’re in the job market, expect to be looking for around two months.  If you’re not picky, possibly only one month.  I applied to 93 total positions.  I interviewed at about a quarter of that.  I got several offers, but it was important to me that I find the RIGHT place, not the first place.

Whether you’re looking for the perfect job or just a paycheck, here are a few helpful hints:

Job Boards

Post your resume on every single one you come across.  Update it weekly.  I don’t care if all you are updating is your skillset or one word in your description.  Every time you update, you get bumped up in search results.


I’m not going to enter the debate about one page or multiple pages.  Do what you think is best, there.  However:

  • Have a list or grid of skills.  Not sentences, phrases.  Example:  graphic design, user interviews, heuristics
  • Forget the “goal” – that’s an outdated relic.  Instead, have an introduction that describes what you can do, and how long in total you’ve been doing it.  It’s like a two sentence cover letter.
  • Treat your resume like an Information Architecture project.  What’s the most important info?  Make that very prominent.  What’s next?  Put that nearby.  Etc.
  • Include all your contact info on your resume.  Recruiters will tell you to take it off, but the job board resumes should have it.
  • Include a link to your portfolio.   If you do ANYTHING, people are going to want to see samples of your work.


A lot of people feel recruiters are like used car salesmen.  Honestly, some are.  However, I’ve had fantastic success with particular recruiters and I swear by them.  I like them so much that I keep touch with them for years afterwards, and refer friends.  Build relationships with some good recruiters and they’ll take great care of you.

  • Reformat your resume however the recruiter asks you to, for them.  You don’t have to use that format anywhere else, but the recruiter knows his clients the best, and he knows what they are looking for.
  • Insist that your recruiter tells you every company/position they submit you to.  Bad recruiters will send your resume to positions you don’t fit, and it reflects badly on you.  Plus, if you then submit your resume directly, the hiring manager will only remember that your name is associated with something negative and you’ll hit the round file.
  • Communicate with your recruiter.  Think of them as your advocate.  Or your best friend, or your bodyguard.  Whatever it takes for you to treat them like a partner.

Social Web

Use your friends and your social networks.  Announce that you’re looking, unless you’re doing it in secret.  Talk to everyone.  Go to networking events.  Do side projects.  Offer free advice, consultations or etc.  Word of mouth is invaluable, and nothing gets you an interview faster than some impressed acquaintance saying “I know this amazing person…”

Also, momentum is a great thing.  If you know people with similar skillsets, ask them to pimp your resume out when recruiters reach out to them.  I regularly pass on resumes when recruiters touch base with me – it helps the job seeker and the recruiter.

Keep Upbeat

I know this sounds weird, but the more positive, cheerful and upbeat you are, the better your chances are.

As a job hunt drags on, you can start to wonder, “What’s wrong with me?  Why don’t I have 10 offers and a bidding war yet?  Am I unemployable?  Am I outdated?  Are my skills too weak?”

Don’t fall prey to this way of thinking.  It shows through in your body language, your written communication, and it even causes you to make bad choices about where to apply.  Keep your eye on finding a “perfect” fit.  If you haven’t been hired yet, it’s because you haven’t been exactly the right fit, not because you haven’t been good enough.


Try to find out as much about the people you are interviewing with, how long the interview will take, and what you should bring before you ever go in.

  • Take a printed copy of your resume AND the job description when you go.
  • Take the time to read the website, try the product, and get familiar with the company you’re interviewing with.
  • While you’re doing that, come up with three questions about the company or product that dig deeper in than their website, FAQ or press materials go.
  • Dress nicely, but not TOO nicely.  There’s nothing wrong with asking how you should dress for the interview.  Especially with dot com companies, wearing a suit might lose you the job.  They might decide you’re too stuffy.
  • Be prepared to answer some canned questions.  Think through the answers ahead of time so you aren’t caught off guard.  Do an internet search on interview questions and you’ll find a ton of lists.
  • Be prepared to do a test project.  This isn’t free work for the company, so don’t get irate.  They aren’t going to use what you’re doing, unless they’re really unethical.  They just want to get a sense of what it’s like to work with you.  Be pleasant, flexible and fast and your skills will speak for themselves.

Be Ubiquitous

Unless you’re looking for an entry level position, your potential employers are going to Google you.  Be found.  Blog posts, forum comments.  LinkedIn profile, facebook profile, livejournal.  Make sure you’re everywhere and that everywhere you are reflects your professional persona.  You want potential employers to know you’re not going to embarrass them, and that you’re respected and passionate about your profession.

There’s no magic wand that will fix the economy and make our 10% unemployment rate go away.  But at least for UX people, the situation isn’t as dire as it was eight years ago.  Chin up, carry on, and go find that “pony”.

Today’s Glossary Term:
A/B Testing –  this is a process by which you create two versions of something, either slightly different or very different.  You then serve up version A to some of your users, and version B to the rest of your users.  This is, of course, simplifying the concept, but you get the idea.
A/B testing can answer little questions like “does a red button or a green button encourage conversion?”  It’s invaluable, but it takes some infrastructure to set up unless you have…

Today’s Interesting Link:
Google Web Optimizer – GWO is a free (for now) tool which lets you do A/B testing without building an enormous infrastructure on your own.  It’s not going to tell you everything you might want to know, it’s not going to be as convenient as having a home-grown system, but it’s nearly immediate, and it’s darn easy to use.

Today’s Usability Quote:
“Perhaps the most difficult thing an artist has to do is evaluate the quality of his own work.” -Peggy Hadden

Today’s Music To Design To:
Boards of Canada was introduced to me by an artistic genius and all-around neat guy a few years ago.  You can’t go wrong, with Boards in your headphones.  It’s downbeat, but happy, musical but not lyrical, and energetic without being thumpy or making you anxious.  It’s good driving music, and great for those long hours coding.
Download some MP3s or
Buy a CD