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

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.

Giving Feedback Without Your Ego

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


What’s Your Ultimate Goal?

IMG_20130107_150314People who work with me hear the same questions over and over again, almost to the point of shellshock.  One of my proudest moments was when a VP sheepishly told me that in a meeting she had channeled me and asked those questions.  She felt guilty, but I thought it was the best thing ever.  It means she’s internalizing them!

What are these questions, and why am I so obsessive about them?  These are the questions that get the conversation moving in the direction I need it to, so I can understand the intent of the product or feature.  Without intent, you’ve got nothing and you’ll waste everyone’s time with design and spec cycles that are never right.

1.  What’s the goal for this project?

You have to ask this to get the conversation started.  You’ll get a complicated, detailed answer, probably.  It might involve metrics.  It will probably involve the name of an executive.  All that’s fine – it’s your starting point to dig deeper.

2.  Who is going to be using it?

Even if the goal answer told you this, you need to ask this question to get them thinking deeper about the end-users and the end-user result.  The answer is almost always slightly more complex than their initial response, so you should ask about other types of users and dig deeper to make sure you don’t miss those incidental, corner-case “other users”.

3.  So what, ultimately, do you want that user to do?

Follow this question out several steps.  So often the answer is “click the button.” but that’s not the ultimate goal.  The reason they want them to click the button is to proceed to the form, because they want the user to submit the form, because they want the user to sign up and take classes at a university.  So ultimately, what they want the user to do is to become a student, not click a button.

4.  What user problem or pain point are we addressing here?

Be cautious of a company that consistently does projects that don’t address a user issue.  They won’t be around forever.  However, understand that sometimes, the perfectly valid answer will be “This isn’t something that bothers users, it’s something we have to do to remain profitable.”  In those cases, use your past and current research to find user pain points you can address in the course of this project.  Never do a project without some tangible benefit to the user, if you can avoid it.

5.  So what’s the ultimate philosophic goal here?

No metrics allowed in this answer.  Make them talk about how the user should feel, what they should do, and how that affects the user’s relationship with the company.  Those are the key things that will influence your product design, whether you’re making the pixels, writing the code or penning the spec.

Sometimes, as you uncover intent, you discover an entirely new way of approaching the problem.  Sometimes you realize it’s not a project worth doing.  Sometimes you realize it’s way bigger than you previously thought.  But in every case, you’ll be able to approach it with a stronger understanding of the requirements and conviction that you’re doing the right thing.

Today’s Interesting Link: – There are so many ways to view your site across multiple devices out there.  This one is nice because it’s very quick, and it’s not bad to send clients to.

Today’s Usability Quote:

“For, is it not written the Holy Manual of Style :  “Lo, and the goddess of Eeuu Ayee did come forth down from the hill.   She did look upon the masses and Spake Thus to all.  ‘THOU SHALT NOT COMMIT THE CRIME OF BLINKING BUTTONS’ and lo it was so.”  – Martin
Bogomolni, referring to me.

Today’s Music To Design To:

I’m frankly surprised that I haven’t mentioned these guys yet, so if this is a duplicate recommendation. Soundtracks are so good for working, and Lagaan: Once Upon a Time In India is brilliant like that.  It’s exotic but familiar, sweeping and dramatic.  It’s hard not to be both soothed and energized when listening.  Check it out.

What you need to know, to be a UI Designer

Clearly, it is holiday time

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 FestivalSmashing 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: – 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.

Let Your Styleguide Live!

Me in my garden

In my garden on world usability day.

Recently, Nishant Kothary tweeted that styleguides “are the most useless design deliverables in existence.” Geri Coady responded with a nicely written blog post defending styleguides and their use, but pointing out the drawbacks to their usage, plus some good examples.

The thing is, there’s a BETTER way.

First, let’s take a quick gander at what a styleguide is, traditionally. This is a document, usually a PDF, ranging in length from one to hundreds of pages. It lists everything from what fonts are allowed on your website or marketing materials, to where the logo can be placed, what colors are kosher, and more. It’s the brand bible, and it’s often the product of months of work by a team of very smart people.

The styleguide’s most valuable purpose, and most undeniable impact, is to create consistency. My UX teams know that consistency, consistency, consistency is my mantra. If a website or application is consistent, then even if it’s hard to learn or understand at first it’ll build a sense of safety, confidence and speed in the user. The user will learn that they look for X to do task 1, and that task 2 is always in place Y. It’s proven that consistency builds trust in users, and that companies with consistent branding, user experience elements and interactions are perceived as more professional.

