Reporting website usability flaws
I’m becoming increasingly aware of usability flaws, as time goes by. I’m a professional web application developer, and tend to work on the presentation layer most of the time, so it makes sense that I pay close attention to user interfaces. I wouldn’t call myself an expert on the subject, but it is something I’m very interested in/passionate about.
But, it’s becoming more of a curse, kind of like the way typos jump out and punch me in the nose, whenever I encounter them. Actually, it’s very much like that. When I run across confusing instructions, misleading button labels, dead ends (pages that don’t include any navigation controls to get back to where I need to be), or any other UI elements that don’t make sense to me, I want to fix them!
Unlike typos, though, I feel like I have a better chance of enacting a change by reporting usability flaws, so I’d like to start emailing companies’ customer service/tech support teams about this kind of stuff.
This requires several steps, though:
- track down the correct people to contact (may or may not be trivial… depends on the site)
- write up descriptions of the issues, in a way that the recipients will be able to understand (optionally may involve screenshots, URLs, steps to reproduce, etc)
- suggest potential solutions/improvements (optional)
As this seems like an awful lot of unpaid time/labor, I think I’m going to start by posting some of this stuff here, on this blog, so I will have it handy if/when I’m ready to deal with the companies directly. That way, I can just post a few quick notes/screenshots immediately, and can deal with some of the details later, if I feel like dealing with it. Unless it’s something I encounter repeatedly, or something that’s really easy to explain, I’m not sure how often I’ll actually follow through. But many companies keep tabs on the blogosphere, so there’s a slight chance they’ll run across it without me having to actually tell them directly. That would be ideal!
An added benefit of posting these things here is that other people (like you!) will be able to comment on them, and perform a bit of sanity checking for me. You can tell me if I’m overreacting, or missing something obvious. Or, you can chime in and say “I’ve run into that, too, and it bugs the heck out of me!” Or maybe it’s a common gripe, and you know of a GreaseMonkey script that addresses the problem. In any case, comments are always welcome!
subscribe to entries feed
July 11th, 2007 at 2:30 pm
I think SOME of this is inconsequential for YOU/ME. Can’t navigate back? We all know where the back button is. If it’s YOUR site you should care, but if it’s not.. It’s just free labor, as you mentioned…. Let their site suck; you will just look like that much better of a developer in comparison! :)
July 12th, 2007 at 9:02 am
@ClintJCL: The trouble with the back button is that some sites choke when you use it. On those sites, you need to use the navigation controls they provide on the page.
I’ve encountered some that will send you back to either the login page or the landing page where you started out after logging in. Often, this also means that any data in whatever multi-step process you were involved in, when you were naughty and used your own browser’s back button, gets thrown away.
Sometimes, the very reason I clicked my back button is because their multi-step process didn’t provide adequate means to go back and correct something on a previous step.
I’ve dealt with more than my fair share of back button issues in a few of the web applications I’ve worked on, over the years. I know how hard it can be to balance session state management with the possibility of users opening multiple browser windows sharing the same session, and things like that.
In at least one of these webapps, we ended up changing all the ‘Back’ buttons that we provided on the web pages into ‘javascript:history.go(-1)’ links, because then we only had to worry about one type of backward navigation, and we would not have to worry about browser back buttons screwing things up.
Also, if a user clicks a browser back button (or menu, etc.) such that a dropdown list of the recently navigated pages appears, they could go back (for example) 3 pages at a time, so we had to also code things so the app wouldn’t choke on this sort of navigation.
Of course, no single navigation mechanism is ideal for all webapps, as different app servers / programming languages / frameworks / 3rd-party APIs, etc. all have their own constraints and idiosyncrasies. It also depends on what type of data is being manipulated by users, whether multiple users can edit the same pieces of data, etc.
My point is that if a webapp is going to restrict users to only using the navigation controls provided on the web pages, then they need to *always* provide navigation controls on *every* page.
I do kinda like your thinking though, about how if other sites suck, then mine will look better. :)