A while back I wrote about Death By A Thousand Bugs, the slow degradation of user experience that comes from keeping all those little bugs around that are just too small to feel like they’re worth fixing.  There’s another kind of death, death by mediocrity, that I want to save you from today.

Have you ever stopped to think about the difference between a really great product that you love, and its competitors that you don’t love as much?  Odds are, it’s the small details. When a product team has taken the time to think about all the little things, not only does the product feel more polished, it’s easier to use, and it’s a more comfortable environment.  It’s like a house, where your hosts have thought to clean the grime out of the corners in the bathroom.  It’s just NICE.  The details matter.

What are details?  

Everything.

From the corner radius on your rounded boxes, to the color of your dropshadows, to the way things respond when you click them, to the thoughtful predictions of user intent, there is no end to detail. I can’t list every detail of an application because they are truly, infinite.  Apple is a master of the details, though even they don’t think of every single one. Google, I’m sorry to say (as a very loyal user of their products) is not good at details in its UI.

Learn how to break things down.  There’s the normal view:  “Oh, it’s a page with a body, an aside, some ads and a call to action button”.  Then there’s the next level of attention:  “The body is 2/3 of the page and the aside is 1/3 on the left.  They are separated from each other by a colored border.  The ads all have borders and a label.”  Then there’s the next level: “Everything but the content responds when I mouse over it.  As I scroll new things appear.  All the borders are 1px.  Everything actionable has a drop shadow.”  And then you get really into the nitty gritty “The shadows are dark green instead of black.  There is a darker shadow on the most important thing.  Things that are meant to guide my attention are tilted at a 15 degree angle” etc.

This is, of course, a vastly simplified example.  But it’s important to see the progression – it’s like zooming in with a microscope on every single little element of every screen.  I like to start at the top and work left to right, top to bottom, but you can find your own method.  Think about the very atoms of what you’re looking at – and while you’re at it do your users a favor and ask if it really needs to be there.

Whose job is it to keep track of all the little details?

I can’t think a single person in a product team who shouldn’t be thinking of details.  There’s probably a funnel, with the product manager and designers thinking of the most details, but every person, from project manager to developer to QA engineer should be paying attention to these things and talking about them with the rest of the team.  If  designer misses the idea of putting helpful mouseover text on the icons, the janitor should be able to point it out and suggest it.  If the engineer notices that it would be neat if the eyes on the icon critter closed when the product wasn’t in use, they should be able to suggest it or even just build it.  How much you empower the people outside the “planning and design”  functionalities of the project is up to you.

I’d like to say that the product manager and designer should think of every detail, because detail is their job.  However, no one, two or ten human beings can think of an infinite number of things and I’ve already pointed out that details are infinite.  Even Apple misses things.  So the product manager should do their best and they should deputize every other member of the company to do the same.

You’ll find that certain people are really good at finding certain kinds of detail.  I’m really great at noticing visual design and interaction details, but I’m not always awesome at data details or QA details.  Because I like to set up tight all-way communications in my teams, I usually get the feedback that I missed a certain browser or resolution when I was QAing, and I actually keep a checklist.  Know where you’re strong, and offer that up to the team.  Know where you’re weak and find a workaround, whether that means trusting someone else to be strong there or making checklists or creating mnemonics or whatever works for you.

The user experience of your product is only as good as the least detail-oriented person working on it. Don’t be that person.

How can I train myself to think of details when I’m busy crafting the big picture?

That’s the easiest part.  There are some great blogs out there – one of my favorites is Little Big Details – and you can subscribe to them.  They only take a second to read each day, but they’ll change how you view the world.  While that’s happening, you can start asking yourself why all the time.  Why am I doing it this way?  Why do I like that?  Why did they do that?  Why should we do this?  You’ll start finding that the critical thinking will really improve your appreciation of everything you do, but it’ll also improve your understanding.  As a side effect, it’ll also increase your frustration with the world “Why did Safeway require me to choose payment method on the self-checkout screen and then again on the card reader screen?”.

Every time you see something you like, think about whether there’s an equivalent for your product.  Maybe the texture on the dashboard of my Prius (one of the many details that makes me love the car) inspires me to use a texture in the background screens of my app, just to make it feel more tangible or evoke a subconscious association.  Nothing in the world should NOT inspire you.

This doesn’t mean you have to stop thinking of things holistically.  It just means you need to become a more flexible human being.

When should we start fine-tuning details?

This is a prickly question, because details can mean scope bloat and creep if you’re not careful. It can lead to analysis paralysis if you don’t practice pragmatism and prioritize well.

Start thinking about your details from the very first moment you conceive of a project.  Carry over details from previous projects that you’ve already thought of and implemented. Bring in the dreams of idealism.  Polish starts from the very first second, as you build a smooth surface to buff later.

