Design your back door

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

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

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

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

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

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

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

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

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

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

Today’s Interesting Link:

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

 Today’s Usability Quote:

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

Today’s Music To Design To:

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

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.

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?  


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