This morning I sat through a great presentation from one of my fellow Canooeys about Usability Testing. The presentation and discussion were in German, so I have no idea what anybody said; but someone had brought Black Forest Cake to share. Any meeting with Black Forest Cake is a good meeting, without exception.

I was introduced to Usability Testing way back in 2003 in the UST Graduate Program in Software. The class was taught by a great professor named Robin Kincaid whose distinguishing credential was that he was literally at Xerox Parc when Steve Jobs came to see the first GUI. Now, Prof. Kincaid wasn’t working on that machine in particular, he just happened to be standing in the hallway at the time, but that is a good enough credential for a Minnesota university. I was impressed enough to spend the next seven years carrying the mission of usability testing forward with varying degrees of success. Here is what I learned along the journey.

You Can Afford It

The low cost of discount or guerilla usability tests is the UX community’s worst kept secret. Where did everyone get the idea that you need a video camera and a dedicated usability lab? You need about 15 minutes of a real user’s time and maybe one hour per user of preparation: 4 hours total (for those not so quick at math: just recommended a sample of 4 users). The problem is trying to sell a manager “discount” usability and then trying to explain that discount doesn’t mean inferior. We’d be better off calling it Agile Usability so people identify usability with removing waste instead of vice versa.

You Have the Tools

PowerPoint or other presentation software makes a pretty good prototyping tool because you can quickly create mockups and even link a few slides together with hyperlinks. The user can then sit in front of an actual computer when exploring usability rather than having to deal with printed paper. But pen and paper do work well, and there’s even an entire book on Paper Prototyping. Balsamiq and other tools look great and produce impressive looking results, but require an initial investment to get started. If you need to impress a client then look at using Balsamiq. If you just want to make a better product then there is surely a zero cost way to start usability testing at your company by using the office supplies and software you already have.

You Don’t Need Training

You know what’s often better than being taught how to do something? Learning to do it yourself through practice. My last project included an initially reluctant designer. To kick start our usability practice, I ambushed him with his own mockups, and used him as the user in a testing session. Then we turned around and did the exact same thing with real users. Just showing someone how it is done within 30 minutes was better than several weeks of failed persuasion in meetings and retrospectives, and he turned into a great advocate for this style of testing. Over the course of the project we practiced and continually refined our own usability process ourselves, without training or consultants.

You Don’t Need an Expert Opinion

Usability testing means putting together a low cost prototype, showing it to real users, collecting the feedback, and then revising your prototype. An expert opinion is valuable when you have no access to your target market. For example, if you need accessibility features in your software, and you can’t find suitably impaired users to test with, then relying on an expert’s opinion is a good choice. But before calling in the consultants, ask yourself how these consultants became experts in the first place. The answer is no secret: they practiced usability testing and read some books. Instead of calling in the experts I recommend just becoming one yourself: practice, read, repeat.

Usability Won’t Bloat Your Process

So you’re already doing use cases, user stories, design documents, and copious amounts of meetings… can you really afford to add usability testing into your process? There is a legitimate fear that delaying development in order to produce paper mockups, testing scenarios, and user feedback will postpone final delivery even more. But take a hard look at your current process: aren’t the inputs to usability testing (mockups and a user scenario) already being produced? So called Software Design documents are oftentimes crammed full with screenshots and mockups, user stories and use cases are just testing scenarios with a different name, and many shops will spend hours on the design by committee merry-go-round debating how an interface should look. Usability doesn’t change the artifacts you produce, it just asks you to produce them at a time when they are useful instead of useless.

You Do Have the Time

Designing a user interface during a meeting is one of the most costly ways to create a UI. Eight people for one hour is a full eight hours of company time, and usually with a poor result. Instead, why not perform four hours of usability testing and then spend 15 minutes reviewing the results in a meeting with those same people. It takes the same amount of time in the end, so there is no additional cost to adopting this technique once. You only don’t have time if you insist on continuing to waste time in other ways.

It Works Best in an Agile Cycle

Here’s a process that has worked great for me in the past: with 2 week iterations the designer worked ahead one iteration, working with the users and testing his mockups. At the end of the iteration, we developers presented our working and finished software to the users, and the designer presented the system that was going to be produced in the next iteration. Then development took the mockups into iteration planning where we used the artifacts as a key guide to producing estimates and work breakdowns, while QA used the mockups as input and guidance for test creation. We didn’t start with this process, but after a few iterations of tweaking we were all quite happy with what we ended up with. If you’re new to usability then use the by-the-book approach at first, but revise the process to fit your team and your company.

It Is Not Testing

The hallmark of a good test is that it passes or fails. It satisfies a requirement or it doesn’t. Usability tests, on the other hand, make things better. Skeptics of usability studies often use this lack of precise results to dismiss the whole endeavor, saying that results of testing cannot prove which is the best user interface. This is true. Design reviews also cannot prove the best software design. Both software and user interface design can help you decide the better option out of several alternatives, but both are limited by what alternatives are presented in the first place. If you are asked to choose between two crappy designs then your final design will be… guess what? Crappy. Don’t let the best be the enemy of the good. Many practices exist to provide an improvement, not perfection. This is one of them.

You Don’t Need Usable Software (maybe)

Everyone wants usable software, but not everyone needs it. Sometimes a complex, hard to learn interface is better than a simple, easy to use one. Always ask yourself how the software provides value. Frequently, the answer is that it doesn’t. If software is just a tool to getting transactions completed, then the more transactions completed the better off your company is. I’ve worked in several call centers and seen two drastically different approaches to usability. In a call center, all of the operators receive training, and time spent operating software is an expense. In this context a user interface should be optimized to be as fast as possible to complete transactions, even if it requires training to use. Several methods exist to measure the speed of a UI, including GOMS and Master Clerical Data (MCD). If your customer will financially benefit from a fast to operate but difficult to learn system, then stop worrying about what’s intuitive and start worrying about keystrokes and mouse movement. Some simple arithmetic can create an eye-opening return on investment proposal. For more on this idea I recommend reading Humane Interface by Jef Raskin.

