Usability Issues: Tab Order

Open your application. Start hitting Tab on your keyboard. Look where focus goes. Is order intuitive or random? Are all controls accessible?

Try to fill in form in your application. Go through edit boxes, check boxes and radio buttons with Tab. Can you get to another control you are expected to fill with one Tab press? Each time?

Setting correct tab order is a small, yet dull, development task. You don’t gain much completing the task. On the other hand you lose much if you reject to set the tab order properly. Your users get frustrated with the product. User experience peaks down. Everyone starts using competitor’s software. Your company bankrupts... OK, I went too far with that one. However that’s another small thing usability is built from.

Whole usability issues series.

Usability Issues: Nice Enough

Make your application looking nice. I don’t say every app has to be shiny and polished like Vista, but make it looking good enough for your users. If you write for system administrators then console should be enough. But if you do anything more, even when your UI can look ugly don't make it sloppy. Controls set straight. Buttons placed intuitively on each window. Toolbars don’t changing their appearance randomly. All controls and options accessible with keyboard.

You get much with little effort.

Whole usability issues series.

Usability Issues: Most Frequent Used Means Most Important

Which features are the most important? For salespeople newest ones. For marketing your application differentiators. For developers those which bring interesting problems to solve. Unfortunately usually none of them actually eat their own dog food. And for users the most important features are those which are used the most frequently.

If you need or want to work on usability focus on those functions. It can be search and time you need to wait to see first results (first 10, not all 16,9 million of matching results). It can be filing an invoice for simple invoicing application (what a surprise). It can be writing or test formatting for word processor. You name it. It’s your software.

Checks how accessible are those features. Measure how fast they response. Verify if they are easy to use. Think how intuitive for a new user they’ll be. Focus only on features which are used the most often. When you have no ideas how to improve them move to next, a bit less frequently used.

Whole usability issues series.

Usability Issues: Responsiveness

You take this new app which is told to be better than the one you use at the moment. If you’re lucky it’s intuitive and you don’t have any problems to set it up. Then you start working. And it hits you. Important operations are slow. Not dramatically slow, but significantly slower than with the old app.

Take new shiny Vista box with new shiny Office 2007 and sometimes it’ll freeze for a second. Annoying. Your good old XP with Office 2003 didn’t perform like that. Take Google Spreadsheet try to cut and paste a piece of cells. What the heck is happening? Am I faster than the app? Oh, yes I am. It wouldn’t happen with good old Excel.

The clue here is responsiveness. How fast application will answer to most often executed operations. Lightning fast? Maybe as fast as industry standard? Or you’re just too slow?

This is the big issue especially for web applications. Responsiveness of the web is significantly worse than desktop application. As far as we used WWW just to browse websites it was natural since it wasn’t a replacement for an existing application but a completely new one. With financial, CRM, project management or office apps we’re trying to replace desktop software we use every day. If they’re slower the user experience descriptions will definitely use the word “frustration.”

Focus on your software responsiveness, especially on the most important functionalities. Compare to other, legacy software in your market. If you’re significantly slower, well, that’s a sign you have a task to do: improve.

Whole usability issues series.

Usability Issues Series

I was writing here about usability of applications on a couple of occasions. And since usability is made of small things I thought it’s a great idea to run another series of short posts on the subject.

There will be post per week published unless I’m off on vacations or some disaster happens.

Usability issues so far:

Responsiveness
Most frequent used means most important
Nice enough
Tab order

Don’t Confuse Users

“Let’s add some function here. It’ll work that way for the first 15 minutes since the service activation and another way later. We’ll have to teach users only one function instead of two.”

And you’ll have your users wandering why the heck that feature works differently each time they use it.

“Let’s put a menu here. User will be able to choose what exactly he wants to do. Menu will appear each time a user enters as it should be possible to choose each option even if the first one will be chosen in a vast majority of cases.”

And you’ll have your users swearing each time they’re choosing the default option as they always do.

Make your users’ life easier. Give them simple unambiguous paths and shortcuts. If you have two different functions give two different buttons, menu options or short-codes to invoke them. If you have one option used much more often give a shortcut by adding another easier method of calling it.

