During my 20 years as a usability consultant with IBM, it was the rare corporate client that was willing to pay for extensive usability testing. Many clients expected that since we were “user interface experts” we would be able to design a great and usable interface in short order. To cope with the resulting time pressure, we developed several methods for rapidly iterating and evaluating user interface designs. Even so, there remained the question: when do you stop iterating? In other words, when is a user interface good enough?
Continue reading “When is a User Interface Good Enough?”Scaling Usability Based on Requirements
When a company such as a bank hires a usability engineering consultant, they usually have a specific problem they are trying to solve. One common problem is that customer-service call centers are too expensive to operate. When it is not practical to build a self-service website for their customers, clients will choose instead to redesign their call center agent workstations to make them more efficient. Sometimes, just reducing the amount of time by a few seconds an agent needs to complete a customer service interaction can save the company hundreds of thousands of dollars. The company may even calculate how much time they need to save on certain high-volume customer service interactions in order to achieve their business goals. That targeted time savings then becomes what we call a usability requirement. Of course a usability requirement can also be defined in terms of the number of errors an agent makes using their workstation to complete an interaction, or even just the number of clicks.
Regardless of what the formal usability requirement may be, the usability engineer needs a way to estimate the likelihood that a proposed user interface design will meet that requirement. In other words, is there a way to scale measured performance in a usability test against some criterion so that it represents the probability of achieving a specific usability requirement?
Continue reading “Scaling Usability Based on Requirements”
Dr Martin Fracker 