Why would I want to?
Why are we writing software ? Because we need, or we like, to solve problems.
I you write software for people to use (as opposed to embedded software, for instance), these problems will only be solved if these people actually succeed in using this software. This is, both surprisingly and annoyingly, incredibly difficult.
Your users are not dumb. They are not as well-trained as you are in using computers. They often will be far superior to you in their field of choice. Don’t underestimate them.
And even if you do underestimate them, or even if your users were actually not-that-smart, so what? Aren’t you writing software for them anyway? You are not your user.
How do I do that?
I urge you to do user testing. It will blow your mind, and might make you rethink your whole software. It doesn’t have to be huge, you just need to put people in front of your software, and watch them use it.
You can begin by asking co-workers that are not as familiar as you are with the product : a secretary, an accountant, a salesperson… If you’re in a building with other companies, you might ask people there. Better yet, if you can, ask real users (or prospective users) to come to your office.
Get in a room with them, get them on a laptop with a mic (most do, these days), install a capture software like BB Flashback Express, run it, then run your software or open your website.
Then, just ask the users to do common tasks. Insert this, edit that. Don’t help them. You might find plenty of help everywhere on how to conduct user testing.
How will it help me?
Listen to their remarks. Probe them for more informations. Don’t necessarily do what they suggest, but think about what problem they encounter, what problem they want to solve with their suggestions, and how you would solve it optimally.
Some examples of recent user comments that have had a tremendous impact on our recent designs :
I think I understand how to resize this block, but why does it display a “hand” cursor instead of an arrow ?
This allowed us to realize that our block resizing was even more awful than we thought, and we redesigned them completely. The blocks had arrows on the corners that allowed the users to resize, and on mouse-over the cursor changed to the “link click” cursor. The common pattern is that the cursor must change to a “double arrow” to resize. We were so used to this anti-pattern that we didn’t even notice it anymore. Now users finally understand how to move and resize blocks !
I think the previous version was more simple to use. I liked the toolbar.
This comment made us realize that our “clever” new design was in fact very confusing. The new design uses contextual panels and buttons in various places to do various actions, it’s kind of pretty, and has a lot of attention to details. The old one was using a single toolbar for all actions, was awfully ugly, with widely inconsistent icons that changed places depending on what you clicked. But users always knew that the actions were there. Now they’re lost, because the action to do X is on the left, Y is on the bottom, and Z is displayed in a contextual panel. It’s only this comment that made me realize why I was uncomfortable when watching users search for some actions: they are actually lost. We might have to rethink our whole design to switch to toolbar-based.
That’s it?
Of course not. It’s very easy to do enhancements with just that, but it won’t allow you to build the best software out there. But there is some help available everywhere.
I personnally started with Steve Krug’s “Don’t make me think” and “Rocket Surgery Made Easy” : they are very concise and to the point. I’d consider them mandatory readings.
There are many great usability blogs out there: try out (in no particular order) Smashing Magazine, UX Magazine, UXMatters, Boxes And Arrows, The UX Booth, UX Movement, Usability Counts, Wireframes Magazine… the list goes on.
I am sure this small start will help you a great deal.