(Not) About the Importance of Design

This article is NOT about the importance of design.  Those who know me best know that I'm a bit of a contrarian... I tend to play devil's advocate in arguments just to see what will happen, I do the opposite of what I'm told just to see if I can, and in college I once wrote a reactionary "Anti-Feminist Manifesto" because I was so tired of being told by my women's studies classes about what a victim I was of The System and The Patriarchy.

I have to stop and clarify a bit here.  This article will NOT BE an Anti-Design Manifesto.  For one thing, I've grown up a bit since college, and along the way realized that victimhood aside, I am a feminist.  For another, just because I'm tired of hearing about the importance of design doesn't mean it's not important.  I just don't think it's important to CONTINUE TALKING about the importance of design ;)

My reasoning here is threefold.

First of all, it's all been said.  Read the first chapter of just about ANY design book, and you'll get inundated with the reasons why design is important.  Most of them come down to a basic fact: if you don't set out to design your [noun], you'll end up with a badly designed [noun].  I cannot count how many times I've heard this phrase.  Many times it's stated far more eloquently than I just said it, but the basic argument is the same.

My second reason is that talking about the importance of design is preaching to the choir.  I've already picked up your book, attended your lecture, turned on your video, whatever.  If I'm here, and your content is not SOLELY ABOUT the importance of design, chances are that I've already bought into the message.  I don't need to hear it again, because I already know it by heart.

Lastly, talking about the importance of design is pointless because if you don't get it by now, you're probably not going to.  I assert that with all of the "democratization of design", all of the numerous sources who will tell you it's important, all of the cultural shift that has transitioned towards intentional design, unless you've been living under a rock, you've heard some (or most) of it by now.  And if you've heard it, and you still don't buy it, I can talk about the importance of intuitive information structures and seamless interaction models until I'm blue in the face; I still don't think you're going to buy what I'm selling.  And that has to be OK.  It's a waste of my time to convince someone who doesn't believe in of the importance of deliberate, intentional design.  I'd much rather spend my time working with someone who at LEAST buys into the story A LITTLE, and then show them just how far that story will take them.

You may, by now, be wondering "If it's all been said, and you're soooo tired of it, why do you keep reading/watching/listening to these sections?  Why don't you just skip them?"  Frankly, it's partially because I'm a sucker.  I enjoy the eloquent phrasing, the reiteration of an important point.  But also it's because these first chapters often set the tone for the rest of the material.  These sections define what the AUTHOR thinks are the important concepts in the "importance of design" message.  For example, you might be able to guess from reading this article that things like "information structures" and "interaction models" are important to me, because I called them out in my examples.  That gives you some important context about where I'm coming from.  And personally, I'm all about context.

I've seen some great diagrams explaining the different facets and personas within the design process.  What I think would be cool is if we designers could use some of these diagrams, and color in the parts we feel apply to us, and to our content.  So without further ado, I will show MY PERSONAL design emphasis pictogram here.  I hope both that it comes in handy for you other context-o-philes, and that this is the start of a broader industry trend.

My emphasis order is:
1. Information Architect
2. Interaction Designer
3. Visual Designer
4. Copy Writer

.

A big thank-you to Robby Ingebretsen and the videos at .toolbox, from whom I stole the original UX Venn Diagram.

"The sea is so great and my boat is so small..."

...how is my feature supposed to get found in all this mess???

Discoverability is one of the harder issues any designer faces.

Part of it is the advertising aspect: pick me, pick me!!  The problem with this is that it's not ALWAYS the right time for your feature to be visible, and if everybody puts a happy flashing glow around their feature, then nothing stands out.  But if you don't stand out at all, how will people see you?  Furthermore, you don't want to be the flashing glowing icon on the screen when people DON'T need you.  Then you're the annoying kid in class with his hand up… "why can't he just keep quiet??"  The key is figuring out what makes you special to the user, be that when they need you, and then get out of the way.  Just like in the Tao of Steve, "Be there, be brilliant, be gone."

Some of it comes back to the launch point discussion.  What is in the users' mind when they need your feature?  What is on their screen?  What information do they have at hand, and what information do they still need to get?  Or what do they need to do?

Once you know these things, picking the right name is what it's all about.

Naming is hard, but completely worth the investment in time:  The right name will make people stop and take notice.  The wrong name will at best make your feature ignorable, and at worst make you a subject of mockery, ridicule, and shame.

Apple is great with names; my personal favorite is TimeMachine, their automated backup solution.  It brings to mind the idea of freeing yourself from linear time, and the ability to instantaneously move to whatever point in time is important to you, to experience that time firsthand.  And isn't that exactly what the user wants when they want a backup solution?  "This stupid computer isn't working right.  It was working right yesterday!!" Ok then, let's just go back to yesterday!

On a tour of the Redhook Brewery in Seattle, I learned that one of its founders supposedly thinks a great way to name something is to take two completely unrelated words, one of them containing the letter K, and put them together.  According to him, the result will be something that sticks in peoples' minds.  I can't speak to the effectiveness of his strategy, but I admit I used it to come up with my blog name... :)