As you move through the production process, details get more and more expensive to design and implement.  Too much, too late, and you have experience rot before the product even goes live.  So try to make fine-tuning a part of your DNA.

If you’re willing, empower your developers to just Make It.  I’ve worked with some great developers who knew that thing could pulse when you mouse over it, and I happened not to think of it.  They just did it, and showed me, and I jumped up and down with delight.  Just remember to encourage communication loops; surprises are a bad thing.

If you have a deadline, or if you are on an agile schedule, treat the details like a constant improvement.  Do as many as you can before you push, and then queue up a list of new things.  Always be adding to the list, always be improving.  I’m an Agile fan, so this comes easy to us.  Waterfall shops will have a little more trouble with that, since it’s often “get it perfect before you hand it off and then don’t even think of changing it”.  However, even in a waterfall world, you can build relationships with the people downstream and upstream, and make judgement calls.  What doesn’t increase scope too much goes in, what does goes on a list for the next rev.

Get started today

Go.  Go now, my child!  Look at your website, your app, your product. Break it down to every atom of form and function. Find a friend who’s anal-retentive and ask them to do the same thing. Find someone who’s good at describing things and ask them to describe to you how it looks, how it feels, how it behaves. And then make EVERYTHING better.

You can do it, I believe in you.

Today’s Interesting Link:

random.org – Random is hard.  Like really, mathematically hard.  Let these guys do it for you.  They have so many fun toys, that you’ll find excuses for being random all the time. And that can’t be a bad thing.

 Today’s Usability Quote:

 “If it is something important, get a colleague to improve it.” – David Ogilvy on writing, but fits design

Today’s Music To Design To:

Cirque Du Soleil has so many good options.  However, Dralion has everything I love – haunting vocals, varied tempos, and a wonderful mixture of exotic and familiar.  You can’t go wrong with Cirque, and maybe it’ll even inspire you to get out of the office and go see them.  

I work a lot in web application design. I also live in the bay area of California, so I’m surrounded by creative, colorful people and subcultures. So, every time I see a Submit button on a form, I twitch a little bit.

Let’s talk about language here. Language is the primary communication method we humans use. Secondary to language are visual cues, like “body language” in-person, color in visual medium, and audial cues like sound effects. Language is really freakin’ important when we want to get a point across, sell something, or build relationships.

Pay attention, lead generation and conversion designers and product managers. This is MOST crucial to you.

What is a user interface but a relationship between your company and all of its customers? Because of this, every single word in your interface is critical. Every single word builds your brand. So why, then, are so many great companies using the word “Submit” in their form buttons?  It’s domineering, vague, and cold. I can only think of a couple of companies that would want to vaguely, coldly dominate their customers and I’m betting yours isn’t one.

As best I can tell, Submit as a button label comes from the very earliest days of the web. When we started being able to write programs that captured user-entered information, and submit them to a server for processing and storage, we labeled the button literally.  It submits information from a source to a destination.  Back then, mostly only techies were doing this stuff, and maybe no one had thought it through from a user perspective. I don’t remember. Sadly, this established a precedent.

Then the WYSIWYG web editors came about, and they codified this behavior by having the default wording when you create a button be “Submit”. A bad habit was born and websites have been whacking their users over the head with it ever since.

Why do you make a form?  Because the user has information and you want the user to give that information to you. Bonus points to you if the user is highly motivated to give you that information – that makes your job easier. But after overcoming all their objections in order to get them to type stuff into fields on a page, you have a golden opportunity to build your brand, reinforce the message that got them to fill out the form, or reassure them about what will happen to their data.

Instead of saying “Submit to us, you dastardly supplicant!”, why don’t you say something descriptive and friendly like this:

• Get your free account
• Download your package
• Buy now/Add to Cart/ Get One
• Send to our secure servers
• Preview your awesome thing
  or even just
• Finish (if you absolutely can’t find something to convey the value they’re about to get when they click)

If you are using Submit buttons in your interface, you’re insulting your users, either by dominating them or by not caring enough about them to think through the little details. So spend the extra thirty seconds to think of a good button label – it’ll pay off in conversions, user loyalty and goodwill.

Today’s Interesting Link:

typeconnection.com – This is  one of my favorite websites to send people to when they say they’re interested in typography.  It gives you a font, and lets you choose fonts that pair well with it, then “send them on a date” to see if they’re compatible. At the end it explains why you were or weren’t right, and in the process of playing a game you learn more about typography than you would sitting through a class.

 Today’s Usability Quote:

 “If I’d asked my customers what they wanted, they’d have said a faster horse.”  – Henry Ford

Today’s Music To Design To:

Halou has an album called We Only Love You, and I love it. It’s got energetic, creative beats and soundscapes, with airy vocals and sweet lyrics. It’s just ambient enough to serve as background music, or you can crank it up and let it drive you to design with circles and whitespace, crisp details and elegant simplicity.

