The Mythical User

Taking the mystery out of User-Centered Design

Inside the Workflow: Sketching on Whiteboards

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

Inside the Workflow: Sketching on Whiteboards

Advertisements
Leave a comment »

5 Ways to Make It Safe to Fail

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

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

Leave a comment »

Clear ownership makes for a happy team

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

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

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

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

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

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

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

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

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

Designers have a role in this too.

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

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

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

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

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

The bottom line

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

Today’s Interesting Link:

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

 Today’s Usability Quote:

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

Today’s Music To Design To:

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

Leave a comment »

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

Leave a comment »

Get Your Interface Out of The Way


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

Leave a comment »

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:

Alignment

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.

Image

Containers

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.

Image

Widgets

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:

www.placekitten.com 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 placekitten.com 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.

Leave a comment »

How to manage stakeholder feedback

One of the hardest parts of a UE person’s job is to reconcile the needs and priorities of users with the differing needs and priorities of internal departments. Inevitably, you’ll get great feedback that either doesn’t work because it conflicts with someone else’s, or because it doesn’t take all factors into account. Inevitably, you’re going to have to tell someone “Thanks but no thanks.”

Realistically, this is why we’re paid what we are.  It’s not because we have design school degrees or can write three languages by hand.  It’s because we take the pressures from all concerned parties and turn them into the best realistic solution.  It’s like being the rope in a multi-dimensional game of tug-of-war.

Sometimes, that means choosing the lesser of two evils.   Every designer has at least one story of where they had to throw band-aids all over a terrible situation with no time, no user testing, and without the buy in of half the stakeholders.

Today, I heard a stakeholder say, “Why are you asking for my input if you’re not going to listen to it?”

His frustration is universal.  It’s the same way I feel when my daughter asks “blue or purple?” and then chooses the opposite of what I answer.  Why waste my time?

There’s a good answer to this question, though, and it’s worth your time to explain.

Good user experience can’t happen in a vacuum.  It also can’t happen by committee.  If you’re worth your salt as a UE person, you absolutely must take the time to gather every viewpoint and perspective you possibly can.  However, if you implemented every suggestion that was made to you, not only would NO ONE be happy with the result, your product would be an unusable hodge-podge.  (Believe me, I’m tempted to make a mockup with everyone’s suggestions someday, just to let them see what the alternative is!)  Someone has to mediate.  And at the end of the day, that Someone who has to weigh all the information and make a choice, is you.

So if a stakeholder ever expresses this frustration, here’s what you need to do:

  • Tell them you understand how they feel.
  • Tell them you ask for their feedback because it’s both good and important.
  • Remind them of times in the past when you’ve acted on their feedback.
  • Explain that you have to weigh everyone’s feedback, and this time you had to make a tradeoff that they didn’t win, but next time they might.

This is the worst part of our job; thanking people for feedback we can’t act on.  But it’s also the best, because it builds a relationship of honesty and trust between you and your stakeholders.  Remember that they’re as invested in your product as you are, and you’ll all get through, just fine.


Today’s Glossary Term:
Ubicomp – Ubiquitous computing.  This term describes the phenomenon that we and our users experience every day – every aspect of our lives is becoming computerized.  There are computers in our watches, our cars, our refrigerators.  We are living at the birth of the Era of Ubicomp.

Today’s Interesting Link:
http://www.yellowpagesgoesgreen.org/index.html – This site is a prime example of a great idea with a suboptimal UI.  The main purpose of the site is lost in all of the clutter.  It’s attractive, it’s modular, it’s organized – but there’s no hierarchy at all.  I suspect that no one told the designer what was highest priority on this page.

Today’s Usability Quote:
“You can please some of the people all of the time, and all of the people some of the time, but you can not please all of the people all of the time.” – Krys Taylor, revising Abraham Lincoln

Today’s Music To Design To:
Sparky’s Flaw is a relative newcomer to the music scene, but they’ve got charm and talent in spades.  Their music is a fresh style of rock, and their lyrics are both endearing and thought-provoking.  Their tunes are catchy enough that you’ll find yourself tapping your foot even if you’re only listening in the background.
Download the MP3s

