I know at one time we were going to inventory the books we had among our various desks. I also have quite a few books at home that others might want to borrow (and even read). I think it would be useful to maintain a book list here on URID.org. I'll even volunteer to do it, if you all think it would be worthwhile.

So I think the requirements for HTML prototyping comes down to this: we have to build the HTML prototypes very quickly on the cheap, and they can't be mistaken for the final design.

Friday or Monday, Chris sent me some "cool" links that address these issues head on. Chris, I don't know where you find these websites, but they are gems. The upshot of this is that I could quickly create an interface, including form elements. Being the geek that I am, I wanted to know how effectively this could be applied to a template and across a web site. My personal website (which you should never visit at work) is template driven. In about 15 minutes I designed a new layout template and applied it to my web site. The results, while aesthetically challenged, showed to me that an HTML prototyping approach is feasible.

So I guess I'd better list my caveats. I acknowledge that I have a fair amount of experience with HTML and CSS. If you want to build HTML prototypes quickly with the tools, you need to have an understanding of CSS and HTML.

I suggest the books, Cascading Style Sheets: Separating Content from Presentation, Briggs et al., Glasshaus, 2002, and Cascading Style Sheets, Designing for the Web 2nd ed., Lie and Bos, Addison-Wesley 1999. For HTML, I always suggest Werbach's Barebones.txt.

And now, Chris' super-cool links that changed my life:

• Layout
• Lists (I use these for navigation components)
• Forms generation
• Form elements (for custom tweaking)

All of these tools generate HTML code and the underlying CSS. These really are better than sliced bread!

URID will, of course, continue to live among the ongoing collaboration of all of us that Erika will be coordinating—and URID.org will be an essential part of that.
And, Chris is exactly right that each of you will continue to be usability professionals, and you will not only be able to, you are expected to, make a greater impact by working from a position that gives you greater control over the product development lifecycle.

It has been—and I expect it to continue to be—a source of great personal joy and pride to work with all of you, individually and collectively. I’m very proud of each of your professional development, professional accomplishment, and contribution to Fannie Mae’s success, and I anticipate continuing to have reason to feel that way far into the future.

Thanks,

Bill

A few random thoughts:

• Many of us have often joked that URID sounded either like the name of a disease or a Balkan nation (as in URIDstan). Well, in keeping with the nation metaphor, I think it’s appropriate to think of URID’s future as a loose confederation of states that will continue to work closely together to achieve common goals.

• In many ways, URID.org becomes more important in this brave new world. Because we will be decentralized, there is an even greater need for a single place where we can exchange and archive information.

• For me, at least, the key to making peace with this new world is to continue to see myself as a usability professional who will be able to make a greater impact by working from a position that gives me greater control over the product development lifecycle. I think a big part of my reaction yesterday was in thinking that this identity as an expert was going to disappear and that we would just be assimilated into the product management machine. I now realize that this doesn’t have to happen.

A final comment. When I was talking to Gerette last night about the fact that one of the goals of these changes was to bring a more user-centered design perspective to the product/project management process, she said “It’s like Usability Eye for the Project Guys”. I laughed, but she said — quite accurately it turns out — “I guarantee you’ll be using that line at some point tomorrow.”

Thanks!

• Facilitated user feedback from Third Fed for APS; found that generally new interaction design seems solid but there are still issues with the data returned.
• Finalized APS wireframes based on Third Fed call and business owner feedback; finalized APS Navigation Model; finalized APS Wireframe Specs (see TWiKi).
• Attended APS status meetings and participated in issue resolution efforts.
• Created W2W materials for usability evaluation; talked w/Jeff Ballard of Citibank to get his input on the materials.
• Worked to finalize set-up for W2W ID’s.
• Began set-up of W2W Netraker evaluation (was on hold for ID’s and b/c acceptance was down).
• Participated in 2.4 requirements reviews for scoping effort and for e-Business Marketing review.
• Attended DUR status meetings; on track for meeting Jan. 1 deadline for HMDA changes, interaction design is in-line with other 2.4 changes (see TWiKi).
• Attended DO/DU support communciation meeting w/Erika. Main topic of discussion was how to get changes into DO/DU faster, agreed to focus on issues that could be resolved in upcoming releases instead of analyzing the data in general and not taking action.

