Software Usability – Resources for Usability Evaluation

I had an interesting discussion with several people this week that I could summarize this way: “How does software get designed and built that no-one can use?” 

“Usability is the combination of fitness for purpose, ease of use, and ease of learning that makes a product effective.” according to the University of Maryland’s Guide to Usability. Not everyone loves software usability testing. It has been jokingly said that if the software was difficult to code, it should be difficult to use. Unenlightened project managers may even think of users as the enemy. Of course, that is not true. Satisfied users are salesmen for your products and champions of future business opportunities.

However, pleasing users can be challenging.  If you are a software or project manager you know what I am talking about.

In a usable product, says, Dan Costenaro, Microsoft Outlook Program Manager, "Anyone can walk up to your piece of software, sit down in front of the computer, and accomplish their goal. If it’s not goal-driven from the user’s perspective, they will never figure it out." I agree.  Dr. Karen McGraw takes this even further, adding that, “If the user interface is not designed to support the user’s mental model—the way they approach their tasks and work—it will take them longer to learn, accept, and effectively use the new system.”

I wholeheartedly support the increasingly sophisticated tools and processes being implemented to evaluate software usability. Some of these are useful during formative testing, when the design is fleshed out, while others are more effective during summative usability testing.  If you are newly converted to the importance of usability testing or a seasoned veteran always interested in more information, here are some of the resources I suggest you investigate.

A good place to begin is Usability Net’s Methods Table  represented in the graphic below. On their website, each cell leads you to articles and more topic information.  It is worth wandering around on this well organized site to get an overview of usability evaluation.




Here are a few more sites with information on usability testing:

Guidelines for Usability Testing with Children
Microsoft UI Guides and Usability Testing
Performance Centered Design white paper
Usability Professionals Association
Practical Usability Testing from Digital Web Magazine
National Institute of Standards Usability Reports
Userview Remote Usability Testing (I have not used this service, so I am not recommending it. However, the ability to “watch” users interact with your applications remotely could be useful in some instances and they have a free trial available.)</p>

So bottom line for a PM:  Ask your development team what steps, processes and tools they are using to ensure that the interface or product is usable by the user.  If you have had some excellent or unpleasant/unsuccessful experiences with usability testing, please share with other PMs in your comments.

10 Project Management Mistakes

Mistakes happen. Bad luck happens. But, when the same mistakes occur over and over again to different PMs on multiple projects, we really should figure out a way to avoid them, but we don’t.  We call this lessons learned in the business – and believe me, it is better to learn from someone else’s mistakes! Although as Douglas Adams tells us in Last Chance to See,

 “Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”

Here are 10 of my favorite PM mistakes. Well favorite is really not the right word because it implies something good—like favorite ice cream flavors. Let me re-phrase: Here are 10 project management mistakes I see frequently.

#1.  Over committing key resources. This relates directly to the discussion of the last three weeks on resource management. But it goes beyond that. There is an element of wishful thinking, too. When bidding contracts and developing schedules, ever-optimistic managers are tempted to decide how long a task requires if the “best-of-the-best” are working on it and the wind holds steady.

#2. Believing that good technologists make good project managers. Project managers need people and leadership skills that are not demanded of the technologist. The problems that PMs are called upon to solve often require working through and influencing others on the team.  I often see a job description for a PM that involves lots of required technical skills and none of the people skills.

#3. Ignoring problems. If the PM doesn’t acknowledge that a problem exists, then he or she is under no obligation to solve it.  We sometimes refer to this as the Ostrich maneuver.  Believe me, problems don’t go away by themselves; they usually get worse with time.

#4. Not communicating with stakeholders. The people who care about the project either because they are funding it, reporting on it, or will be using it need to be informed frequently. “No surprises” is the best credo.

#5. Failing to control problem team members. This is one of the more frequently ignored problems because it can be messy and unpleasant. Whether someone is failing to do their tasks or making life miserable for other team members, the PM needs to acknowledge the problem and deal with it.

#6. Failing to manage risks. The risks to successful project completion come in many guises and sizes. Events such as: The new process management software that no one has been trained to use; Relying on an independent team to get their part of the project done on time; Moving offices or changing requirements and not changing the schedule to accommodate the predictable negative impact.

#7. Decreasing time allocated for testing. When project schedules get into trouble and deadlines are not being met, many project managers decide to cut allocated time for testing and user evaluation at the end of the schedule in order to meet the final delivery date. This is always double trouble – you don’t find the bugs and your users or clients are furious.

#8. Learning from experience. Projects should have post mortems and lessons learned that are documented and shared.  I know there is never time left at the end of the project to do this, so try doing a capture of lessons learned during the project at different intervals.

#9. Not controlling requirements. Requirements creep is ubiquitous. Marketing wants additional features, senior management agrees to new capabilities, and future users ask for more, better or different. The PM must provide these stakeholders with realistic estimates of the consequence to cost and schedule of increasing requirements. And sometimes the PM has to say, “no”.

#10. Believing in saviors and miracles.  To quote Pawel Brodzinski—there is no silver bullet.  Or put another way, “Hope is not a strategy!”


I invite you to add to this list with your favorite project management mistakes. We can all choose to learn from the mistakes of others no matter what Douglas Adams says about the human condition.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site