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

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.zurb.com – 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.

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:

http://readymag.com/  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.