Leave a comment »

Rapid Prototyping: Slideshows

First of all, let me express to you how important rapid prototyping is.

You absolutely ought to do requirements gathering first, then come up with a theory of what your users want, then build a quick-and-dirty prototype and take it back to users – both the ones you gathered requirements with, and others. This can take you a few days and cost a few hundred dollars, and it can save you hundreds of thousands in development, materials, or man hours.

So now that we’ve established that you all agree and will employ rapid prototyping before you build anything big, let’s get into the meat. There are a lot of ways to do make a prototype. Depending on your medium, you can build a cork-board model, draw pictures on a piece of paper, or whip out wireframes and screenshots. Regardless, you shouldn’t spend too much time on them – depending on the size of the project, we’re talking an hour to 2 days, no more. They don’t have to be perfect, fancy, interactive, or anything along those lines. They are nothing more than a tangible representation of an idea or concept. Nothing more.

One way, particularly useful for an experience (like a tour), or an application (web-based or desktop) is to use a slideshow.

Irfanview is a free, easy to use downloadable application. It has lots of features, but the only one I ever use is the slideshow builder. You can drag screenshots in, and then set controls on each for mouse click, arrow, etc. This enables you to get on the phone with a remote user, and bring up the screenshots in any order you want, without opening gifs from a folder. It can completely fake user interaction, as far as clicking goes – click with the mouse and it can take you to a next screenshot that shows a list expanded or a field filled in.

It saves out to an .exe file, so you can then send the “prototype” to anyone you want. You can make it go from slide to slide automatically, or control each slide individually. File sizes are reasonable. I also use it for training, and believe it or not – I have a version of my portfolio in an executable slideshow. Many possibilities for a little free gem!

Irfanview’s interface isn’t the prettiest or simplest, but the basic functionality only took me a few minutes to figure out. It’s incredibly powerful, when you’ve got a test you need to keep running smoothly.

Enjoy this tool, and if you find others like it, please comment and let everyone know!


Today’s Glossary Term:
AEIOU – A research method focused on Actions, Environments, Interactions, Objects, and Users. It’s primarily used for ethnography (studying people and making a mental model of how they see the world) but can also be a good mnemonic to spread throughout your team. It helps to get everyone thinking of the world from the user’s point of view.

Today’s Interesting Link:
http://www.csszengarden.com/ – Is one of the places I go when I’m feeling boxed in by a design. It’s a great resource for inspiration, or if you’re looking to improve your CSS skills. If you don’t already have Zen Garden bookmarked, you really ought to.

Today’s Usability Quote:
“The greater danger for most of us is not that
our aim is too high and we miss it, but
that it is too low and we reach it.”
– Michelangelo

Today’s Music To Design To:
Getting away from the edgy electronica, it’s time for a Jazz recommendation. However, Jenna Mammina is not “just” jazz. She uses her voice like an instrument, switching between belted lyrics and then lilting back into a soft, sultry croon.
Download the MP3s or Buy the CD

Leave a comment »

24/7 Usability Methods

Mark Hurst has a great post on “Listening Labs” in his excellent blog. In it he talks about a method I can’t recommend highly enough – a freeform session in which you watch your user actually use your product, their way. No test script, no tasks, no standardized objectives. Just “show me what you do”. I’ve been using this method for about 10 years now, to identify problem areas, build personas, and flesh out requirements.

What surprised me about Mark’s article is that he called “Listening Labs” an unorthodox method. I’d never thought of this as particularly clever or unusual, so it got me thinking.

There is a mindset amongst us product people that user feedback is best solicited through guided methods. Interviews, surveys, lab time, observations… all of these things structure your time with the user and are great for targeting specific stuff. But I feel that it’s absolutely crucial to do an additional sort of data gathering – we’ll call it 24/7 Usability.

24/7 Usability means that at any given moment of any given day, you are soliciting feedback on your existing product. There are a number of ways to do this, and you’ll be amazed at how simple they are.