Users like simple operations. If you need to teach users for more than several seconds how to launch your new cool feature it’s too difficult. Note that I’m telling about launching a function, not describing what it does and how it works.

If you ask me, leave ideas as those mentioned above and try to find a way to have each feature, which is extensively used available under one click.

Users Like What They Know

You plan to introduce a new version of your widely spread application and one of key features will be new user interface. Or maybe you enter the market with new product which shall compete with market leaders and now you design GUI for your app.

And you have lots of ideas how to organize user interface better than it was done before. That’s for sure.

Unfortunately it does mean you set up a goal which is hard to achieve. I can even assume all your improvements ideas are great, which is rarely true. But let’s not complicate the situation. They are great.

You launch your new version/product/whatever and complaints start. We want to have spreadsheet working Excel-like. We want to work on Gantt charts in a way we work with MS Project. We want to have search looking like Google. We want to have invoicing window the same as it is in SAP. We want to have it the way it used to be. Keep your great ideas for others, we want our old damn interface back.

Because we like what we know. And we don’t want to learn new ways of doing things we do. We just don’t.

If you want to try to change the world of users habits you have two ways. You either believe your idea is strong enough to prevail or you stick to standards (no matter how low they are) and work hard to teach users new ways of doing things. The most obvious example of former is Google with clean search engine design. The examples of the latter can be Project-ON-Demand or Google Spreadsheet.

The first option has much higher failure rate. For each example of success you can find a bunch of examples of failure. From time to time I check different applications from area of project management and every time I see GUI totally different from what MS Project offers I see incoming failure. People won’t know it so they won’t like it. I don’t say MS Project is cool. It isn’t. I don’t like MS Project. Actually I hate it. But I used to it and most people around did too. Everyone knows how it works. Everyone expects other software doing the same things will work similarly.

Sure, you always can try to educate me with different approach but remember I’ll be reluctant. I’m like a typical user. Users like what they know. And they are lazy too. Remember about that next time when you start redoing all your user interface or reinventing the way people do things.

Getting Users Emails

For web-based business one of the most important measures (usually single most important one) is a database of users. When we think “user” we see “email”. Sometimes more but the very first thing is an email address. There are lots of businesses which are valued highly only because they gathered a big number of emails... I mean users. The more emails... I mean users you have the better.

That’s web-business owner perspective.

On the other hand we, as users, are always suspicious when someone wants us to give out our email address before we can see the application or use the service. Who doesn’t have so called spam email which is entered whenever we have to sign up to the application we don’t know we will use longer than five minutes. We don’t even check what is there. We only click the confirmation link and voila. We’d prefer to keep our emails private as far as possible.

That’s user perspective.

I value services which allowed to be used without registration. YouTube is a standard example, but we did exactly the same in Overto. You can use main features (search through auctions) without registering. Although in YouTube when you want to upload a clip or access all content you have to sign in. When you want to use subscriptions in Overto you have to sign in. Service owners get information they want. You trick them with crappy address.

By the way that’s smarter tactic than just forcing users to register before they can do anything. In that case I usually walk away.

Lately I see more and more sites with another approach. They don’t force you to register at all. A good example can be myminicity.com. A kind of on-line game where you build your virtual city. The game keeps people coming back by giving them personalized website (their city). And it works. Sure they won’t spam you with newsletter covering features they have just added but who likes that spam anyway? If you don’t force people to register in any way those who do give you right emails.

That’s always a quality versus quantity question. Think about it another time when you ask your users to give you their email.

What Is Your Mobile Website?

We’re becoming more and more mobile these days. Yes, I know, I should try myself in “The most obvious thought of the day” or something like that. We’ve already moved out old-school thick clients to websites available from any browser on any computer. Next step is already there and these are our mobile phones.

We don’t carry our laptops everywhere and even if we do it’s not always convenient to use them. On the other hand you can operate typical mobile phone using one hand while standing in crowded bus.

For those who are still there loosing their last hope I actually might have something to tell which is at least a bit less evident – thank you for support. I’m going right to my point. Usability.

You have your website (whatever it does). Think why mobile users come and how they interact with the website. Company’s home site? They rather won’t come here from their phones. Newsy site? Chances are quite good. On-line game? A sure shot. Some kind of niche search engine? Again, mobile users will be there.

