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.

“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.”
-Me

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.

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.

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 cheezburger.com

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.

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 (OKCupid.com 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.

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.

People 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:

http://quirktools.com/screenfly/ – 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.

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.”

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.