However, the styleguide usually gets emailed out to everyone, then put up on an intranet, where it instantly begins to get stale and moldy. Those people who got the email either delete it without reading it, or stick it in a folder to be forgotten about. It benefits no one other than the designer who needs to use it to cover his butt or the product manager who wants to use it to convince a reluctant designer to do something a certain way. In other words, it’s an instantly dusty, bully pulpit.

Designers complain that styleguides stifle creativity, and developers complain that styleguides are unusable documents that change too often to be tracked properly. I suspect these are the bases for Nishant’s frustrated declaration – and who can blame him?

But what if it wasn’t this way? What if the styleguide was effortlessly up-to-date, relevant and useful to everyone involved in the design and development process, and accessible directly within everyone’s workflow? What if the styleguide wasn’t a drab, outmoded tome, but rather a LIVING thing made of code and recursively following its own rules?

Living styleguides aren’t a new idea. However, when my architect came to me and said “hey Krys, you know that styleguide you’ve been working on? How about we build it in code, and instead of just being a document, the very styleguide itself is the CSS that people will use? Separate presentation from everything else and let people just write code without having to think about how it looks.” my head nearly exploded.

It took me a while to get the concept, truly. It’s possible that I didn’t completely grasp it until we built it. But build it, we did. It took us a couple of months, and goodness knows there’s a lot more we want to do – but our styleguide lives and breathes.

From a practical, design-oriented viewpoint, here’s what it is:

  • An architecture that completely separates presentation from code, segmented into typography, colors, containers, backgrounds, foregrounds, interactions and widgets.
  • A set of supporting Sass and Compass files (I’m sure you could do this with other technologies too, but we’re a Sass/Compass shop)
  • A few haml pages that use the styleguide to demonstrate the styleguide, in case anyone needs to reference it
  • A matching and corresponding UI Design Library psd file, which is the only part that is manually maintained (and when I figure out how to have a PSD auto-generate from a CSS file, I’m totally going to be rich)

When a designer is creating a new feature, it’s quick and easy to use styleguide elements because each element is named according to its purpose and intent, not its appearance. The process looks a lot like this:

  1. I need to give the user this information without distracting them from the primary task here.
  2. I guess that would go in a low-priority container, then.
  3. But since it’s in a green page, it needs the green page foreground colors
  4. and standard typography
  5. and that looks a little awkward so I’ll vertically separate it.
  6. Ah, that was easy. Now on to something that challenges my giant brain.

Then the designer hands it off to the developer, saying, “It’s a low priority container in the right column, 4 grid columns wide. Standard typography, green foreground, vertically separated”

And the developer just creates a div with these classes: low-priority-container, g-4, reading-text, green-foreground, vertically-separated

And you know what? it’s instantly pixel-perfect.

Look how easy that was for everyone involved.

If the designer is working on a feature, and the styleguide isn’t quite sufficient, all she needs to do is design something new (here, there’s some discipline needed. I go into detail in my Adopting Sass talk), add the appropriate code to the Sass files, test it in the haml, and deliver it to the developer with corresponding class names. Simple, clean – and because she designed it actually in the code of the styleguide, she saved the developer a lot of time and trouble.

I’m not saying living styleguides are easy to implement. I did a lot of hand-waving over the really brilliant, hard work that my architect did actually building all the backend stuff. There are some wonderful frameworks already out there. There was also a steep learning curve for some of the engineers, while they adjusted to a new way of working. However, I’ve since heard engineers say things like “The styleguide makes building new pages so much easier” and “It’s so much easier to communicate when you just tell me what class that is”.

Plus, a super awesome bonus: you get your UI cross-browser testing for free with a living styleguide. You cross-browser test it when you build it the first time, and every time it gets reused you’re using already-tested code. Don’t get lazy with your QA – just focus it where it’s needed most. :>

When it comes to moldy PDFs, I’m with Nishant. They’re nearly useless. But as a workflow and communication tool, and to ensure consistency and brand fidelity, a LIVING styleguide provides an amazing scaffold on which your team can grow and thrive.


Today’s Interesting Link: – Foundation, by the good folks at Zurb, is a decent place to start if you’d like to build a living styleguide.  It provides you with a basis from which you can build all kinds of amazing things.  And it’s responsive, which in this day and age, is a MUST.

Today’s Usability Quote:

“To innovate, you must first be inspired.” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:

The Tron:Legacy Soundtrack is energetic and relaxing at the same time.  It’s so well crafted that you almost feel the transitions from song to song.  It instantly inspires me to make new things, and it seems to be completely independent of style.  I love to listen to this while I’m sewing or making props too – it’s just CREATIVE music.

Get Your Interface Out of The Way