And when they are, what do they see? A fully packed 500k page? Scrollbars both on the right and on the bottom? Pictures? Or rather a simple page with limited information but delivering content fast.

News? Headers are enough in most cases. You won’t find many amateurs of complex reports read on mobile phone out there. On-line game? You should go for basic operations, possibly those users have to execute very timely. Search engine? Easy access to search box and light-weight easy-to-scroll result list. No pictures please. Content has to be adjusted to the device it is accessed from.

And another thing, probably even more important. Navigation. Forget mouse steering. Forget even keyboard-driven approach. Now you have 12 buttons to rule them all. Entering accounts and passwords becomes a pain in the ass. Standard shortcuts are useless as you neither have Ctrl nor O (to open something in that example). Positioning and order of links becomes crucial part of your design. The world of 320x396 display and 12-key keyboard is just different.

I think the most interesting case we have above is on-line gaming. There are a lot of games now, which base not on World of Warcraft or Second Life model (thick client and on-line world somewhere there), but can be accessed from a web browser as a client. Usually the key thing there is coordination of actions you do. E.g. the match is played every day at 6 pm or you have turn every day to build something in your empire or your character’s action points regenerates slowly over time etc.

I’ve heard stories about people setting up their alarms on 3 am just to gain some advantage over other players or asking their friends to perform some action when they couldn’t be on-line. With easy interface on your mobile users can play everywhere and always. The only prerequisite is usability of mobile app. Users can’t spend half an hour for an action they’d complete in a minute while using “adult” browser.

If I was creating an on-line game now I would start from mobile interface and then go into classic browser.

Usability is Made of Small Things

How usability is made? It is made of small things. Think about scenarios your users will use. Then improve them one after another. Think in categories of:

• ambiguity of operation

• clear messages shown to user

• speed of operation

• number of clicks needed to complete a operation

• possibility to work without a mouse

That’s not a rocket science. What more, thinking about small things, you can improve the application step by step. That’s completely different scenario than with for example performance improvements, where you often need to redesign big chunks of architecture to move out from a dead end. Usability improvements can be done easy in your next development cycle. Almost all you need is enough will.

The reason of all that evangelization lays in a list of usability issues I experienced lately.

• Error messages in Facebook. That’s so easy – hide your SQL messages, they tell nothing to most of your clients, they confuse users, they look unprofessional and they give out information about structure of your database, database engine etc. Give one of those funny error messages instead. Unfortunately, Facebook crew has still this step on the roadmap. Sin: unclear messages.

• Synchronization with Windows Mobile. I wanted to copy some music to my Windows-based Samsung i600 phone from the notebook. Should be easy: Ctrl+C, Ctrl+V, issue resolved, case closed. No so fast. ActiveSync which works as a middleman here can possibly want to make some encoding here, that’s why copying is so darn slow. First time I used it I thought the progress bar shows progress of copying the whole album. Shit happens – it was a progress of copying a single song... As a bonus the application you’re copying files from freezes until the process is completed. Sin: speed of operation.

• Playing music on Windows Mobile. OK, I’ve uploaded mp3s to the phone. I’ve started Media Player and found none of new music there. Ops, forgot to use the update library option (as it couldn’t be done automatically during synchronization). I’ve updated library and all music was gone. Ah, forgot to switch back default source for library from my device to storage card (as if it couldn’t remember how it was set before updating the library). And than finally I could start to listen to my music. Thank you Mighty Microsoft for your generosity. Sins: ambiguous operations and number of clicks.

• Setting up an internet connection via mobile phone. You want to connect to the Internet from your laptop through GPRS/EDGE/UMTS/HSDPA/whatever connection of your mobile phone. You configure the connection and finally you have to type “number” which will be called every time you connect. I mean some cryptic chars like “*99#” which I virtually never remember. Sure, you do it once, until you’ll be forced to repave your machine, but even then it should be darn easy as mobile operators charge you for using the service (and flat rates still aren’t as obvious as you’d think). Sin: ambiguous operation.