It is Surprisingly Hard to Sell

If you aren’t doing usability testing, then someone, somewhere has the job of making user interface decisions. These decision makers have power, and few people will give up power for nothing in return. Maybe it is a developer who produces screenshots as part of a design process, or maybe it is a manager who debates and decides how a form should look. If you want to try usability testing then you need to convince these people that it is worthwhile. A developer is typically easy to convince, because you can replace an ad hoc UI design process with something more rigorous, appealing to their engineering principles and padding their CV. A manager or analyst is much harder to persuade because they often are not rewarded based on the quality of the finished product but instead based on the amount of their input that ends up in the finished product. Selling usability can oftentimes be interpreted as making part of their responsibilities obsolete. This is true, good, and a difficult pill to swallow. I recommend involving analysts as a key member of the usability team, so that the energy they had put into committee decisions can be refocused to a better process. As for selling managers on the idea… I don’t have any successful tactics and would love to hear feedback or experiences you might have.

Today, after several years of practice, I am just as excited and hopeful for usability testing as I was when I started. Many, many software shops could benefit from low ceremony usability testing. The key to getting value from it is to keep investment and costs to a minimum. Train yourself, don’t commit to fancy tools, resist the allure of pricey consultants, and just get on with practicing. Happy Testing!

What contributes to the richness of a RIA (Rich Internet Application)?
What contributes to the poorness of a PUWA (Poor Ugly Web Application)?
How does a RIA compare to a PUWA?

In this post, I’ll discuss forms and what they look like in a RIA. Forms are the sort of things that you find a lot in business applications. For example, bank employees use them to manage customer data, to view account transactions, or to calculate mortgage offers. Or what you, as a brave citizen, use to submit your taxes. But forms are not limited to business applications. You can find them in games to set up your player or to configure the game server.

Consider the following screenshot showing a form to calculate a mortgage offer:

What exactly makes the above form a rich form? Can you spot it? Sorry to disappoint you, but it is not possible to see form richness. The only way to decide that a form is rich or not is to feel the form. And of course with a static screenshot it is really not possible to feel the form. Richness comes from interaction design and not from graphical design. This is a common source for misunderstanding. So let’s repeat it: Richness comes from interaction design and not from graphical design. Two topics in interaction design define the richness of a form: input feedback and input support.

Input Feedback
Let’s start with input feedback. The easier the user can connect the feedback to his or her user interaction, the richer the form. Given this fact, a form within a PUWA can never be rich. A PUWA is page-oriented and the user does not get feedback at the time when he or she enters wrong values. Instead he or she gets feedback only when he or she commits the form (see this groundbreaking article that compares PUWAs with Ajax-based web applications). A measurement for the richness of the feedback is the kind of feedback that is available to the user. Basically we distinguish between syntactical and semantic feedback. Syntactical feedback tells the user that field input is not well formed, e.g. error messages such as this is not a number, this is not an email address, this number has to be between 0 and 18. Whereas semantic feedback puts the input in a broader context and checks for business rules, e.g. the total loan amount may not be greater than 80% of the object’s value, or you are not authorized to withdraw more than 2000€ per week. The more semantic feedback the richer the form.

Input Support
The second measurement for the richness of a form is input support. One well known example for input support is suggesting valid field values as the user types. You can check out this feature at Google Suggest. Other forms of input support are the calculation of dependent values (e.g. calculating the city name for a given zip code) or disabling of non-mandatory fields (e.g. fields defining the legal guardian for underage persons). The more input support, the richer the form.

How does UltraLightClient ’08 fit into this? First, its server-side architecture is a perfect fit for ultra-easy semantic feedback. This is because all of your code runs always on the server-side. There is no need to split code and propagate business logic to the client. Just access the business objects you need, it is that easy! Second, UltraLightClient ’08 includes an high-level form component out-of-the-box. This makes the implementation of forms both, efficient and ultra-easy. The application that provided the screenshot above is implemented with UltraLightClient ’08 and contains all forms of input feedback and input support.

Summary
Richness comes from interaction design (feel) and not from graphical design (see). There are two measurements to decide if a form is rich or not:

• Input feedback: the more semantic feedback the richer the form
• Input support: the more support the richer the form

UltraLightClient ’08 is a perfect fit for both measurements. Its server-side architecture makes it ultra-easy to provide full semantic input feedback and its high-level form component enables full input support out-of-the-box.

The August 2008 issue (Volume 31, No. 4) of Informatik Spektrum has published a background article by Hans-Dirk Walter on Rich Internet Applications. The article is in German and can be purchased online at the publisher’s website:

“Rich Internet Applications” – Eine perfekte Kombination benutzerfreundlicher Schnittstellen mit Webtechnologie

Zusammenfassung “Rich Internet Applications” (RIA) sind Webapplikationen, die mit einer wesentlich interaktiveren Benutzerschnittstelle ausgestattet sind, als wir das bisher von den auf HTML basierten “poor ugly web applications” (PUWA) gewohnt waren.

Canoo recently published a new look for one of its UltraLightClient sample applications.

Our aim for this sample project was to show that Java web applications need not rely on the standard “grey and clunky” look and feel, but can be customized to fit into a company’s corporate design or to match current web design trends.

The design for the OnlineShop sample was developed by User Interface Design GmbH. Two Canoo developers then implemented the final design within two weeks.

The sample application can be accessed online:

Please note: you will need the Java plug-in to view the sample application.