The Mythical User

Taking the mystery out of User-Centered Design

Inside the Workflow: Sketching on Whiteboards

If you’re curious what it’s like to deep-dive into a design challenge, or if you’re looking for a tip to help you focus and brainstorm on your own, there’s a new post on the new home of The Mythical User, called 

Inside the Workflow: Sketching on Whiteboards

Leave a comment »

5 Ways to Make It Safe to Fail

Hey!  There’s a new post over in the new home of The Mythical User.

Read the 5 Ways You Can Make It Safe to Fail.

Leave a comment »

Moving Blog

Great news!  I’ve finally gotten around to moving this blog to my domain!  I’ll put a note here with a link to the next 10 or so posts I write.  In the meantime, feel free to update your bookmarks (sorry for the inconvenience! I won’t do this again.) or head over to The Mythical User to re-subscribe.

If you’re curious, this blog’s new home URL is http://www.swankster.com/wp/mythicaluser/

 

Leave a comment »

Book Review: Blink by Malcolm Gladwell

When I am teaching art to kids, they frequently ask me “Is this right?” or “Is it done?” or “How do I know if it’s good?”. My answer to them is always the same – you’re the artist, you tell me. Only the artist can know when art is done, and only the artist’s heart knows when it’s right. The kids usually react one of two ways – they’re either relieved to have complete freedom, or they’re horrified at the lack of judgement.  I can tell a lot about the kids and about their parents, by those reactions.

User experience isn’t quite the same. It isn’t art.  It’s right when it’s easy, it’s never done, and it’s good if the users are delighted at the end, and if the business wins too. I like to say that UX is 50% science and 50% art, but it’s probably more 75/25.  We user experience designers rarely experience artistic freedom because we are not serving ourselves.

At the same time, it is the UX person’s job to become as expert in the field as possible, so that they can make split-second decisions. Companies, especially those who haven’t had a UX person before, are very critical of a UX person who isn’t right with these split-second decisions.

This is where Malcom Gladwell’s Blink comes in.  Blink talks about the difference between conscious deliberation – the gathering of data, weighing and analyzing, and then choosing a course of action – and instinctive judgement.  Gladwell explains that instinctive judgement can be much, much more powerful in the right circumstances and coming from the right person.

As UX designers, when we’re called on to quickly decide whether a form field should be a dropdown or radio buttons (both valid choices for most circumstances) our subconscious processes a million pieces of experience stored in our supercomputer noggins, and spits out an answer.  Gladwell says this is a great use of instinct – it’s that primal reflex built into us since the dawn of time.  We look like we’re pulling it out of thin air, but in reality we have processed this and our split judgement has an answer at the ready.  This is “thinking without thinking” in Gladwell’s world.

However, the business world has taught us not to trust ourselves.  We second-guess, we think everything needs deep analysis, and we don’t know how to explain our instincts.  So we back up and question our experience, and this leads us to either 1) go with a HiPPO’s snap judgement, which they trust more than we trust ourselves or 2) wind up in analysis paralysis, working on a project for 3 months that should take 2 weeks.

I’ve been there. Gladwell describes a ton of other people who have been there too.  Careers are won or lost on the ability to trust snap judgements. Industries are built around the snap judgements of experts.

In Blink, we are shown through anecdotes and real-world examples just how amazing the instincts of experts can be. There’s a strong distinction there:  Gladwell is clear that you must be an expert in your field before your instincts are to be trusted. No one would ever ask me to make an intuitive diagnosis of a car problem, and I would never ask a sign language interpreter to choose the best interface for building engagement.

Gladwell also goes into the need for deeper analysis and examination of data.  He says that instinctive judgement should not be the only thing relied on.  It should be a data point. His contention is that, unlike what we have all been trained to believe, instinct is as strong a data point as data is.

I recommend this book for anyone who has ever questioned their instincts, and that’s all of us.  It’s good at reinforcing the lost confidence in our mind’s subconscious processing power.  And it will reinforce to you that it’s ok to put that problem down, walk away, and do something else while you let the wetware in your head work out the solution for you.

Blink was published in 2005 and is available on Amazon in just about every format.


Today’s Interesting Link:

CSS3 Animation Cheat Sheet – I love this, it’s so clear and beautiful and it’s fun at the same time.  It’s the perfect example of what a cheat sheet should be.  It shows you examples of all of the CSS3 animations and if you like it, you can just add their stylesheet to your work and boom! You can call them by name.  Saves time if you want it to, or gives you inspiration.  You choose.  :D

 Today’s Usability Quote:

The key to good decision making its not knowledge. It is understanding. We are swimming in the former. We are desperately lacking in the latter. – Malcolm Gladwell

Today’s Music To Design To:

Vicious Delicious by the Infected Mushrooms.  I’m pretty sure this is good for just about everything, because the Infected Mushrooms are energetic, electronic, melodic and evocative. it makes you want to dance, so don’t blame me if you find yourself swaying and bopping in your chair.

 