But regardless of how you come up with a name, be it the lightening bolt of inspiration, some strange algorithm involving the letter K, "bible dipping," or any other method, make sure your name speaks to your target audience.  And the only way to do that is to test.  Test TEST TEST!!  I didn't really test my blog name other than to ask a few trusted friends what they thought of it, but that's just a blog.

For a shipping product, you want to know that your name resonates with your audience, that it has the right connotations and brings up the right feelings.  Make sure you can say the name aloud: show a few people the name on paper, and ask how they would pronounce it.  You want to make sure the name is pronounceable, and that people don't come up with some completely alternate way to say it that you don't like.  If it has an acronym, try out the acronym aloud.

On the subject of acronyms, I have to say this: for all our sakes, if the acronym is as interesting or more interesting than the name itself, please, STOP.  Think again.  You probably have a bad name.  The technology world simply does not need one more acronym.  Acronyms make great nicknames for internal discussions, but they're terrible for customers.  And if the acronym is so much easier to say than the name itself, maybe you should give some more thought to a name that rolls off the tongue.

Where do I begin?

Begin at the beginning… and go on till you come to the end: then stop.” Lewis Carroll, Alice in Wonderland

In my industry, people don't WANT to use your feature, they want to do their jobs.  They didn't wake up this morning and think, "wow, today I want to spend all day using that new feature I found yesterday!!" That may be how things end up, but it certainly was never the goal ;)

So how does your feature help them do their job?

• What is on their mind when they need your feature?
• What information do they have in front of them?
• What are they doing?  (Or at least, what are they trying to do??)

That's your launch point.

"But what if my feature starts from nothing??"

It's certainly easier to create features that add tasks and actions to existing information and objects than it is to create features which start from nothing.  But even if the feature starts from nothing, the user still has a mental model of how things are, and how they should go.  What is in that model?

1. What things are part of their mental model?
2. What does the user think is the right place to start?
3. What are they already familiar with?
4. Is there anything that exists already?

Hint: the answer to question 4 is always "YES!"  Even if they don't have a computer, they probably have a spot they could put it in.  Think about the set of things that already exist for the user.  What are the environments and tools already at their disposal?  Where do they spend their time?  What do they like to do for fun, and how do they like to do their work?
If you want people to use it, your new feature should feel as familiar as possible; this applies especially the launch point. If (for some immutable reason) your experience has to be fundamentally different from what they already know, you can use your launch experience to ease them into your new world.

I like to think of designing features in terms of getting a new job.  You want your customer to "hire" your feature, to add it to the set of tools they use.  Before your customer will hire you, they will interview you to make sure you will do the job well.  They want to know that you're smart, that you're a hard worker, that you're not a crazy psycho who will steal all the paperclips.

A lot of people ask "why do I need to spend so much time designing an experience that the user will only ever see once, maybe twice in their whole lives?"   To these people I say, "would you show up for a job interview without making sure your clothes are straight and your teeth are brushed?

Your launch experience is your interview with your customer.  Metaphorically speaking, if you need to take the extra 2 hours in your schedule to make sure your clothes are dry-cleaned and pressed beforehand, that time will be well invested, even if they never see that outfit again.  It helped create the first impression that got you the job.

A little bit of background...

In my work life, I'm a UX PM for Microsoft SQL Server Management Studio.  To the real world--those of you NOT working in the design industry or at Microsoft--that means I design user interfaces for Microsoft's premiere database tool.

A lot of people give me funny looks when I tell them where I work.  And I get it... SQL Server (and Microsoft in general, I know,) is not exactly known for its fantastic UI.  In fact they've both got a history of some pretty crummy UI.  SSMS (the tool my team develops) is difficult to use, idiosyncratic, and has no real design standard other than using another team's crappy UI to justify your own.  And those are the more polite things I have to say.

I once went to a lecture from a man who was giving career advice based on his life and work experiences at SQL Server... he was the sort of person who commands a lot of respect around here.  Anyway, I doubt he thought there were any UI folks in the audience when he made the offhand comment that if you want to progress your career in deep technical thinking, SQL Server was the place to be, but that "if you want to progress a UI Design career, well, maybe you should work someplace else."

I disagree.  I think this is a great place to grow my UX career, because I have a unique opportunity to shine: I know that whatever I do, I'm going to make users happier than if I'd never been here at all.  And after several years, I know I'll be able to point to the legacy I've left behind, and have something to be proud of.  I'm part of the design revolution. 

I could go work for a team known for fantastic UI, and I know I'd learn a lot about how other people do it.  Maybe I'd learn to avoid many mistakes I've had to learn the hard way.  But at the end of the day, I couldn't point to the interface and say, "if it hadn't been for me, that wouldn't have been there."  Call me conceited, but that gets me up in the morning.  And the accountability keeps me honest, and working hard.

I started my current job early in 2008, when my boss decided to take a chance on an unknown person based only on my obvious passion for the subject.  At the time, I was working as a tester for another team.  I knew nothing about SQL Server.  I'd never designed anything a real user would see.  I had one (pathetic) design course under my belt.  And I was full of opinions.

I'm still full of opinions.  And I aim to make sure my boss never regrets his decision...