I recently had the opportunity to play second in an interface design project, with my architect Chris Eppstein as lead designer. This was a particularly eye-opening challenge for me because for about the last 10 years, I’ve always been the lead on the design projects I’ve worked on.

Chris is a CSS luminary, father of Compass, and frequent open-source contributor.  He’s a wonderful designer in his own right, having at some point in his career had to choose between focusing on being the best coder ever, or being the best designer ever.  He chose code, but his instincts, understanding of standards and love for clean, simple design didn’t just disappear.  In fact, I think it’s part of what makes him such a great architect.

At the company where Chris and I both work, we’re developing an internal (think, enterprise) tool which is of critical importance to the business and has to be done FAST. You know, one of those “This should take 6 months, but we’re going to give you two, and if you don’t do it right the whole company will fail” projects. No pressure.  Since time was of the essence, the application needed to be incredibly complex and powerful, and there would only be two users in the whole world, Chris took the lead and designed the UI.

My job was to skin the UI, and to add UX guidance and value where I could. Chris had excellent, well-thought out and well-organized sketches, from which I was able to use standards and a “novice” eye (because I wasn’t involved in the product meetings) to build detailed comps.

So I was completely flummoxed when, in the process of comping one particular screen, I continually struggled to understand what was going on, how the hierarchy worked, and how to make it flow naturally with the screen before it. In the user experience business, when you’re having this problem, it means there’s a fundamental flaw in the requirements and you need to step backwards to examine the intent of this screen.

However, upon deeper inspection, the purpose of this screen was clear, the entry to it was simple and meaningful, and everything on the screen needed to be there, and needed to work the way it was designed.  Chris’s reasoning was sound – while there were tons of ways to simplify this screen with standards and best practices, every single one of them diminished the usability.

Wait, what? Simplification made something LESS usable?

And that’s when it struck home: that thing I’ve said to so many people, so many times.  “Don’t let your user interface get in the way of what your user wants to do.”  I always meant that you shouldn’t have so many bells and whistles and features that people can’t accomplish their tasks, but it actually works in the reverse, too.

This was a complex, difficult-to-grok design because if any one thing was missing from it, it would be fundamentally HARDER to use. This was an enterprise application and the core wish of the two people who would use it was to have everything in one place so they could move efficiently through their workflow.  This was an expert interface, and the fact that it makes me feel stupid is a sign that it’s meeting its very tiny demographic’s needs.

Now, please don’t use this as an excuse to add one more feature to your consumer app just because your users are on it every day, and need efficient workflows.  I’m going to say that 95% of the time, the answer is to simplify, using affordances and transparency and progressive degradation, white space and  golden path optimization. Make beautiful, useful things that don’t cause people to feel shouted at or claustrophobic.

But once in a while, just once in a hootenanny, maybe the answer to making something easier to use, is to make it more complex.

Today’s Interesting Link:  This interface has SO much potential. it’s not perfect – it’ll be a while before people are comfortable arrowing through screens and so there need to be affordances that will disturb the crisp aesthetic aspirations here.  However, I love love love this idea, and I can’t wait to see what develops.

Today’s Usability Quote:
“When I’m working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong.” – R. Buckminster Fuller

Today’s Music To Design To:

Premiers Symptomes by AIR.  This is a very mellow piece, good for designing with whitespaces and light colors.  I’d listen to this for a feminine, modern kick, because it puts me in a lightweight mood.

Tool Review: Pixelapse

Every designer has, at some point, had someone say “Hey, you know how you had it before?  I liked that better.  Can you change back?”  We all have different workflows for managing this.  Saving numbered versions of psds, having folders, keeping backup layer groups… we do it all. And it’s a pain in the butt.

Photoshop plays nicely with SVN, but you have to remember to check out and check in.  No good there, we have enough to remember.  So, when I saw Pixelapse pimped on one blog or another, I started drooling.  I begged until they gave me a beta invitation, and I’ve now been using it for about a week.

Pixelapse login page

Pixelapse login page

First off, their UI is very pretty.  Clean, good use of white space, simple, and responsive.  Signup is quick and it’s obvious how to download the app.

I was surprised to see that Pixelapse is a standalone app, rather than a Photoshop plugin.  This was fine – but somehow I’d gotten a different expectation.  Once installed, Pixelapse creates its own folder on your hard drive.  Then, every time you save a change to any file that’s in that folder, it auto-uploads the change to your pixelapse account.

Here’s where I encountered my first issue – ideally I would have been able to point Pixelapse to my project folders, and have it track them from where they already live.  I was initially anxious about the Pixelapse folder, because there’s no assurance in the interface that subfoldering is supported.  So, I dragged one of my project folders in and was pleasantly surprised – I can nest folders as deep as I like in the Pixelapse folder and it’ll reflect that hierarchy on the website.

