March 21, 2008

Warning: Third-party Usability is Bad for your Health

3rd_party_usability There is a huge problem in the software and web services industry: 3rd party applications, widgets, dashboards or site add-ons can kill your usability efforts.

Poor user experiences with 3rd-party applications can undermine or make your usability efforts look bad. 

Vendors such as PeopleSoft, Vignette and many others are notorious for providing "clunk-ware", "vapor-ware" or "sneaker-ware" as one of our clients at Experience Dynamics put it.   

Let's explore why this is a major problem that you need to confront head on, or be a victim of 3rd-party usability issues.

First, a 3rd-party application, content feature or widget is something that adds-value to your site and potentially to the user experience. It might be an entire account management dashboard, content management system, a 3D model of the human body, a mortgage calculator, a job board or a web service like an ecommerce shopping cart or secure service solution.

Configuration Nutritional Deficiency

In my article "Configuration Hell" I discussed how users don't do configuration behavior very well. In the case of software vendors, they provide already pre-configured applications or web services. In many cases software is developed fully loaded with features, and configuration entails "turning off" nonsensical screen elements and elements of functionality.

Open source software suffers from the same lack of understanding of defaults; poor or badly organized content and features; functionality lacking a task-oriented design.

Software vendors regularly ship products with poor usability, that are poorly configured. Worse, the practice of shipping unusable web applications or web services seems to be a business model.

"Oh, you want us to configure it so it's usable...?"

The idea is that you get a baseline package (largely un-configured) and if you want it to reflect a coherent user experience (like the rest of your site), you will need to pay more.

For me, this business model lacks integrity. Up-selling should be used for adding powerful features, not for gaining access to basic usability. The reality is that most Fortune 1000 companies will typically pay for the baseline product, ending up with a shoddy or inferior user experience.

Another reality of 3rd-party usability is that project, program or product managers are not able to do anything about 'locked down' third-party applications, widgets or re-directs to outside applications.

Herein lies the problem: users don't know when they are entering 3rd-party country. To users, it's all one big swirling experience. Poor user experiences with 3rd-party applications can undermine or make your usability efforts look bad. 

How to minimize third-party usability problems

1. Negotiate for usability standards maintenance when signing agreements.

What many companies are doing is writing usability guarantees into the contracts so that vendors are forced to adhere to your standards before they win the contract. This is the most direct and legally binding way to leverage usability in the vendor relationship and with the solution they deliver. Sound drastic? Many of our clients are doing this, having been burned by third party usability issues year after year.

I encourage the practice, and I think vendors need to recalibrate the business model of selling unusable systems. Offering usability from the get-go is core value, it's not a value-add that you should dangle as a carrot in your customer's face for up-sell purposes.

2. Mandate your usability standards as a necessary requirement to integrating a third-party application.

Vendors often will beta their next release for a negotiated price. Be careful if you choose to be a beta guinea-pig:

A ruined user experience reputation could cost you more in long term customer retention and satisfaction than buying clunky functionality that doesn't work as users expect, and integrates poorly into your development environment, causing you to write countless API's to patch the problems, for example.

3. Work with your vendor over the course of your relationship to encourage usability as a requirement in their development process.

As a customer you have tremendous influence over vendor development directions. Demand usability as a requirement and encourage specific usability enhancements, maybe not in this release, but in next year's for sure.

I don't think it's wise to even ignore usability in your software purchasing evaluation process. Apparently, neither do 70% of software buyers in a recent study by the Sand Hill Group & Neochange (2008) who rate user adoption (usability issue) as more important then features or functionality in software purchasing.

 

Your senior usability lead should be on hand to provide concrete input if not "gut feel" input. If you don't have a senior usability person, hire a usability consultant and have them do an informal or formal usability audit on the intended product. This is a perfect use for usability consulting firms. If you're going to spend money on usability later, why not bake it into your due diligence as one of the risks you need to manage up-front? 

In my ten years of experience with usability consulting, I have heard many attempts to have me evaluate a 3rd party product before purchase- even with an existing client- but somehow that criteria gets overlooked or minimized in importance. Rarely is the usability due diligence conducted. As a result I run into a lot of clients who are "stuck" with 3rd party usability issues.

Demand a change in direction from your software vendors and partners and you'll avoid or greatly minimize the inherited usability problems that often come with 3rd party applications and web services and tools. That way you won't be a victim of 3rd party usability and neither will your users.

Best Wishes,

Frank Spillers, MS

February 23, 2004

Are you hiring what you think you are hiring?

UI-designer.jpg
Part 1:Clarifying skill sets

This User Interface (UI) Designer position correctly states that UI designers create navigation maps, functional specifications and design requirement documents. Hint: They don’t code anything.

Yet a recent polling of my colleagues and clients shows that the common usage of “User Interface” person means someone who does "front end" (interface design) and the "back end" (programming). There are many UI Designers out there who design the usability and they have a background in the area. However, because programming is being conducted simultaneously, many people fall into the “split-mind problem”. It is hard to focus on the user's needs while thinking about the system's needs.

Years ago, before working exclusively in usability, I programmed in C++, C, HTML, Java and some virtual reality and artificial intelligence languages. I can verify that there is a huge mental leap between the "front end" (interface design) and the "back end" (programming). It is extremely difficult to do good usability if your focus is code.

Takeaway: Be careful to clarify your conversations with an agreed definition of UI Design skills. In the usability community, it means the above (see ad). In the programming community it means the job involves code. There is a difference. Make sure you know what you are hiring.

QA-tester.jpg

Part 2: Focusing on strategic insights

Fact: Usability is not Quality Assurance (QA) and can not be performed professionally by a Quality Assurance specialist. Would you have your plumber take care of legal problems?

People who hire “Usability Testers” and QA specialists to handle usability requirements, seem to think usability is purely functional. They, like the authors of the above (second job ad), contribute to a one-sided view of usability, namely that usability is purely a tactical step in good software development.

Usability is actually highly strategic. Design changes can impact: markets pursued, how audience segments are defined, whether marketing and business goals are altered, whether resources need to be allocated to change or add new functionality etc. Compare this to the outcome of QA where fixing a button, moving a link or adding an image might be the result.

Takeaway:If your usability requirements are going to be covered by QA, you may be missing the forest for the trees. Never substitute QA for usability in your web development lifecycle.

Best Wishes,
FS