Planned Activities (Sept. 29 - Oct. 3)

• Complete set-up of W2W ID’s
• Complete NetRaker W2W evaluation
• Complete W2W evaluation dry run with Jeff Ballard
• Schedule W2W evaluations with participants
• Deliver final documentation for APS
• Work with APS to develop HTML mock-up of application

Project Statuses

• APS: approaching finalization of 2.2 documentation, creating HTML mock-up of UI
• DUR: approaching finalization of Jan. 1 release to meet HMDA requirements
• W2W: in production with Citi

Issues

• APS business owner has different goals for usabaility evaluations than UR+ID. Clear that Paul is using calls as opportunity to show changes and sell (or re-sell) APS. Result is that UR+ID is not getting good usability input.
• APS business owner has set opinions on how some of the screens should look, which differ from the little feedback we’ve received as well as established best practices for presenting data on-line. Colin is going to set-up a meeting for us with Kelly & Paul to have conversation about screen in question. In the end, we’ll do what Kelly wants.

Travel Next Week

• None

Project Contacts

• W2W: Lorri Holloman
• APS: Colin Deaso
• DUR: Rich Acker

As Erika pointed out in a discussion that she and I had after Friday's session, what she was doing was market research, not user research. Because of the constraints of the evaluation situation that we were in, we were collecting user responses, not user behavior. That is not to say, however, that we don't gain valuable insight from the technique that she employed.

In the sessions that we've had so far, we have to remember that no matter how low-fidelity the evaluation, or constrained the process, we gain value from communicating directly with users. We also gain experience and confidence in our ability to facilitate.

Some Evaluation Techniques

I'm proposing a couple of dimensions for evaluation that I think our team should consider:

• Facilitation dimension
• Stimulus dimension

Facilitation Dimension

The facilitation dimension extends from a facilitated phone conversation in which the facilitator cannot see the user or the user interaction to a full-blown usability test in which the facilitator is looking at the user and observing the user's interaction.

Phone Facilitation. The facilitator talks with the user over a phone line. The facilitator cannot see the user or the user's behavior. In the APS example, Jessica and Erika talked the user through the wireframes, asking the user questions, and documenting the user's responses. While it's evident that phone facilitation does identify issues, the facilitator is flying blind. Here are some issues:

• The facilitator cannot validate user behavior.
• The facilitator may have to coach the user to elicit a response.
• User responses tend to be more about the application functions and less about the user experience.
• Evaluation results are not valid and may not be actionable.
• The evaluation is relatively inexpensive.
• We need to have a discussion about the kinds of questions that are appropriate for this kind of situation.

NetRaker Facilitation. Using NetRaker, the facilitator can see the user's interaction with the stimulus, but may miss other important behavioral cues. NetRaker should make it possible to validate user behavior. Its clickstream capabilities will also provide valuable information. Issues:

• While not flying blind, the facilitator still does not have a complete picture of the user experience.
• Because the evaluation can be conducted in the user's workplace, the evaluation may have an added realism that a usability test doesn't have.
• The evaluation protocol can be modeled on a usability test protocol.
• The results may be valid and actionable.
• The evaluation requires resources, but can probably be absorbed without it becoming a separate project expense.

Usability Test. Certainly, our team has the most experience with formal usability testing. AIR facilitators know what they are doing. Tests are well documented with notes, tapes, and reports. While this kind of evaluation has enormous constraints, it also provides authoritative results:

• The testing situation is artificial
• Fannie Mae doesn't have lab facilities.
• Because we farm the testing out, AIR provides an expert seal of approval--it's not just us saying something.
• The results are valid and actionable.
• Usability tests are difficult to set up and expensive to run. We can't hide these in project expenses.

Stimulus Dimension

The stimulus dimension extends from wireframes through a full-blown application, or non-interactive to interactive.