The Feedback Link
First and foremost, the very minimum you should do. You should have a way for a user to give feedback from any page or screen in your application. The feedback should have a form, so you can get enough info to respond to them – and it should be called “Feedback”. Seriously “Tell us what you think” or “suggestions” or “comments” or any number of other cute, non-standard things may give your site/app personality, but it’s not necessarily going to be instantly recognizable to a confused or frustrated user.
The result of this form should go to customer support, of course, but the user experience team or professional should be CC’ed. Just work out who is the responder, and make sure you’re not double-teaming your poor users with responses.

Message Boards/Forums
I can’t tell you how valuable the Usability Forum for my product is. I post survey questions there, I answer interface questions (each one identifies a problem with the design!) and I get requests. I can even share screenshots of proposed designs, since only registered users can get to the forum. I keep a spreadsheet that logs every feature request and confusion point, along with how many users have requested it, and what type of user they are. When I’m building my strategy, I refer to this spreadsheet like a bible.
When a new feature gets released, or an old one gets improved, I head back to the forum and comment on every post that asked for it, letting users know we listened to them. As a result, our users have confidence that their feedback is being heard and acted on.
A bonus is that because the forum is public, if a user requests a feature that doesn’t make sense to other users, those other users will dispute their request, and they often work out a compromise between themselves – without my interference!

Your Customer Support Team
If you’re not already good friends with every one of your customer support folks, you’d better bake them cookies and get on it. These people are the front line of usability. They hear all the complaints – and the compliments!
I’ve got an arrangement with my support managers – whenever anyone in support gets a call where the problem is interface, or they can’t find a button, or don’t understand a word – support sends me an email. These all get tracked in that Holy Spreadsheet too, with special annotation that it came from a support critter. Those get higher weight because they were bad enough that someone picked up the phone and made a call.

Your Sales Team
Believe it or not, your sales people are just as important as the customer support people. Here’s where you have to be careful, because there are often qualifying factors. However, a salesperson knows that when she is demo’ing a product, and three potential customers ask the same question, there’s a real problem there. I’ve even taught my salesmonsters how to ask followup questions in a non-leading way, empowering them as mini-moderators. These guys are a fantastic source of feature requests, and they can give you the pulse of a customer segment you REALLY want to make happy – the ones you don’t have yet.

Statistics
All too often, apps – whether web-based or dowloadable – are built in a hurry, with an eye to timelines and no thought of the future. However, it’s important to build into your architecture the ability to track everything a user does.
There are privacy issues, of course. However, it’s incredibly simple to assign a different token to each of three links to the same page, so you can tell which one is getting used the most. Qualitative data is precious, but nothing beats sheer quantitative data to show you what you’re doing right and wrong.
Take the extra day, or week, or month, to make sure that you’re tracking user behavior without violating privacy or user trust. It’s well worth it.

The point is, usability shouldn’t be an on- and off- thing. If you only test in spurts, you’re likely to miss some very important issues and opportunities. Consider every contact with a user, whether that contact is via website, person, or product as an opportunity to do 24/7 usability.


Today’s Glossary Term:
Wireframe – A rough diagram of a page/screen, either sketched by hand or made with black & white lines, that generally indicates basic layout and what info/functionality is shown. These are good for first walkthroughs, high-level validation of a concept, and finalizing requirements. They’re also great when you’re playing with multiple layouts or methods, because they take very little effort/time and can be very illustrative.

Today’s Interesting Link:
http://supercook.com/ – It’s got your usual web 2.0 look and feel, but the layout is useful, primary functionality is well highlighted, and the concept is great. I frequently have the problem of having too much of X and not wanting to let it go bad – with this site you enter an ingredient and it pulls up recipes.
I particularly like the suggestions on the search box, the mouseovers on everything, and the reactive nature of the site. Well done!

Today’s Usability Quote:
“If it was magic, how would it work?” – Alan Cooper

Today’s Music To Design To:
Ape of Naples is a fantastic album by Coil. If you’re familiar with Coil, you’ll enjoy the dark, funereal remixes, and if you aren’t familiar with them, it’s a good introduction. Excellent for designing dark, edgy stuff.
Buy the CD or Download an MP3

1 Comment »