As Jeff Atwood reminds us, the ultimate metric of developer success is the number of users our products. Building software that people actually want to use involves creating an enjoyable experience from the first minute they encounter your brand to the minute they power down.
It got me wondering, what are a couple of low cost (both in money and time) ideas/techniques/methods that a small software shop can use to better consider user experience design during product development?
I would say the hallway usability test is both effective and cheap:
Grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.
What I have done in the past was develop the UI to the best of my ability looking at
Then once I had something working, I would sit down with a fresh user, who has never seen the product, and just observe them as they used it and made notes of how they interpreted the interface and how they interacted with it.
One low cost method is using a site like http://usertesting.com. It's relatively cheap and it enables you to do quick and easy hallway testing.
In our case it was even easier than to actually go out and find people in the hallway!
Paper prototyping is a great way of interating the design before commiting code or even pixels. It's more than just a drawing on paper see Papper Prototyping (the book), it a methodolgy for low cost prototyping. I tried this on a project a while ago and it really really helped. Any prototype that gives you something you can run though with a user and get feedback on will really help. see also http://en.wikipedia.org/wiki/Paper_prototyping. EDIT ( of course you need to grab a person to test on that doesn't know about your app and is something like one of your users. If domain expertise is needed to use the app then you'll need a user who has that. If you're a making an app for Spear Fishermen then you'll probably need to get hold of one to test with )
This will depend on what languages you are using for development, but with a UI design tool like Expression Blend you can develop a UI shell quite quickly (in this case in WPF or Silverlight). You should be able to do the same in your technology of choice. Just implement enough code behind to be able to navigate the UI.
This can then be used as though it were the real system, by yourselves or any customers you want to show it to. This will get you actual usage information.
Be careful though, don't make the UI look too slick or you run the danger of people thinking your application is functional when it clearly isn't.
If the prototype/mockup doesn't work you've not spent a great deal of time on it, but if it works then you can change it to production code relatively easily by adding the real code behind and updating the styles.
What are you looking to identify? How useful your product is to customers? How usable it is? How attractive it is?
Products are generally successful because they either provide a new capability that people need, or they are sexier than the existing solutions. Do you know what your customers' problems are? Do you know how to solve them? Do you know what they find sexy?
Ask them: You should include users at almost every stage of development--most importantly, you should include them before you start building anything. Market research, sure, but also go and talk to your users, whoever they are, and watch them do their tasks. Work with them using low-fidelity prototypes like whiteboards and pieces of paper, and see where you could improve their workflow. Show them mockups and have them try to do their tasks using the mockups.
I'm going to guess it's too late for this sort of user-driven development. If it is, go look at Guerrilla HCI methods on tips to running a very-small-scale usability test. Even having two users sit down and look at a piece of paper--with the rest of the development team watching from behind glass, or watching a video tape of the experience--can be very revealeing. And bringing in 2 people isn't that expensive; you'd be surprised at how motivating $100 is for 2 hours work (and what is $200 in the total cost of your project?!).
User surrogates can also be used if you absolutely can't get real users. But use them with caution. These are people who have studied how your users work, but might not have the day-to-day, minute-to-minute knowledge to really see if your solution works.
Sorry, Jeff sounds quite reasonable to the rational mind (or as Alan Cooper would call them, homo logicus), but basing developer success on how many people use the software is no better that measuring programmer success by lines of code.
While a company needs sales to succeed--and Jeff is partially right when he suggests that ideas worked on that do not ultimately result in sales allow a development team to merely founder in a sea of ideas (yet look how well the model has worked at places such as Google)--a much better metric is user happiness.
Why? How many times have you encountered, have you read about, people who have no choice in the software they use? Whether through massive marketing campaigns (Windows Vista) or corporate fiat, hundreds, thousands, even millions or people are locked in to using certain software. Does that make it good by mere numbers?
That said, along with some of the ideas already suggested, you may be able to go to where your users do their work. See what they do repeatedly. See what they do occasionally. See what makes them frustrated. See what delights them. When you begin to understand user needs, you start to get the idea about what in a UI will work and what won't. Many companies have never considered the idea that ethnographic research is not only a part of the usability lifecycle, it's often one of the most important parts.
For example, you might not think that figuring out how to make a small task take two clicks instead of three is a productive use of resources--until you see that your users do that small tasks dozens of times a day, every day.
You also don't need a "formal" usability lab to conduct usability testing. I've done usability testing in empty cubicles in a quiet part of the building, with monitors sitting quietly in the cubicle next door.
One good idea is not to actually create your UI design ideas in the code that you will also use for development. Use anything else, from graphics programs to paper and pencil. Too often you'll find a mindset that once you've expended resources to write code to do something, it's wasteful to throw it away. Create your ideas in an environment and with a medium where you find it easy to discard ideas that do not work.
Finally, consider the idea of personas. Alan Cooper outlines their usefulness well in his excellent book "The Inmates Are Running the Asylum," but the idea is expanded on well in the book "The Persona Lifecycle." Another good book that can give you good ideas on how to incorporate and integrate usability into the development process is "Interaction Design: Beyond Human-Computer Interaction." (Advance warning: the latter two fit more into the textbook style of books and are not easy, breezy reads, but they contain not only tons of useful information, but many, many useful references.)
For an existing product, nothing beats spending an entire day just watching actual users. You have to spend a long time with each user to get past the "somebody is watching me" phase where their actions aren't natural though.
For new product, watching what they use now (if anything) is also revealing as well as talking to them.
Whatever you do, do NOT just talk to the managers of the users. You will not get all the detail you need to develop the application. Managers are big picture guys, they really don't see what their employees have to go through to do the job right now.
Paper prototying is also good for new features. Observe things like where do they look for the new feature, likely that isn't the spot you would have put it into. Ask questions about how often the tasks are done. If they have paper inputs that they do data entry from, get copies and look at the order things are in. If the form they do data entry from says last name, first name, then don't make the data entry say first name, last name unless you want a lot of bad data.
The first step for developers (like me) might be a mindset change. This is needed for listening the user critics to our beloved UI without starting an argument. Acting as a usability type I got really aggressive responses from developers, especially from the juniors, when I pointed to UI issues. Ideally avoid talking to the user. To do Konaminman's "Hallway test" get a user, give her a task, and silently observe her struggle. Refrain from helping or shedding instructions! If the test user gives feedback don't argue: if she was in trouble then there are problems, by sure. Make the UI simpler to fix the troubled steps and try again, with another user. Trough this process you build knowledge so that your next UI will not have these exact issues.
About test user's comments, do what they need but not what they say. Many users will suggest a change they think that might solve their issues. It is unsafe to follow these suggestions (unless the user is The Boss).
I like Chuck Martin's answer. Going to where the users do their work is what I always did, and doing so I learned a lot. It might not be practical when the users are not reachable. For these cases we build "Personas", synthetic users used to validate interaction designs.