Wireframes. Wireframes document the application interface, but don't provide any interaction:

• The lack of user interaction with the prototypes is a major drawback.
• Because wireframes are produced in the course of our work, they are always available for evaluation.
• We discovered in the APS evaluations, that the "flatness" of the wireframes and the constraints of their HTML rendering made it difficult for users to see options, links, and buttons.
• Wireframes are amenable to remote evaluation, but don't have high enough fidelity to be used in a usability test.
• Users could not see the contents of drop down lists.

Paper Prototype. Paper prototypes have traction during the early design process. We should consider adding them to our evaluation tool suite.

• Paper prototyping may be too expensive to test with end users because of recruiting and facilities requirements.
• Paper prototyping require face-to-face facilitation (although we might experiment with remote evaluation via videoconferencing).
• Paper prototypes are useful for discovering usability issues with "surrogate" users (business owners and subject matter experts).
• Paper prototypes are inexpensive to devise, and infintely malleable during the design/evaluation process.
• Paper prototypes are not easily adapted to remote evalutation techniques.

HTML Prototype. HTML prototypes provide interaction and navigation, providing opportunities for validation not possible with wireframes.

• HTML prototypes require extra resources that our team doesn't have.
• Developing an HTML prototype template would help mitigate the resource issue.
• Prototype evaluation can validate user behavior.
• Prototypes can lull observers into believing that application development is much further along than it actually is.
• HTML prototypes are amenable to the full range of evaluation techniques.

Application Prototype. Application prototypes can be used to evaluate limited application functionality.

• If a development team uses iterative development, an application prototype provides an opportunity for validating the user's experience with prototype's functionality.
• Results can be folded into a subsequent iteration.
• URID resources would be used only to evaluate the prototype, not to develop it.
• Technical difficulties are the order of the day when working with application prototypes. They tend to be buggy, and setting up an evaluation requires working through firewall, environment, user id, and test data issues.
• Application prototypes are amenable to the full range of evaluation techniques.

Working Application. Evaluating a working application provides the most complete coverage of functionality.

• URID resources would be used only to evaluate the application.
• Any evaluation results would have to be folded into the next (or subsequent) release of the product.
• There will be some technical issues, but probably not on the scale of testing an application prototype that's in a testing environment.
• Applications are amenable to the full range of evaluation techniques.

Analysis

Use of resources moves from phone facilitation -> usability test and from wireframes -> HTML prototyping -> working application. Validity goes in the same direction. However, actionability doesn't. Usability findings are more actionable early in the development process. The evaluation models we employ should provide:

• no or little additional resource (at least for URID) commitment
• facilitation that captures significant user behavior
• findings that are readily actionable by the development team.

For the most part, NetRaker provides a facilitation model that captures important user behavior without the expense of a full-fledged usability test. An augmented wireframe or HTML prototype provides some degree of user interaction (I vote for the HTML prototype). Wireframe and prototype development also occur at the point in the development process where the results from a usability evaluation will be the most actionable.

The class is intense with lots of reading material. It’s mostly lecture in format; so be prepared to sit for long periods of time. The interchange with instructors and students was open and encouraged. Sometimes this got in the way of the class message, because some FM people like to hear themselves talk. On the other hand it was great to hear the mortgage banker perspective, then the FM response. In the process, you learn a lot about FM’s business, too, which can’t hurt.

If you want more information about the class, I have the notes and the textbook at my desk. I’d be happy to talk with you about it. My advice: enroll and attend. Some last words: the food was good. The instructors were engaging. The shuttle out to Herndon was a little piece of heaven.

Thursday Sept. 25 & Friday Sept. 26 - Vacation

Monday, Sept. 30 - OUT in the AM, in ~1PM
Tuesday, Sept. 31 - OUT in the AM, in ~ 1PPM
Wednesday, Oct. 1 - in the AM, OUT ~3PM
Thursday, Oct. 2 - in the AM, OUT ~ 3PM
Friday, Oct. 3 - in the AM, OUT ~3PM

If you need me while I’m out, please call on h: 703.938.2777 or c: 202.549.1508.