The Mythical User
How to manage stakeholder feedback
30 September, 2008 by Krys
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:
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
Evolution vs. Revolution: How to effect change
26 September, 2008 by Krys
There’s a term that people use for a job that is everything you could ever want, right off the bat: a pony. For a designer, the pony job is one in which you come in to a well thought out, well researched product that has no pre-existing interface and will be built using the best technology for the job, after you’ve had ample time to do your user research and design.
But that NEVER happens.
More often than not, the case is that you hire on to a company that either has an existing product with established design conventions (good or bad), or an emerging product whose original design was done by engineers and the CEO while they tried to find and hire you. Don’t get me wrong - great products can and have come out of these situations. But frequently a designer joins a team or a company and in addition to designing the ever-flowing panoply of new features required to stay competitive and build brand, they also have a mess to clean up.
So how do you do this, without losing ground a competitive marketplace? Design takes resources - Product, Marketing, Engineering, QA, sometimes even executive. While those people are working on requirements, testing, coding and verifying all these fancy fixes you want, they’re not doing the things necessary to whoop your competitors into forlorn lumps of also-ran.
Yes, we all know that having a usable website or application is an integral part of remaining competitive. I take great pleasure in reciting a story about a director of E-commerce at a Fortune 500 company that hired me as a consultant. When I was giving him the standard ROI speech on usability, he actually said to me “We got this far without doing any usability. Why should we start now?”
That director no longer works for that company.
Joking aside, though, it is a tricky balancing act - how do we update our past code while still driving forward with new?
The answer is evolution.
Evolution is a multi-general process in which an organism changes to adapt to its environment. Your website or application SHOULD be a living organism of sorts, growing and shedding and hopefully healthy. There’s no reason your website can’t evolve.
If you think about it, stopping everything to have a revolution - major relaunches, complete identity changes - is an enormous and painful act. It costs unimaginable amounts in money and time, not to mention your users’ pain as they relearn everything they were comfortable with. It sets you back in brand identity, because you have to rebuild everything you’ve built. And the potential for things to go wrong, the risk of failure, is enormous.
It’s not that there’s never a time for revolution. We can all think of one or two incredibly successful relaunches, or prominent redesigns. But honestly, it’s a drastic measure that should be left to the giant behemoth corporations, or used as a last resort.
Because you can always evolve.
Start with a plan, a vision for your end goal. I like to draw pictures and make spreadsheets, but other people might work differently. This becomes your strategy, and is much more powerful than any buzzword-filled strategy statement will ever be.
Then take the most heinous wrongs and right them first. What are the usability holes your users are complaining about? Will converting static pages to AJAX enable ten other improvements later? Can you revamp the golden path all in one fell swoop? Start one at a time and break out all the tiny tasks that make up the grand vision. Let your site mutate.
Your users will complain. Unless you have the most complacent user community on the interwebs, SOMEONE is going to complain about every single thing you change. I have actually had users complain when I reduced clicks. Listen, but don’t be discouraged. Most of the time, if you did your research well enough, those same users will fall in love with the new stuff after a few uses. They’re habit driven. And if you were wrong, and what you did actually DID make things worse, well, you only have a small mutation to roll back, rather than a huge redesign.
It’s not ideal. Who wants to change one page at a time and have potential inconsistencies with their names attached? Who wants to wait a year or two for pages to be tiled? But in the big scheme of things, it’s worth the wait, and it’s a great way for a design team to empower the corporate strategy, rather than slowing it down.
Today’s Glossary Term:
Golden Path -The primary task flow or navigation flow of a website or application. If you can’t instantly identify the golden path for your app, you should immediately sit down and figure it out. What is the one thing that everyone should or wants to do when they come to you? And how do they do it?
Today’s Interesting Link:
http://www.dontclick.it Both beautiful and brilliant. Imagine a web interface in which you don’t click. Then follow that link and go experience it.
Today’s Usability Quote:
"The greatest mistake you can make in life is to be continually fearing you will make one." - Elbert Hubbard
Today’s Music To Design To:
Dead Can Dance have been around for too many years and have too many albums for me to recommend just one. Honestly, almost anything you find from them is great, and it’s all got a mellow, exotic groove that lends itself amazingly well to creative work.
Check them out at Amazon.com
Rapid Prototyping: Slideshows
17 April, 2008 by Krys
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
24/7 Usability Methods
2 April, 2008 by Krys
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
Time Keeps on Ticking: How to reset timelines
17 March, 2008 by Krys
You busted your butt for four days to complete a set of mockups derived from a "final" PRD. You even took the extra effort to include the wireframes and a mini-spec. Then the Product Manager has a genius idea that changes everything, and suddenly you’ve got to start over from scratch. You don’t mind; it’s a good idea and after all, that’s job security, right?
Then comes the punchline. At 5pm on Thursday he presents his scope and direction change to you, and smiles blankly as he says “So when can we have updated mockups? I’d like to show them tomorrow at 2.”
I know, I know - but murder is illegal and slashing his tires only means he’ll spend more time in the office. You have to find a civil way to educate the poor fool. Honestly, he’s not TRYING to give you an aneurism. It’s just ignorance.
So, how do you educate a Project and Product team that, when scope or direction of a project changes, they have to accept a timeline slip? O Grasshopper, you’ve come up against the age-old dilemma of more than just the UI folks. But lucky for you, this Old Man On The Mountain has an answer.
You have to be stubborn, manipulative, and flexible all at once.
First of all, we all know the Scotty Principle, right? At the very beginning of a project you’re always asked to give a guesstimate of how long it’s going to take you. Usually, without all the info you need. So, you take a good guess, triple it, and make that your estimate. The product or project manager always goggles and clutches their chest, you subtract two days, and they breathe a huge sigh of relief. Then, you can deliver early, look like a hero, and the developers thank you for the extra wiggle room later.
That Scotty Principle padding will come in handy when the project changes. If you delivered early, you can just assert the rest of your reserved timeline.
Second, you may have to exaggerate the amount of work that goes into restarting a project. Don’t LIE - because it’s important that people know they can trust you. But you can beleaguer the point (”I kinna do it, kaptin!”) and let them draw the conclusion that it’s more work than it is. Then, when you ask for 3 days instead of the half-day they offered you, they’ll be impressed that you’re willing to work so hard and so fast.
Third, employ some negotiating skills. My Scottish ancestors are well known for their frugality and their ability to haggle - something I’ve employed liberally in my career. Ask for more than what you want, and let them work you down to what you DO want. Don’t be afraid to be outrageous with your requests.
Fourth, and this might be the most important - be willing to work the extra hours if it means doing the right thing for your users. Be willing to pull an all-nighter to meet an unreasonable deadline, because in the end, you’re part of a team, and sometimes timelines CAN’T slip by much. Understand that while it’s important to put our feet in the sand, and teach the lesson that good design takes time, it’s also sometimes important to be flexible and work your butt off for the greater good.
Knowing when is the bigger problem. :>
Today’s Glossary Term:
Storyboards - These are rough, high-level sketches used to indicate workflow and possibly basic functionality. Sometimes they’re done by hand, sometimes with Visio or some other program. They should not indicate what a page or step LOOKS like, only provide a user-based series of steps including important information, decision points, and backtracking.
These are really useful in making optimal workflows, and working through intial requirements. I color-code them, as well, to help indicate where an experience might be less than perfect.
Today’s Interesting Link:
http://kuler.adobe.com - Adobe’s Kuler is not only a beautiful interface, it’s also terribly useful. Looking for a color palette and stumped? Needing inspiration? That’s the place. There are so many color palettes, you’re sure to find something to satisfy you. Apply it to more than just software design - I’ve used this in making clothing, decorating my house, and painting!
Today’s Usability Quote:
"Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense." - The Buddha
Today’s Music To Design To:
In honor of St. Patrick’s Day, Afro-Celt Sound System. Whether you like to design while listening to music with or without lyrics, Afro-Celt is sure to please. Their stuff is an interesting combination of African, Indian and Celtic music, with some great electronic beats. They’ve worked in collaboration with some top-notch singers including Sinead O’Connor and Peter Gabriel. I can’t recommend them highly enough. Buy the CD or Download the MP3s
Welcome to The Mythical User
14 March, 2008 by Krys
Through the mist, a brilliant light cuts a swath of whiteness. Somewhere impossibly far away, a black speck mars that perfect shining bar, and as it grows you realize a person is walking toward you, as if the light were a solid path. The figure grows and you see it - average height, average clothing, average income, average age, indeterminate gender. As celestial choirs of angels sing, you realize you are in the presence of the Great and Holy User.
Okay, so maybe it’s not like that in the real world.
The reality of user interface design is that rarely do we ever get to consult our users even a fraction as much as we should. Whether the company is large or small, startup or mature, UI design is often given only a token nod in project plans. No matter how trained the project or product manager is, they always seem to forget up-front research. So, we, the mockup monkeys of the world, resort to our weapons - industry standards, emerging best practices, and least tangible of all, instincts.
Then there are our engineers.
We love these people, don’t we? Some of us started out as developers, others are headed that direction eventually. Regardless, the people who receive and implement the pretty pictures that designers make are often so removed from the User that it seems like a myth, wrapped in mysterious symbols and color-codes and head-shaking illogic. We, the designers, often take on an evangelistic role, preaching the Greater Good of the Lowest Common Denominator from our soapboxes like southern roadsermons - but hopefully without the polyester suits.
If this sounds familiar to you - if you’re that beleaguered designer, mystified engineer or even a user who can’t fathom why his voice isn’t heard, you’re in the right place. Stop in, kick your feet up, and join in the discussion. Together, we’ll build a more usable world.
How to manage stakeholder feedback
30 September, 2008 by Krys
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.
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
Evolution vs. Revolution: How to effect change
26 September, 2008 by Krys
There’s a term that people use for a job that is everything you could ever want, right off the bat: a pony. For a designer, the pony job is one in which you come in to a well thought out, well researched product that has no pre-existing interface and will be built using the best technology for the job, after you’ve had ample time to do your user research and design.
But that NEVER happens.
More often than not, the case is that you hire on to a company that either has an existing product with established design conventions (good or bad), or an emerging product whose original design was done by engineers and the CEO while they tried to find and hire you. Don’t get me wrong - great products can and have come out of these situations. But frequently a designer joins a team or a company and in addition to designing the ever-flowing panoply of new features required to stay competitive and build brand, they also have a mess to clean up.
So how do you do this, without losing ground a competitive marketplace? Design takes resources - Product, Marketing, Engineering, QA, sometimes even executive. While those people are working on requirements, testing, coding and verifying all these fancy fixes you want, they’re not doing the things necessary to whoop your competitors into forlorn lumps of also-ran.
Yes, we all know that having a usable website or application is an integral part of remaining competitive. I take great pleasure in reciting a story about a director of E-commerce at a Fortune 500 company that hired me as a consultant. When I was giving him the standard ROI speech on usability, he actually said to me “We got this far without doing any usability. Why should we start now?”
That director no longer works for that company.
Joking aside, though, it is a tricky balancing act - how do we update our past code while still driving forward with new?
The answer is evolution.
Evolution is a multi-general process in which an organism changes to adapt to its environment. Your website or application SHOULD be a living organism of sorts, growing and shedding and hopefully healthy. There’s no reason your website can’t evolve.
If you think about it, stopping everything to have a revolution - major relaunches, complete identity changes - is an enormous and painful act. It costs unimaginable amounts in money and time, not to mention your users’ pain as they relearn everything they were comfortable with. It sets you back in brand identity, because you have to rebuild everything you’ve built. And the potential for things to go wrong, the risk of failure, is enormous.
It’s not that there’s never a time for revolution. We can all think of one or two incredibly successful relaunches, or prominent redesigns. But honestly, it’s a drastic measure that should be left to the giant behemoth corporations, or used as a last resort.
Because you can always evolve.
Start with a plan, a vision for your end goal. I like to draw pictures and make spreadsheets, but other people might work differently. This becomes your strategy, and is much more powerful than any buzzword-filled strategy statement will ever be.
Then take the most heinous wrongs and right them first. What are the usability holes your users are complaining about? Will converting static pages to AJAX enable ten other improvements later? Can you revamp the golden path all in one fell swoop? Start one at a time and break out all the tiny tasks that make up the grand vision. Let your site mutate.
Your users will complain. Unless you have the most complacent user community on the interwebs, SOMEONE is going to complain about every single thing you change. I have actually had users complain when I reduced clicks. Listen, but don’t be discouraged. Most of the time, if you did your research well enough, those same users will fall in love with the new stuff after a few uses. They’re habit driven. And if you were wrong, and what you did actually DID make things worse, well, you only have a small mutation to roll back, rather than a huge redesign.
It’s not ideal. Who wants to change one page at a time and have potential inconsistencies with their names attached? Who wants to wait a year or two for pages to be tiled? But in the big scheme of things, it’s worth the wait, and it’s a great way for a design team to empower the corporate strategy, rather than slowing it down.
Today’s Glossary Term:
Golden Path -The primary task flow or navigation flow of a website or application. If you can’t instantly identify the golden path for your app, you should immediately sit down and figure it out. What is the one thing that everyone should or wants to do when they come to you? And how do they do it?
Today’s Interesting Link:
http://www.dontclick.it Both beautiful and brilliant. Imagine a web interface in which you don’t click. Then follow that link and go experience it.
Today’s Usability Quote:
"The greatest mistake you can make in life is to be continually fearing you will make one." - Elbert Hubbard
Today’s Music To Design To:
Dead Can Dance have been around for too many years and have too many albums for me to recommend just one. Honestly, almost anything you find from them is great, and it’s all got a mellow, exotic groove that lends itself amazingly well to creative work.
Check them out at Amazon.com
Rapid Prototyping: Slideshows
17 April, 2008 by Krys
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
24/7 Usability Methods
2 April, 2008 by Krys
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
Time Keeps on Ticking: How to reset timelines
17 March, 2008 by Krys
You busted your butt for four days to complete a set of mockups derived from a "final" PRD. You even took the extra effort to include the wireframes and a mini-spec. Then the Product Manager has a genius idea that changes everything, and suddenly you’ve got to start over from scratch. You don’t mind; it’s a good idea and after all, that’s job security, right?
Then comes the punchline. At 5pm on Thursday he presents his scope and direction change to you, and smiles blankly as he says “So when can we have updated mockups? I’d like to show them tomorrow at 2.”
I know, I know - but murder is illegal and slashing his tires only means he’ll spend more time in the office. You have to find a civil way to educate the poor fool. Honestly, he’s not TRYING to give you an aneurism. It’s just ignorance.
So, how do you educate a Project and Product team that, when scope or direction of a project changes, they have to accept a timeline slip? O Grasshopper, you’ve come up against the age-old dilemma of more than just the UI folks. But lucky for you, this Old Man On The Mountain has an answer.
You have to be stubborn, manipulative, and flexible all at once.
First of all, we all know the Scotty Principle, right? At the very beginning of a project you’re always asked to give a guesstimate of how long it’s going to take you. Usually, without all the info you need. So, you take a good guess, triple it, and make that your estimate. The product or project manager always goggles and clutches their chest, you subtract two days, and they breathe a huge sigh of relief. Then, you can deliver early, look like a hero, and the developers thank you for the extra wiggle room later.
That Scotty Principle padding will come in handy when the project changes. If you delivered early, you can just assert the rest of your reserved timeline.
Second, you may have to exaggerate the amount of work that goes into restarting a project. Don’t LIE - because it’s important that people know they can trust you. But you can beleaguer the point (”I kinna do it, kaptin!”) and let them draw the conclusion that it’s more work than it is. Then, when you ask for 3 days instead of the half-day they offered you, they’ll be impressed that you’re willing to work so hard and so fast.
Third, employ some negotiating skills. My Scottish ancestors are well known for their frugality and their ability to haggle - something I’ve employed liberally in my career. Ask for more than what you want, and let them work you down to what you DO want. Don’t be afraid to be outrageous with your requests.
Fourth, and this might be the most important - be willing to work the extra hours if it means doing the right thing for your users. Be willing to pull an all-nighter to meet an unreasonable deadline, because in the end, you’re part of a team, and sometimes timelines CAN’T slip by much. Understand that while it’s important to put our feet in the sand, and teach the lesson that good design takes time, it’s also sometimes important to be flexible and work your butt off for the greater good.
Knowing when is the bigger problem. :>
Today’s Glossary Term:
Storyboards - These are rough, high-level sketches used to indicate workflow and possibly basic functionality. Sometimes they’re done by hand, sometimes with Visio or some other program. They should not indicate what a page or step LOOKS like, only provide a user-based series of steps including important information, decision points, and backtracking.
These are really useful in making optimal workflows, and working through intial requirements. I color-code them, as well, to help indicate where an experience might be less than perfect.
Today’s Interesting Link:
http://kuler.adobe.com - Adobe’s Kuler is not only a beautiful interface, it’s also terribly useful. Looking for a color palette and stumped? Needing inspiration? That’s the place. There are so many color palettes, you’re sure to find something to satisfy you. Apply it to more than just software design - I’ve used this in making clothing, decorating my house, and painting!
Today’s Usability Quote:
"Believe nothing, no matter where you read it, or who said it, no matter if I have said it, unless it agrees with your own reason and your own common sense." - The Buddha
Today’s Music To Design To:
In honor of St. Patrick’s Day, Afro-Celt Sound System. Whether you like to design while listening to music with or without lyrics, Afro-Celt is sure to please. Their stuff is an interesting combination of African, Indian and Celtic music, with some great electronic beats. They’ve worked in collaboration with some top-notch singers including Sinead O’Connor and Peter Gabriel. I can’t recommend them highly enough. Buy the CD or Download the MP3s
Welcome to The Mythical User
14 March, 2008 by Krys
Through the mist, a brilliant light cuts a swath of whiteness. Somewhere impossibly far away, a black speck mars that perfect shining bar, and as it grows you realize a person is walking toward you, as if the light were a solid path. The figure grows and you see it - average height, average clothing, average income, average age, indeterminate gender. As celestial choirs of angels sing, you realize you are in the presence of the Great and Holy User.
Okay, so maybe it’s not like that in the real world.
The reality of user interface design is that rarely do we ever get to consult our users even a fraction as much as we should. Whether the company is large or small, startup or mature, UI design is often given only a token nod in project plans. No matter how trained the project or product manager is, they always seem to forget up-front research. So, we, the mockup monkeys of the world, resort to our weapons - industry standards, emerging best practices, and least tangible of all, instincts.
Then there are our engineers.
We love these people, don’t we? Some of us started out as developers, others are headed that direction eventually. Regardless, the people who receive and implement the pretty pictures that designers make are often so removed from the User that it seems like a myth, wrapped in mysterious symbols and color-codes and head-shaking illogic. We, the designers, often take on an evangelistic role, preaching the Greater Good of the Lowest Common Denominator from our soapboxes like southern roadsermons - but hopefully without the polyester suits.
If this sounds familiar to you - if you’re that beleaguered designer, mystified engineer or even a user who can’t fathom why his voice isn’t heard, you’re in the right place. Stop in, kick your feet up, and join in the discussion. Together, we’ll build a more usable world.