In many situations, a usability expert is required to conduct a usability expert review of a software application that runs in an application domain unknown to him. Is the unfamiliarity with the domain really a reason for declining a usability review? Or in other words, is the expert constricted to provide valuable usability advice only in contexts of use he does widely know?
I argue that the fundamentals of usability engineering abstract from the underlying application domain and provide methods and tools that allow the assessment of usability quality independently from previous knowledge. And, would you really favour the usability engineer with a low methodological profile, but very specific and deep domain know-how over the one with decades of experience, but no experience in the very special domain? Or in other words, is it the surface or the preserves you care about the most?
I have seen representatives of both types and I will always prefer to have the method-guru on the team. If he has a profound background, he will get into the domain easily anyway. Moreover, I have experienced the huge benefits of cross-domain knowledge transfer several times by myself and I consider it as being much more important than biased in-domain knowledge.
In my opinion, the misleading tight coupling of usability expertise and domain knowledge therefore is ill-conceived. As a wide spread phenomenon, it is caused by the marketing materials found on the websites of many usability consulting companies. Some try to compete with others by making domain knowledge the driver of valuable usability work. Many consulting companies state, that the expert must have a certain experience in the specific application domain in order to do the expert review seriously.
This is absurd – especially because usability engineers are usually particularly trained in accessing different domains and moderating between the disciplines.
Where does the nonsense come from? Typically, companies provide a clearly laid out set of different usability services for diverse problems. Because some specific terms, among them the “expert review”, have gained increased popularity, other related techniques do practically no longer exist. Therefore, the term is used to represent usability testing techniques that are rather slight or small-weight and which do neither require extensive preparation nor use involvement. On the other side of the spectrum there is the formal usability test, which requires a development of test cases, the testing environment (lab) and the analysis of the recorded findings. In between: methodological desert.
So, can you explain who kidnapped – for example – well-established walkthrough techniques? Besides one to several experts on the review team, a domain expert from the client-side can participate in the analysis and guide the usability people through the main application scenarios and provide important domain information on the fly. There is absolutely no argument against an expert review just because the usability expert does not have domain specific knowledge. Therefore, the expert review can be applied in well known domains as well as in unknown environments, with the conquerable variation that somebody with domain knowledge (but no usability expertise) joins the review team during the analysis is conducted.
Naturally, people interested in usability advice should not be overwhelmed by too many different kinds of methods. No consulting company wants to strike its clients with dozens of explanations and definitions. And, the celebrity of some usability methods significantly helped in transporting user-centred design into the heads of decision makers. But the tendency to associate wrong statements with a small sub-set of techniques is equally misleading. As companies promote hard prerequisites such as domain knowledge, they educate clients in a way that contradicts the nature of usability as a discipline. The focus on just a small subset of usability techniques thwarts the efforts of many sapient usability people who developed a bouquet of usability techniques to take varying initial situations into account.
As a usability mentor, I try to rather point out to the adaptability of a certain test setting depending on the application domain. This also provides the chance of underlining usability competency instead of narrowing the discipline to a few hyped terms. Naturally, you can only promote diversified method competence if you actually have got some – otherwise, you need to continue to sell expert reviews doped with domain knowledge.
User Interface Design and Specification
Usability Architecture - From Models To Surface
Thomas Memmel`s Blog on Usability and User Experience
About Me
Labels
- Agile + Usability (4)
- Costs (1)
- Discussion (4)
- eBusiness (1)
- eCommerce (1)
- Information Architecture (1)
- Inspector (1)
- Interaction-Design.org Encyclopedia (1)
- Interview (2)
- IREB (1)
- Job description (2)
- Job profiles (2)
- Method (2)
- News (2)
- Nomenclature (1)
- Publication (5)
- Requirements Engineering (1)
- South East Asia (1)
- Tools (2)
- UI Prototyping (2)
- UI specification practice (6)
- Usability (4)
- Usability ROI (2)
- User Experience (2)
- Video (1)
Blog Archive
-
▼
2009
(23)
-
▼
June
(9)
- Interaction-Design.org Encyclopedia: Information A...
- Domain knowledge vs. usability skill set – the met...
- Providing Requirements Engineering Training in Kua...
- UX, Information Architecture and Agile Development...
- Prototypes as UI specification
- Who am I? From interface designers to usability ar...
- Usability Engineering Return-on-Invest
- User Interface Specification - From Models To UI D...
- eBusiness: How to argue usability investments to y...
-
▼
June
(9)
Copyright 2009 The Usability Architect
Imprint: Thomas Memmel, Zurich, Switzerland - memmelatacmdotorg

0 comments:
Post a Comment