Interaction-Design.org Encyclopedia: Information Architecture

The Interaction-Design.org Encyclopedia has just published an encyclopedia entry on Information Architecture by Michael Cummings.

See: http://www.interaction-design.org/encyclopedia/information_architecture.html

What is Interaction-Design.org?

Interaction-Design.org is all about making research accessible. We deal with human-centered aspects of technology: Interaction Design, User Experience (UX), Human-Computer Interaction (HCI), Information Architecture (IA), Human Factors, Usability, and related fields.

Domain knowledge vs. usability skill set – the methodological desert in usability marketing material

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.

Providing Requirements Engineering Training in Kuala Lumpur, Malaysia

I just returned from providing a requirements engineering training to a class in Malaysia. It was an awsome experience.

The training is the preparation course for the IREB certification in requirements engineering (foundation level), which is already quite popular in Germany and Switzerland.

The participants were software architects and software testers. They all work at a popular Malaysian IT company.

I was very happy to be in KL and I am looking forward to provide more training sessions there in the future. Besides the exciting experience of being in KL, the time in SEA also was a journey back time for me, cause it reminds me of my stay in Singapore in 2006.

UX, Information Architecture and Agile Development

Check out this SlideShare Presentation. As we are currently preparing our "Agile Usability" workshop for the UPA conference in Berlin, a colleague forwarded this interesting slides to us. I decided to share them with you, because they provide a great example of agile user-centered development.

IA und agile Softwareentwicklung verbinden: eine schwierige Beziehung?

View more OpenOffice presentations from eparo.

Prototypes as UI specification

I just ran across an article, which describes the use of user interface prototypes as software specification method.

"The user interface specification provides an illustrative requirements specification for a system, because the specification visualizes the functionality of the system in a form that both the client and the supplier understand."

Read the full article at http://www.interacta.fi/ui_spec.html

In her blog on bridging the gap between business and IT, Laura Brandau recently also discussed the form of UI specifications.

"Good UI specifications take into account the data and context of the user within the application. This sort of spec does not replace UI design, but it does help you lead your team through thinking through the UI design and how users will actually experience information within it."

Read the full article at http://www.bridging-the-gap.com/how-to-create-a-user-interface-specification/

Who am I? From interface designers to usability architects

HCI professionals are known as interaction designers, usability experts, graphic designers, user-experience experts, etc. (Belenguer et al. 2003).

With a greatly diversified range of interactive products and the growing need to „get the UI right‟, a variety of job descriptions has emerged (Preece et al. 2002):

• Interaction designers - people involved in the design of all the interactive aspects of a product
• Usability engineers - people who focus on evaluating products, using usability methods and principles
• Information architects - people who come up with ideas of how to plan and structure interactive products
• User-experience designers - people who do all the above but who may also carry out field studies to influence the design of products
  

Although UE is a well-established and broadly used term, (Preece et al. 2002) state that the discipline of interaction design is the umbrella term covering all of these aspects that are fundamental to all disciplines, fields, and approaches con-cerned with researching and designing computer-based systems for people.

Because the world of existing terms is not enough, I recently decided to add a nomenclature: the usability architect. I chose this term because it is the counterpart of the software architect - one who can analyse requirements, conceptualize models and designs and actually build the interactive software system with a focus on the user interface and usability.

References:
Belenguer, J., Parra, J., Torres, I. and Molina, P. J. (2003), 'HCI Designers and Engineers: Is it possible to work to-gether?', in In IFIP Working Group 2.7/13.4, INTERACT 2003 Workshop on Bridging the Gap Between Software Engineering and Human-Computer Interaction.

Preece, J., Rogers, Y. and Sharp, H. (2002), Interaction Design: Beyond Human-Computer Interaction, John Wiley & Sons.

Usability Engineering Return-on-Invest