I often speak on the proper technique for giving and receiving critique, and the value of doing so.  As a writer and as a designer, I have occasion to be on both sides of that equation daily.  I am not exaggerating when I say that it’s a critical skill for any professional.

Why then, is it the case that so often when I see people ask for feedback, it seems like the majority of responses are snarky, unconstructive and poorly formed? It wastes the time of the person requesting feedback by not actually providing them any actionable data, and it wastes the time of the person giving the feedback, because they’re not winning brownie points, looking knowledgeable, or participating in a discussion which can  help them grow.

Let’s take this out of the realm of generalities and draw some specific examples.

There’s a great website called usabilityhub.com.  They have such a wonderful concept.  They provide tools, some free and some low-cost, for you to do quick-and-dirty user testing.  One of my favorites is the Five Second Test.  I use this test regularly with my real users, but when in a pinch it’s wonderful to be able to put a design up on their website, have people look at it, and provide their impressions after viewing for five seconds.  Or it would be, if the audience weren’t comprised completely of other designers, who are just participating in these reviews so that they can get credits toward running their own tests.  90% of the feedback I get on the tests I run is snarky, unspecific and has nothing to do with the design.

As a second example, John Nack of Adobe recently wrote a post asking for feedback on an experimental interface.  I was one of the first to comment, and I gave what I hope is a constructive and useful critique.  I was really interested to see what other viewpoints might be out there, so I subscribed to the comments on that post.  And I was shocked.  Despite a friendly readership, the majority of the comments on the post are caustic, sarcastic, and non-specific.

Perhaps these posters are busy posturing, like puffed up walruses, and they’re not thinking about the fact that this is a valuable chance to interact with and learn from their peers.  They’re participating in some imagined primordial dominance contest  Or, perhaps they have forgotten the value of critique, both to the giver and the receiver, which they were almost certainly taught in design school.

Let’s all remember: A properly formatted critique benefits the person whose work is being evaluated by pointing out things that are not necessarily obvious to the designer/artist, and by providing a different perspective and potentially new ideas.  It benefits the person critiquing the work because it may point out tendencies or habits they have themselves, it may open a new and inspiring dialogue with a worthy colleague, and it may bring to light whole new design philosophies or techniques.  And don’t discount the value of networking – open dialogue with people who do what you do not only lets you learn to do your job better, it opens up doors to new jobs in the future. I love to recommend people who have shown me how good they are, and how easy they are to work with.  Everyone wins when there’s a good critique, and nobody loses.

For posterity, a good critique goes like this:

1. The critiquer carefully examines the work.
2. Critiquer starts on a positive note, by praising something.
3. Next, (optional) is an overall impression of the work.
4. Critiquer asks questions about the reasoning behind anything he/she doesn’t like.
5. Followed by at least 3 actionable things to improve.  Note, I’m not saying “point out three problems”. I’m saying “point out three things to improve”. It’s a positive, constructive thing.
6. Followed by at least 3 things that are great and shouldn’t be changed.
7. Critiquer finishes with an optional recap of the overall impression.
8. The artist listens silently, only answering questions, until the critique is done.
9. The artist thanks the critiquer, and can discuss improvements as long as they’re not attempting to defend their work.  I use the rule that you can’t say no.  Even if you’re thinking no, you never say it or imply it because the point is to receive and internalize, not to debate.

As a design community, and I mean this inclusive of pretty much the whole planet, let’s spread the word of the constructive critique.  Speak up, constructively, to the people you see wasting everyone’s time.  Remind yourself to give and receive regularly. And let’s all try to leave our egos at the door.

Today’s Interesting Link:

http://thisisindexed.com is a delightful blog in which artist Jessica Hagy publishes simple, insightful and funny drawings on 3×5 cards every day.  These drawings are almost exclusively graphs and venn diagrams, which often combine unexpected things to make a wry and useful point.  It’s the perfect example of “a picture is worth a thousand words” and I subscribe to it as design inspiration.

Today’s Usability Quote:

“The brainstorming muscle can get rusty just like anything else.  You get lost in operational realities.” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:

The Art of Noise.  Anything the Art of Noise does, really.  It’s ambient enough to be distracting, while energetic enough to keep your mind focused. Also, the variety of instruments, samples and sounds they use really lends itself to creating things from other things – I don’t know why.  I love derivative work, and Art of Noise is my go-to music for derivative work.

Clearly, it is holiday time as I write this.

Not too long ago, jiatelin5 asked in a comment what books and lessons I recommend for brand new UI designers.  Since I get this question a lot, I thought I’d make it a post.