Leave a comment »

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

Leave a comment »

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

Leave a comment »

Clear ownership makes for a happy team

Hybiscus flowerIn a lot of my posts, I talk about deputizing everyone to give input to the user experience, product and design process.  However, it’s important not to lose sight of clearly defined roles and ownership, or you’ll end up with a very mediocre product.

“Websites designed by committee end up beige and tweed” – A COO I used to work with

On a product team, you usually have executives, product managers, maybe project managers, content producers, designers and engineers.  Note that these people might be on different teams organizationally, but they need to understand that they are on the same team pragmatically.

Each and every person should be able to give input to every single aspect, from strategy, to tactics, to the pixels on the page and which screens show.  However, just because everyone’s voice should be heard, doesn’t mean that the project manager should dictate what color a button should be, or an engineer should be the final decision maker in the pivot of a company’s strategic direction.

That said, this blog is about design, and how to be a good designer even when you’re not a designer.  Here is the most important thing I will ever tell you about doing design:

Give your designers problems to solve, and don’t tell them what interface they have to use to solve the problem.

First of all, if you are not the designer, you are not the expert in design and interaction.  You might have knowledge, you might even be really good.  But the designer is the person paid, probably very large amounts, by your company to do that job and to think through all the options.  You should let them do their job.  If you don’t feel like they are good at design, you should talk to your supervisor or theirs about replacing them.  Don’t undermine them or overrule them.

Second, you are all on the same team, working for the same goal.  If you and the designer have a difference in opinions about what specific interface or interaction will meet that goal, the designer should win by default.  They are the one who will be held responsible for the interface they’re designing.  They need to be the tie breaker, even when the designer is part of the tie.  Would you want to be held responsible for decisions someone else makes against your will?

Third, designers are highly in demand right now.  Every designer I know hears from at LEAST one new recruiter a week.  If you’re constantly overruling your designers, they’re going to wonder what you need them for, and they’re going to go join a company where they get to actually do their job.  Maybe this is a good thing – maybe they aren’t the right designer for your company.  But ask yourself: if you hire a different designer, are you still going to overrule them when they disagree with you?  If so, the problem isn’t the designer.

Designers have a role in this too.

Execs’ job is to steer the company in the right strategic direction.  They get the big bucks, and have the big risks, to make it worth the sweat and tears they put into this.  Designers should bea  voice at the table, when strategies are being discussed, but once a strategy has been chosen – by the exec, not by the designer – it’s the designer’s job to jump into it with both feet and tow the company as hard as they can toward those goals.

Product managers’ job is to decide the tactics that get you to the big picture the execs have drawn.  They also need to determine the requirements for those tactics, and make sure the whole team is clear on what needs to be done.  Designers should give input, suggest features, and argue against the ones that are just cognitive clutter – but in the end the designer needs to trust the product manager to do the right thing for the company, and make the best design to fit the features specified.

Project managers’ job is to keep things moving on a timetable.  Designers have a responsibility to communicate how long things are going to take them, taking into account possible delays, iterations, and things that’ll go wrong.  And then, when the project manager sets a timetable and commits the company to it, it’s the designer’s job to pull as many all-nighters as are necessary to get things done by their due dates.

Content producers deliver the content the designer relies on to design their screens.  The designer can give direction as to length and sometimes structure, but in the end they need to trust the content strategy and adjust their designs to fit the content, or make the designs AROUND the content provided.

Engineers make the world happen.  They need to be involved in the design process, and designers need to trust that the engineer will build what they’ve designed. When the engineer says something can’t be done, the designer must listen to the alternatives, and be flexible enough to change their design to fit reality.

The bottom line

  1. Trust your designers to know what they’re doing.
  2. If you can see it or click on it, the designer has the final word, not you.
  3. Designers: open your ears and listen, and trust others to do their jobs if you want them to trust you.

Today’s Interesting Link:

From Up North – If you’re like me, inspiration comes from everywhere.  From Up North is a fantastic blog that gathers up inspiration from all over the art world – fine art, illustration, design, word art, tattos – you name it!  It’s daily and easily consumed and I love it.

 Today’s Usability Quote:

 “[Having too many choices] takes [customers] out of the purchasing process and puts them into a decision-making process.”  – Stew Leonard Jr.

Today’s Music To Design To:

Arash’s self-titled album is Iranian pop, so I don’t understand the words.  This makes it great for design work!  It’s energetic, exotic, uplifting and a little bit sexy.  I REALLY hope the lyrics don’t talk about drowning kittens and stealing candy from babies, because I like it so much.

Leave a comment »

Don’t be the weak link

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.  :)

Leave a comment »

Dominate the Market, Not Your Users

PHoto of an orchidI 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.

Leave a comment »

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.

1 Comment »

Follow

Get every new post delivered to your Inbox.

Join 644 other followers