Folders are supported

Folders are supported

So far, so good.  One minor workflow change, no big deal.  However, I quickly discovered a second issue:  I only cared about versions of my psds and ai files, but Pixelapse industriously tracks every graphics file in the folders you give it.  While this might be fantastic for some designers, it caused huge amounts of clutter for me.  I would love it if, for future versions, Pixelapse would give me a setting and let me specify which file types to pay attention to.

…Because the clutter reveals what I feel is Pixelapse’s only real FLAW – I can’t tell what the organization scheme is for the files inside the folders.  There are hundreds, and I can’t figure out if they’re sorted by date.  They are certainly not sorted by name.  I’d love to be able to sort them, so that I can swap between name and most recently modified.

I decided to partially mitigate this by keeping only psd files in the Pixelapse folder, and keeping all final artwork, comp exports and supporting documents in my old folder system, which now mirrors Pixelapse.  Slightly inconvenient at first, but I was used to it after a day.

My last complaint: it’s not instantly obvious how I would pull down a certain revision.  If I wanted to download version 1 of a psd, could I do it?  I think so, and there’s a link in the upper right hand corner that looks like I could, but when I clicked the link I got an error page.

Bummer, but I didn’t feel like it was a huge deal.  This is beta software, after all, and I’m certain they’ll work the kinks out.

However, that said, I will tell you that the Pixelapse team is ridiculously responsive.  I have sent them two pieces of feedback, and they’ve been wonderful about responding within hours.  They’re courteous and earnest, and they really seem devoted to making a great product.

The verdict:  I hope I never have to live without Pixelapse again.  I’ve already used it to roll back and show someone previous versions of a file.  I envision it becoming a must-have piece in my design toolbox.

Today’s Interesting Link: of course.  These guys deserve to be successful, because they found a problem I didn’t know I wanted solved.

Today’s Usability Quote:
“Innovation springs from constraints” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:
Because I’m listening to it at this very moment – Poe’s concept album, Haunted, is delicious.  It’s old, but beautiful and poignant.  You’ve got Poe’s haunting, sexy vocals interspersed with real recordings of her father, who is passed.  It’s written as a companion to her brother’s book, House of Leaves.  I haven’t read the book, but I’m told it’s excellent.

A Better Way to Build a UX Design Library

Nathan Curtis of Eightshapes has a great post over at UIE about How to Build a UX Design Library.  I read it and enjoyed it, but couldn’t help but feel like it was way, WAY overcomplicated.  If The UX Design Library process were a UI, people would be using words like “crowded” and “confusing” and “intense”.  Because that’s what it is.

But what if there was a better way?  I think that there is.  I think you can distill all of that down to the MVP (that’s Minimum Viable Product for those of you who don’t follow Lean Startup methodologies) and start getting benefit right away, with just a couple of hours’ time invested.

Keep in mind that I think from an Agile mindset.  Get to tangible, touchable products as quickly as possible.  So what’s the bare minimum you need to get there?  You need a standard set of UI elements, in an easy to understand, access and implement structure.

Enter my MVP: A PSD UI Library.

No, stay with me here.  If you don’t use photoshop for your designs, you can do the same with OmniGraffle or even Visio or heaven forbid, PowerPoint.  You can make a library, and then you can drag and drop elements from it into all your new designs.  There are even starters out there to help you on the way.

The best part of it is, you can get started by taking a psd you’ve already made – pick your most complicated one – and just rearranging or isolating layers.  Boom – in 5 minutes you have the beginnings of a UX Design Library.

Then, when you have a couple of hours to spare, do this:

Structure Counts

You need to think of your UI elements in categories, like this:

  • Alignment
  • Typography
  • Containers
  • Backgrounds
  • Color Palette
  • Iconography
  • Messaging
  • Form Elements
  • Ad Units
  • Widgets

After you’ve done that, sit down and make a list of all the elements that fall into those categories.  Some of them are self-explanatory, the rest are:


You need to be using a grid and vertical rhythm.  I don’t care if your code is using it yet or not.  Your designs must.  And then your code needs to as soon as possible.  Really.  For alignment, determine what grid you’re going to use – how many columns?  How wide are the gutters?  Make those columns as a photoshop layer.  I recommend GuideGuide to get you there with a minimum of pain.

Determine your vertical rhythm.  I like line height * 1.5, but this is a personal thing.  Make lines that go across your design, spaced out by that many pixels vertically.

Save both of these in a group called Alignment.