Becoming a UI designer is a lifelong process.  I’ve been doing it for 16 years and I’m still learning.  You need to have some soft skills, which I’ve described in a previous post.  In addition to these, you need to be very good at communicating, and you also need to have some technical and artistic skills.

The very minimum

1. Learn HTML & CSS.  If you don’t understand how web pages work and how they are built, you can’t possibly hope to design them.  My very favorite resource for this is Code Academy, but there are also good books out there – don’t be afraid to buy the latest edition of HTML for Dummies.
2. Learn Photoshop.  There are plenty of design applications out there, but if you only ever learn one, learn this one.  The reason: once you can use Photoshop, you can use any of them.  The bonus reason:  employers will search for this skill in your resume, and if they don’t see that you know Photoshop, they might not even consider you regardless of what you do know.  All the photoshop books and tutorials have their benefits, but feel free to check out Photoshop for Dummies – pick the edition that matches whatever version of Photoshop you can get your hands on.
   There is a great forum on the adobe website set up just for Photoshop newbie questions – check it out.
3. Learn basic typography.  There are a lot of great articles for this, and some of my favorites are from Design Festival, Smashing Magazine, PSD Tuts and 24 Ways,   There are a lot of great books out there for typography too – start with The Elements of Typographic Style and move on to whatever holds your interest from there.
   The 24 Ways link above is particularly important because you need to understand vertical rhythm in order to design sites that make users comfortable.
4. Learn basic color theory.  Unless you intend to be designing in black and white forever, you’ll need to understand when and why to use color.  Check out these articles: Color Theory For Web Designers,  Basic Color Theory.  Ignore anything you see about what colors mean because they will differ for each culture and demographic.  Red means one thing to the chinese, another entirely to americans.  It means one thing to older americans and another to teenaged americans.  So just forget all that temporarily.  Read The Principals of Beautiful Web Design.
5. Learn about layout.  This is something you’re probably going to get instinctively, or never really get at all – but there are a lot of articles and books about it so even if you get it instinctively you need to read them to be able to explain yourself and make wise choices.  Start by researching Responsive Web Design and follow it wherever you want.  As long as you start understanding layouts from the responsive web design standpoint, you’ll be fine. Interactive Media Center has a pretty good approach to layout, although the site is a little dated.
6. Get a feeling for producing UX deliverables.  At the very minimum, every UI designer needs to know how to make good wireframes, low-fidelity mockups and high-fidelity mockups.  Depending on where you go to work, you might also have to write styleguides or work from them, write specs or PRDs, or build prototypes.  Don’t just follow my links – google all these terms and read everything you can.  You’ll develop your own style and that’s just fine.  It’s awesome, actually.
7. Learn about usability evaluation methods.  Even if you work in an organization where someone else does the research, you need to understand methodologies, when to use which one, and how to understand whether you’re making good designs.  It’s good to do customer requirement gathering before you start your design, and then evaluate your design afterwards – even if you’re just using budget, quick or halfhearted methods.  You can’t design in a vacuum unless you’re designing something only you will use.  Read Don’t Make Me Think and Website Usability: A Designer’s Guide and then keep reading other books that those books recommend.
8. Learn the best practices for web design. Again there are hundreds of good resources, but my favorites are Smashing Magazine,  Jakob Nielsen (even though he’s controversial),  Bruce Tognazinni,  and Designmodo.  Subscribe to blogs and read them every single day.  Best practices evolve, so you need to keep up with the latest research.
9. Understand the difference between designing web sites, web applications, mobile applications, desktop applications and experiences.  This could be a whole blog post of its own, so my recommendation to you is to google all of the above and come to deeply grok the differences.

Please keep in mind that this is just your basic “get an internship” level of learning.  You need to register for conferences, and get out there working and learn more.  If you can find an undergraduate program at a college, go for it.  Otherwise, look into cognitive psychology, computer science, and design courses.  If you have your baccalaureate already, see if your local college has an HCI or CHI or UCD program.

Good luck to you.  It’s a tough profession, but the world needs more of us.

Today’s Interesting Link:

weenudge.com – I heart this page so much.  It’s MOST useful for the freelance or agency designer, but everything in here is helpful for in-house designers too.  It’s essentially a collection of things you need to explain to your clients, and ideas for how to explain them in friendly, clear ways.   It hasn’t been updated since May 2011 (sad face) but it’s still super awesome.

Today’s Usability Quote:

“Ideas are not so compelling that they just jump off a page.  You have to sell your story.” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:

I’m so embarrassed to say this: All of the Twilight movie Soundtracks.  Ok, stop laughing and listen – the movies are awful but the soundtracks are fantastic.  You get everyone from Florence  + the Machine to Bat for Lashes to The Bravery.  The tempo is just right and the songs are just innocuous enough to let you throw your own meanings onto them.  The best one is Eclipse, which I think was the third movie.