PinPoint Performance Solutions Blog (Legacy Content)

The PinPoint Performance Solutions Blog has moved to a new address.  Please update your bookmarks and RSS feed readers to http://www.pinpointperformance.net/blog

The blog you are viewing now will remain intact for the foreseeable future and house PinPoint Performance Solutions' legacy blog content - posts beginning in November 2006 through October 2008.  After January 1, 2009, PinPoint Performance Solutions will take a slightly new direction in our business approach and our blog where we will focus primarily on workplace performance improvement and training as our core service offerings.  User-centered design and usability will be supporting services and applied when necessary.

The new PinPoint Performance Solutions blog is now integrated with our website and will therefore reflect the new direction of our company in its content.  Thank you for being a supporter of PinPoint Performance Solutions in 2008.  If you have any questions about this change in our service, please contact us.

Usability professionals in the Boise area are in the beginning stages of forming a local Usability Professionals' Association (UPA) chapter.

I had the pleasure of meeting some of these pioneers recently and have volunteered my efforts to help launch the local chapter by coordinating education efforts.  When it is launched, which is only a matter of time, it will play host to a very diverse group of professionals dedicated to improving technology for everyday people and educating the Boise business community on the benefits of usability.

If you are interested in learning more about the local chapter or would like to join, please contact me through the PinPoint Performance Solutions website.  I'll collect all the necessary contact information from interested parties and deliver it to the individuals who are spearheading this effort.

What may be obvious to some is not so clear to others.  Quality assurance and usability testing are not same.

My current project work has placed me in the role of usability test participant rather than usability test moderator or usability test developer.  Much of this has been by choice because I think it is good for usability professionals to take a step back and place themselves in the shoes of the test participant.  There is much to learn from being a test participant.  The knowledge I've gain from being in this current role has created topics for future blog posts, but today I want to talk about one important thing I learned in regards to test methodology - the form of testing implemented plays a role in the kind of test data that is received.

I'm not sure if the folks I'm working with are using different terminology (where they say "usability testing", but they really mean "quality assurance" or vice versa) or if there is confusion over the definition of the two terms.  Quality assurance and usability testing are two completely different forms of testing and by defintion they produce two totally different forms of test data.

It breaks down to this:

• Quality assurance tests the suitability of a product.  In other words, is it ready for use and free of bugs or errors (OK, minimal bugs and errors).
• Usability testing tests the usefulness or performance of a product as it applies to the end-user.

Please note, when I say "products" it can also mean software applications, web applications or websites.

I'm sorry to say that the test I'm participating in is a quality assurance test, not a usability test, despite what the moderators say.  We're running test scripts and tasks to record results, but there is very little study into what the end-user's emotional response is to the application or overall performance related to basic tasks.  We're simply finding bugs and reporting them to the developers to fix.

If you are in the process of setting up your own usability test, be clear about your objectives and the data you want to record.  Do you want to measure the suitability of your product or its usefulness?  The type of test you implement will produce different forms of data which you can act upon.

A reader took me to task on a recent blog post I made where I ranted about how bugs and workarounds shouldn't be acceptable or "a way of life".

Patrick Neeman at Usability Counts made two valid points in his response to my post that resonated with me:

1. Test early and test often
2. We live in a beta test world

These two things, among other strategies, will help mitigate usability issues. 

The best example, currently, of living in a beta test world is Google Chrome.  Companies like Google make no bones about the condition of their applications as they are developing them and preparing them for a final release.  It's clearly in Beta - it even says so on the download page.  I'm even using a beta version of the blogging platform I'm using to write this very post.  Believe me, it's far from perfect.  However, the strategy is to let the users be the testers and give them the opportunity to take a form of ownership in the application's further development.

There's nothing wrong with this strategy and I often encourage it among the people I work with.  My point is if the business conditions allow it, do upfront due diligence to make sure the application you are putting out there has a minimal number of bugs, errors and usability issues.  Having these problems only hurts end user performance, if you are expecting them to use the application right away.  A buggy application only slows people down and keeps them from the work they intend to do leveraging the application.

I appreciate Patrick's feedback and I appreciate his willingness to let me comment to his post.  Lesson learned for me is to not vent and blog at the same time!

Forgive the rant, but I'm speaking from experience.  When it comes to technology in business, I believe do it right or don't do it at all.

Over the years, and especially in recent months, I have encountered many proprietary applications not ready for their debut and falling short of their expectations.  Good intentions are there but the applications rolled out to the end-users with much fanfare, who are expected to use them and leverage them to their advantage in their daily work, fall flat.  Instead of full functionality, speed and efficiency, end-users encounter bugs, slow downs and errors.

Sadly, bugs and inefficiencies in applications get passed off as being acceptable and part of the design, development and deployment process.  It's not fair to make your target audience or end users unknowingly be your beta testers.  They shouldn't have to put up with such frustrations if they are being asked to use what really boils down to be a prototype application to do their work.  They should be able to use the application with minimal or no bugs and it should work the way they expect it to. Applications should support work performance, not be a barrier to work performance.

I understand that it may be nearly impossible to release a flawless application.  However, rather than put the end users through this trouble developers and stakeholders should take the time to conduct user-centered design, do quality assurance and build an objective usability test where beta testers can contribute in a meaningful way to find the bugs that are "show stoppers".

Find he bugs, fix them and release.

In the end when a fully functional, working application free of major bugs is released it will work as intended and boost productivity and performance in the workplace.

The team at Virtual Hosting brought to my attention a recent post they made to their blog on how to improve the usability of your website.

Test your Website: A 57-Point Checklist for Maximum Usability

This impressive list provides links to supporting content on the web that I'm sure will burn up your Delicious bookmarks.

Enjoy!