These are borders, boxes, and areas.  A container might have a visible border, or it might be totally clear.  It might involve a layout of two things side by side.  It might be a specific size, or stretch to fit all the available space.

Keep in mind that containers should be distinct from backgrounds.  Why?  Because you’ll want to mix and match backgrounds and containers.



For the purposes of this structure, widgets are things that are kind of unique, and breaking them up into their elements (this container with that background and this typography and that iconography) doesn’t make sense.  My pagination is a widget.  My Member avatars are a widget.  Your widgets will vary, and so will your mileage.  This is the catch-all for unique elements.

Make it Happen

After you’ve done all of your UX architecture, here are the steps you’ll take.

  1. Make a new file.  Add the background for your site.
  2. Add things like the site header, footer, and main content containers, if applicable.
  3. Make your alignment group
  4. Add all the other elements in groups.  The groups make it very easy to find what you’re looking for when you want to use these elements.
  5. Here’s a great starter if you don’t want to create custom form elements.
  6. Distribute to anyone who makes comps.  I keep mine on a wiki and update it every time we add a new interface element or I realize I forgot one.

And that’s it.  It’ll not only speed up your design time, but it’ll get you started down the road to Neil Curtis’s complete UX Library.

Here’s my whole UI Library.  Because I’m meta, it also completely conforms (layout, line height, structure, etc) to my living styleguide.  It was the first piece of our UX Library, and it’s the piece that gets used the most often, and by the most people.  Good luck to you, and let me know if you try this strategy, and how it works out!

My full UX Library
Click to embiggen.

Today’s Interesting Link: is the best way to bring a little joy into your day.  You might notice that the ad placeholders in my UI Library are all cute and fluffy bits of adorable joy.  That’s because exists.

Today’s Usability Quote:

“You cannot have innovation unless you are willing and able to move through the unknown and go from curiosity to wonder.”  -Dawna Markova, author of The Open Mind

Today’s Music To Design To:

The Binary Universe by BT is fantastic for when you’re buckling down and needing to shut out the rest of the world while you work.  You know, those days when you need to be inspired and feel the groove without being distracted.  You can download this oldie but goodie from pretty much any digital music store.

What Do You Do?

In social settings, this is one of the most common questions.  Especially in America, we tend to define people by what they do for a living.  With UX people, that’s actually quite apt.  Like teachers, we don’t leave our work at home.

However, the answer to the question, “What do you do for a living?” is a faceted truth for a UX person, and we should apply the principles of user experience to it.  Not everyone will understand what we mean when we say “I am a user experience designer/researcher/evangelist” and it’s unkind to make people look at you with that head-cocked-to-the-side-puzzled-dog expression.

So, to each type of person, you can give a different answer without in any way being dishonest.  After all, they don’t really NEED a treatise on the entire umbrella of UX.

  • To a layman who knows nothing about computers, you might say “I work with computers. I try to make them easy to use.”
    I also say this if I don’t know anything about the person I’m talking to, since this is the safest of the answers.
  • To an artist, you might say “I’m a graphic designer.”
  • To a psychologist, you might say “I’m a software usability researcher.”
  • To someone who doesn’t know much about computers, or isn’t interested in them, you could say “I make software/websites.”
  • To Cory Doctorow, when getting a book signed with a long line behind you, you might say “I’m a UI Designer.”
Simplifying what we do down to a single bite-sized sentence might seem self-deprecating, but it’s really just a kindness.  If someone demonstrates knowledge of or interest in the field, you can expand on it.  If they don’t, you’ve done them a favor by not listing off a ton of things that make them feel stupid by comparison.
There  is one exception.
  • To a person who might possibly hire you someday, you say “I’m a [give your exact title].  I do [brief list of the things you do].”

Why?  Because this might be the only time you ever get a chance to talk to that person, and they should have all the information they need to know whether they want to continue talking to you.  You should keep your description of what you do to two sentences, and only expand if they ask you to. My own example:

“I’m a Director of User Experience.  I do usability research, interface design, information architecture, evangelism and ux team management.”

I hope this helps you have smoother conversations, and helps you see that the principles of user experience apply to everything you do, not just software design.

Today’s Interesting Link: is a useful PNG compressor for those who have trouble using other tools.  It’s easy to use and does a darn good job.

Today’s Usability Quote:

“Our role goes beyond just making visible products; we need to make objects that are relevant, meaningful, and empowering.”  — Stuart Karten

Today’s Music To Design To:

Flamenco Arabe by Hossam Ramzy is exactly what it sounds like – Flamenco music performed by an Arab musician.  If you enjoy either style of music, you are certain to love this album.  I find it evokes warm colors and intricate designs when I listen.