• Logging into ticket reservation application. I travel a lot between Krakow and Warsaw. Almost always by train. I’m not sure how it looks like in your country but here in Poland we still need a ticket, as Poland isn’t so wealthy to sponsor free train rides (at least not for me). Anyway, I use Polish Railways on-line application to buy tickets at least once a week. I could write about its (lack of) usability for hours but for now just one simple thing. Every time I log into the application I have to confirm I agree with the terms of use. No information if something has been changed or not, just “confirm, don’t ask” approach. As you can guess the terms of use is quite a long document (16 pages actually). As I can guess no one is reading it every time (and most of users don't read even once). If you see any reason to leave that feature there, tell me please. I see none. Sins: number of clicks, lack of thinking.

• Navigation in Google Docs. A couple of days ago I was working with Google Docs, editing very simple document. As you write text you probably use the keyboard unless you can steer the computer using mind powers only. When you want to mark the whole paragraph you don’t want to switch to the mouse and than back to the keyboard. In Google Docs you have to, because Ctrl+Shift+Arrow combination doesn’t work. And that’s not a sophisticated advanced operation – just everyday bread of word processor user. Sin: no-mouse navigation.

Every of those issues could be resolved in a very simple way. Neither of them requires much development or testing. On the other hand fixing any of them would improve user experience. You just need to think for a moment and have a bit of will to change them. Nothing more. Usability is made of small things.

404 Error Handling

If you have a website it will happen. Someone will make a typo in the address. You will change pages addresses and old one will become outdated. People will just try to enter the page which isn’t there.

Will they see that?


Or maybe you’ve made some effort to keep them stick to your website for at least a bit longer. You ccould try to make the 404-page a starting point like on ProBlogger. Or you could redirect those requests on simple error page and than to main page like we do in on Overto site (sorry for Polish language, but it is Polish site). There’s an option to make a simple redirection to main page with no message in the middle. OK, there are heckuva lot of options and every one is better than leaving simple “no page, bagger off” message. Of course as far as you don’t want your users to bagger off.

Screwed Software Upgrades Saga, Episode 152

Haven’t I mentioned I love web-based software? Yes, I have. Haven’t I mentioned upgrades of web applications are smooth and easy? Yes, I have. Haven’t I ranted about those screwed software upgrades examples? Yes, I have.

Ops, they did it again.

I really like Google Reader. Now, with powerful combo of standard version on steroids (actually on Google Gears) and mobile version it’s complete and I don’t even consider moving to another platform. They upgrade versions seamlessly, nothing you need to do. They add those little features, you know, those which look tiny, but save you a lot of time and make you thinking they were on board since The Big Bang. Like that little dropdown which allows you to attach a newly added rss channel to one of groups you use. So simple. So useful. A masterpiece.

And then, they just take it out. It’s gone. It’s just not there any more.

Yes, I know, they’ve just added dozens of new features. Actually I use none of them. I don’t care. The thing I care is they’ve taken one of those several functions I use. OK, I understand someone can overlook a bug and software is shipped with one, but they’ve cut out whole functionality. It looks like no one tried to add a blog to Reader’s list during testing period (yes, I know I exaggerate, but it was my feature, my preciousss).

Lesson learned is simple – taking upgrades away from users makes it easier (well-known and controlled environment, limited backward compatibility issues) but also raise expectations. You can’t upgrade only those 95% of users who won’t be frustrated allowing the rest to keep an old version. Every forgotten feature becomes a pain in the ass, as soon you have to face negative buzz from unhappy clients and you spend time on boring quick patch instead of adding more new cool features. Paradoxically the more easy it is, the more careful you have to be.

How to Make Users Happy

Most software vendors struggle to make their software better. We add functionalities, we improve performance, we fix bugs. We follow strategic vision which tells us where our application sucks... I mean is very good but should be pushed closer to perfection. Unfortunately it is the vision which sucks so often because we focus on wrong areas.

Yes, new features make sales easier but they rarely make users happy. Generalizing a bit, most users don’t use the most new features delivered in a new version. Users follow their old, well-known paths. If you want to make users happy you should track those paths to see where they can be improved.

I see many examples how it is screwed up these days. When I shoot at Google Docs or OpenProj it is because my frustration grows when I try to follow the most basic, yet the most frequently used, tasks delivered by the software. And while I like both I still come back to their old-school Redmond-based alternatives.

Similar situation I found today with MindMeister. It is web-based mind-mapper. Probably the nicest-looking web-based business software I’ve seen so far. It looks nice, is free (for basic features) and delivers functionality you need from that kind of software. Nothing more I could have expected. Except of doing the basic things right. The frustration can appear quite fast when you can’t delete a node in a mind-map or change connections between nodes, no matter how hard you try. These are the most often used features. They should work. OK, they work. Most of the time. Actually they work 99% of the time. But that’s not enough.

Although I use mind-mappers rather rarely I like MindMeister much. It’s a piece of well done work. Unfortunately small issues affect a bit that nice picture. They are small but happen in the area where they should not. The one which is the most frequently used.

That’s just another example that when you want to make your users happy (or happier) you should adjust your vision to include the work on the things which your users use the most often. With complex application the quality and usability can differ depending on areas/functions/modules we consider. Focus on those which make your users frustrated with everyday use and fix them. That won’t bring you direct sales (as new features would) but content user will spread the word.

And the good user is the happy one.

Which Features Are Important?

Several days ago I had a quite insightful discussion about software functionality and usability. Among others we went through Google Spreadsheets and features which should be on the top priorities in a team working on that project.

Maybe I’m a bit controversial here, but I think Google Docs are in the point where there’s a lot of toilsome and dull work ahead. The thing which should be improved now is generally an editing area. I don’t say it doesn’t work. On the very basic level it works well. However, quite a few of us use the very basic features only. When asked, no one would really answer consciously which “advanced editing features” he uses, but after a couple of hours of playing with the application most of us will find a series of small but annoying flaws. These are non-standard features we use.

Highlight B2 and C5 cells. Only those two. Mark a group of numbers to quickly check their sum on a status bar. Change text or background color of cells with only one click. Mark several columns with shift+left-click. Make some simple formula using keyboard, e.g. type “=sum(“ and move to cells you want to sum using arrows. Doesn’t work.

Yawn. Boring. Nothing about on-line collaboration. Nothing about Google Gears (although I believe that’s another extremely important area). Nothing about adding advanced cool features like pivot table. But all that boring work is something what disheartens users when it isn’t done properly. Typical user who tries out Google Spreadsheet is the one who is familiar with Microsoft Office. The one who is familiar with ways she uses Microsoft Office, to be exact. As far as she doesn’t find similar (and working) paths in new spreadsheet she won’t be happy with it. And she won’t stick with it as a consequence.

Yes, when you’re able to keep the user and show him your unique features (collaboration in that case) and make him thinking about them as key functionalities – you’ve won. Unfortunately in most cases you won’t reach that point because few stages earlier the user becomes annoyed with the new software and goes back to old, well-known Microsoft Office telling all his friends: “Oh, that was cool, but sooo immature.”

By the way, similar problem we face in Overto. After first stage of rapid development we have on one hand a bunch of great ideas how to expand the service with new functionalities, but on the other there’s a lot of work to do within the basics: availability, performance and usability. With heavy heart I choose the latter.

Is the Quality Important?

-We’ve made quite a big effort to improve quality of our services during the first half of the year.

- I don’t believe that improving current quality of services can leverage on wining new deals.

- We wouldn’t have had a chance to renegotiate our support agreement unless we had improved the quality.

- Although your approach is nice, customers are never willing to pay real money for that.

- We wouldn’t have won the new deal without references and we wouldn’t have got references without very good opinion about last implementation. That’s real money.

- I don’t consider that as essential in the deal you’re talking about. And I repeat that my experience shows that customers won’t pay for quality improvement.

- I definitely don’t agree with you, but that’s the discussion for different meeting.

What’s your approach?

Our Customer Is Wrong

“I don’t understand our customer. They want us to make the interface like that. But that’s far from optimal design.”

“I guess they have some reasons to do it like that.”

“It’s completely unintuitive that way. Look you have to choose from several hundreds of options from drop-down until you can go further. They said they want it exactly the same like in the legacy system.”

“Um... As far as I know their end-users aren’t very fluent with using a computer. Maybe they followed exactly the same scenario for years by now and it would be hard to retrain them, even if the new one is better. I guess, that can be why the customer doesn’t want any changes here.”

“You know, that can be a reason. I haven’t considered it that way.”

Look broader. Accept you can be mistaken. Trust in knowledge of your customer. Customer is (almost) always right.

Customer Is Always Right

Several days ago I was involved in discussion about ways of reacting when a customer wants us to do something what we believe is wrong. Should I rather agree to whatever customer wants with no objection? Or should I go and try to force my point of view, because I know it’s better? Maybe I should even reject to work in the project when the customer insists he’s right, as one of commentators advised?

My approach is simple:

1. Customer is always right.

2. When customer isn’t right, see point 1.

Of course, I don’t say one shouldn’t discuss with the customer. I don’t advice to hide your point of view. When the guy on the other end of the table is willing to look for the best solution with you, fine – show what you think is the best solution.

We’re not living in a perfect world, so you’ll sooner or later find yourself in a situation where the customer won’t discuss with you about best idea. He knows better what are his needs. It won’t be very rare that you’ll find his concepts very far from what you’d like to do. Then, it’s time to use the rule number two.

Sure, that way you can end up rewriting some parts of the code, just after implementing the first approach. Sure, that way you can have much less fun with the work. But, remind me, who pays for that? This dumb guy on the other side of the table? He pays, he expects, I guess.

If you think the customer may be making a mistake with design decision and doesn’t want to discuss that – don’t moan. Go protect yourself. Get some formal acceptance for that to have some ammo for later discussions (if needed). Sign detailed scope of the project to avoid changing it later for free. And get back to work.

There’s one thing more. We’re very quick with saying that we’re right and the customer is wrong. Unfortunately it’s not always the truth. Quite often it’s completely different. The customer usually knows better his end-users and scenarios they follow. The customer knows all the problems with the legacy application. The customer knows goals he wants to achieve with buying a new piece of software. We’re in exactly the same situation except we just think we know all of that.

Remember that next time when you disagree with your client.

Naivety of the Web

I have a friend with whom we use to discuss different areas of technology world. Last time it happened to be the web. One of great insights I learned from the discussion was:

“The web is naive. In mid-nineties, with viruses and spam, the web learned that there are actually bad people there, who don’t share high ideas of the founders of the web. Around year 2000, with the crash of the internet bubble, the web learned that businesses should bring profits. Now, with hype on the social networks, the web learned that communities are important. Wow. Great lessons. Average people from medieval village have known all of that.”

Wow. I mean I’m impressed how naive the web is. When I try to guess what will be next I think it’ll be belief that the web software have to by crappy. We accept websites which look like a vomit. We accept websites with very offensive adverts. Popup windows are already the past, but we still see lots and lots of sites where it’s hard to find content among the ads. We accept buggy web software because “we know that it’s only software, so it has to have bugs.” And at last we accept unintuitive, poorly designed, user-unfriendly software which should bring a lot of frustration, but in some way we don’t care, because we don’t know that there’s an alternative.

My guess is that usability is the next naive thing that the web will learn. In vast majority of cases people choose things which are easier to use. It’s because people are lazy. People don’t want to wash the dishes, so they buy dishwasher. People don’t want to bother where the nearest telephone booth is and when someone could call them, so they replace fixed lines with cell phones. People don’t have the time to shop so they buy in eBay or Amazon. The list is countless. But wait, I can hear you saying: “hey, it’s not about usability.” Oh, really?

Couples mentioned above have major differences, but it works everywhere. People actually pay for features like cup holders or reading lights when buying a car. Guess what would happen if those options were for free – everyone would take them. While buying a mouse people check how it lays in the hand. They think how comfortable it’ll be in use. Even when people buy clothes they look not only on fashion but also on usefulness. Given two shirts looking similarly and with no big difference in price, the usability will be a deal-maker. People are using fingerprint sensors instead of typing passwords. This list is countless too.

However with the web, generally with the software, things look a bit different. It is expected that almost no one will look at usability. We’re forced to click 3 times where it would be enough to click once. We’re forced to copy and paste where it would be so natural just to pass the information automatically between two windows. We’re forced to use a mouse where keyboard would be faster. Why? I have no answer here.

Usability is already (slowly) waking up. There are some sites where it’s as important as design (equivalent of fashion in clothes). If the website looks sexy but works crappy, it’ll be hard to earn loyal users there. I believe that in a few years we’ll see hype on highly-usable sites, probably aggregating data from different services we use now. They’ll be focused on delivering user interface, which can be used effectively at 3 am, just a second after being awoken from a deep sleep. The web levels others factors like availability (you can access the internet from anywhere), price (with the web market is global) or even design (which can easily be copied). And having anything else equal people will migrate to the “usable world.”

Sounds obvious, but with the naivety of the web I still think it’ll take some time to have it implemented.

Looking For Feedback

I always appreciate when support teams take an effort to actually search for feedback for themselves, not waiting in their entrenchments until they’re called by a customer. Usually a pissed off customer. That’s the rule that we are willing to do something more likely when we are angry. When we’re happy it’s all OK in our comfort zone and there's no need to take any action.

I praised the Google Reader team for looking for feedback and as they write it’s just their policy. I know that the post is two weeks old but it’s worth citing anyway:

“The Google Reader team tries to read all the feedback that gets posted on blogs, and has also been known to reply in comments. This is a great way for us to get a feel for what's important to you, so keep writing up your thoughts and feature suggestions.”

That’s just so easy. No need to do hard core, deep research. Just waiting for Google Alerts (I guess) and writing a couple of warm sentences, thanking for feedback no matter if it’s positive or negative. Feedback is always good. Feedback is something that forces you to move, to react. Now, when all things are moving to the web, when blogs became so influential that Microsoft sends free laptops to top bloggers just to get some reviews, you sometimes need to move from your comfort zone of support inbox and check what people say about you.

That’s not true in every case – when you work for carriers, well, you don’t expect that their middle management write blogs. However, when you address your product to wider market, especially when plain internet users are your target group, don’t hide in the abyss of the standard support channels.

Google Alerts is a great tool for you in this area. Google Reader team use it. Marc O’Brien, the CEO of Projity contacted me just few hours after my post about Project-ON-Demand was published, only because he was alerted that someone had written about his company's product. That’s what I call a great user experience. When support teams care not only about feedback they’ve received, but also about feedback they haven’t received. The only thing which is essential here is the will. If you’re willing to go out from your support channels shelter, the rest is simple (and free of charge).

User Feedback

Google Analytics is definitely far from perfection, like probably vast majority of Google portfolio at the moment. Analytics team is willing to improve their product (no surprise so far), but they also choose to show it. It sounds obvious, but it isn’t. How often, after contacting with support, you receive that kind of e-mail:

“We are committed to your success with Google Analytics and we always aim
to provide you with a great support experience.
Please help us further improve our service by answering six brief
questions via the link below.
(…)
Your thoughts will directly contribute to improvements in our support.
We thank you for your time.”

Organizations surprisingly often either don’t care about their support quality or assume it is good or don’t take any effort to check. I don’t say that having a poll is the best way to achieve that, but I have to admit that I’m convinced that Analytics team cares. They care about their product; they care about their support quality. I feel quite safe as a user.

When I was working in Comarch one of our support centers had a simple mechanism allowing users to rate their satisfaction of received service by choosing any number from 1 to 9 on their phones after a call. As you can guess it didn’t work very well because there weren’t many grades other than 9 or 1, but still it was the way of showing people that the team cares about their feedback.

Another way was chosen by Google Reader team. They’re crawling through the web looking for bloggers spreading opinions about their product, leaving comments and digging for user feedback. To be honest I haven’t posted my opinions on forums, neither have I tried to contact their support, but they found my rants, fixed bugs I pointed and left some comments showing they care. I’m sure I wasn’t the only one who complained but it doesn’t matter here.

How to act when you have only a couple of customers? It’s even easier. Go to them and ask. Develop a good relationship with the maintenance team on the customer’s side and you can be pretty sure you’ll hear about your performance and about customer’s satisfaction soon. It’s also easier to manage the support team when you have to focus on several customers only, because you can allow having much more direct contacts with them.

No matter which method you prefer, choose one, go out and meet your users, whoever they are. You’ll get feedback about your work as a support and about your product. And one thing more, receiving some positive opinions about your work can be really reinforcing.