Because arguments for usability return-on-invest play a great role in today`s usability engineering business, I have made up my mind on the benefits of usability once more. As a result of my brainstorming, I just summarized a couple of benefits along the software development lifecycle.


Because some methods are typically employed at several stages of development, both the investment and ROI may occur several times in the following diagrams.



During software development, the ROI of usability method mainly derives from the engineering-truth that early changes are less expensive that those during later stages of development.

Another very positive effect of usability integration may derive from a shared understanding of design principles and basic usability rules. Agile practices like pair programming especially foster the distribution of usability awareness.




After the software was delivered, several benefits can be measure if usability engineering contributed to the design if the product. Usually, well designed applications require less training effort. Moreover, several ROI-related usability studies have shown that support costs are likely to be much lower if usability was part of the software lifecycle.



Because people love to buy and use soft- and hardware that is easy to use and pleasurable, companies that understand the role of user interface usability can be more successful.

Naturally, usability quality cannot evolve if the functional requirements are not satisfied as well.

After all, usability investments provide the chance for some valuable benefits. However, usability efforts are not for free. It would therefore be dubious if usabilty engineers just talk of pure added value. Additional time and budget must be allocated for modelling and visualizing requirements. In the beginning, the usability ROI will be less concrete. At the latest, a closer look to the total costs of ownership help understanding why it is justifyable to invest between 5 to 10% into usability methods.

User Interface Specification - From Models To UI Design

A reader of this blog has just posted a comment on one of my previous entries on the Inspector tool.

The tool´s website is http://hci.uni-konstanz.de/inspector. Both the theoretical and practical approach is published in my thesis (http://kops.ub.uni-konstanz.de/volltexte/2009/7992/).

The according software project is continued at http://hci.uni-konstanz.de/BlendedIxD with focus on collaboration, support and simulation.

While research is dealing with new visions for blended development techniques, the basic idea of collaborative and interdisciplinary user interface specification must still find its ways into practice. Corporate developers and project managers hanker for appropriate means of joint modeling and prototyping. Some commercial tools (iRise, Axure, Microsoft Expression Blend) already pave the way for sophisticated, but easy to use methods applicable in what I call "visual requirements engineering".

Usability engineers and business analysts need a framework that supports them in travelling from analysis models to the visually specified design of the user interface.

With UI specifications that substitute ambiguous textual specifications with graphical representations of the desired UI and diagrammatic models describing user tasks and behavior, the work of usability professionals will become more engineering-driven and probably more accredited by software developers and formalists.

eBusiness: How to argue usability investments to your CEO?

Many eBusiness managers ask how they can argue for usability investments and how they can measure the return-on-invest (ROI) of usability methods. There is not much serious literature available on this topic and the web is spammed with voodoo economics and rather doubtful metrics of usability ROI.

Usability experts, however, should have some comprehensible answers if clients approach them with the ROI question.

First of all, usability has a ROI. This is a widely accepted truth. The problem is, measuring the ROI is not so easy, especially because in most cases comparative data is not available and typically usability is not the only action taken to increase the quality of an eCommerce website.

Luckily, in eBusiness the ROI of usability can sometimes be measured more easily. If the business runs professional traffic analysis tools, there are some metrics that make usability ROI traceable. For example, if changes to the design of your checkout process result in an increased conversion rate, this can be the benefit of usability engineering. Most likely, such benefits can be measured well because they are the result of a pipelined process, such as the checkout at an online store. If you also changed the presentation of your shopping basket such that cross references to other attractive products appear before the customer proceeds to the checkout, you might even be able to increase the average value of the shopping basket.

While this might sound good on the first sight, the above example does imply a critical problem. If you try to measure the usability ROI after you have implemented both changes, will you be able to determine which usability method has increased the commercial success of your site? And guess you also changed the information architecture and search process in order to make people find your products more easily. Will you still be able to tell your CEO which part of the usability effort really impacted the sales figures?

I’d say no, you are not.

The nightmare of metrics gets even worse, if the marketing department runs an online campaign at the same time. Or, the other way around, cancels a larger amount of marketing activities. If the conversion rate then suddenly decreases to a level even lower than before usability methods were applied, how can you still argue that your usability spending has a ROI?

Measuring the ROI of usability would therefore demand to take one step after another in redesigning your website for more usability. As this would critically defer the time to market, there is not really a straightforward approach to measure the ROI of usability on the basis of figures from traffic analysis data in most project settings.

Even though you might be able to deduce some arguments from analysis data, the facts you will be able to present might be annulled by others easily.

In order to understand the ROI of usability engineering, you have to consider several aspects.

First of all, you have to understand that increasing a site's usability must not be restricted to specific processes, such as the checkout. The challenge rather is to make visitors find and use the processes and applications you provide. If people are unable to find a product or a service, even the most usable checkout design won't help. Again, you will most likely identify increased site usability by the sales figures of your store. But you must understand that the improvement does not just come from a newly designed checkout. If people do not find the products they are looking for, they will not even access a checkout or inquiry process. They will rather remember your store as a dealer with unfriendly sales staff and a bad allocation of products.

Second, and as a consequence of the above mentioned, you have to consider that usability already starts on the home page (or even at the search engine that leads to the right landing page) and continues to play a major role during several other processes, especially the search and find process. The ease of finding products is linked to the filtering and focusing information on your site. The architecture of your site should provide a clear guidance and support different access strategies, e.g. browsing vs. searching for products.

Third, a strictly process-driven design of your website is not a very good strategy. Most users will not access the content of your site in the way you expect. As a website manager, you should think about the motivation why people come to your website and take different types of visitors into account. Once you have an imagination about people's goals and what people expect from your site, you will be able to design an UI architecture that enables a high user experience by providing many ways of interacting with your site.

Altogether, arguing for usability investments should not exclude specific parts of your digital sales channel. If you invest in ease of use with a broader perspective, you can increase the user and customer experience by enabling people to find, understand and buy your products with less effort and in less time. Moreover, ease of access to your product landscape might allow decreasing your headcount of customer support and call-centre agents. A certain amount of usability ROI therefore also comes from decreased total costs of ownership.

Continuous usability testing or customer surveys are the better choice compared to traffic analysis. Monitoring real users while they interact with your site or querying your customers after they ordered a product will give you a much better impression about user (dis-)satisfaction. Unlike vague interpretations from marketing and product management, usability testing will show you how your users and customer really think. Moreover, the effort to invite real end-users to usability testing sessions is usually much lower that the implementation and maintenance of a non-standard traffic analysis tool - which coincidentally is usability ROI again.