Welcome to EMC Consulting Blogs

In my last post, I described the somewhat painful experience I had doing QA on a system I had designed, but where the designs were “thrown over the wall” to the development team. I’m still mulling over what lesson I can draw from this. The basic problem was that I found all sorts of conditions which we hadn’t factored in to the initial design of this lookup system. If the system automatically detects the query type from the input string, what are all the possible responses? What if a particular option isn’t available for all users? If a “not found” message appears, how should the user be able to re-do their search?

I’m tempted to say that I need to be more rigorous about the flow maps for highly interactive systems like this. I drew one early on in the process, but it wasn’t updated to reflect the numerous hacks and requirements changes. Those flows got as far as “display the ‘not found’ message”, but they didn’t cover the full user scenario: What will the user do then? Will they re-try the search? Will they change their parameters? Will they give up and go elsewhere?

One answer, certainly, would be to create more thorough plans. But the time pressure was intense on this project, and there wouldn’t have been time to re-think that after each round of changes. Another answer would be to coordinate more closely with the developers, so that the product could be refined in a somewhat agile manner. But of course the developers are under their own pressure, and we weren’t operating within an Agile framework. Perhaps this was the best that could be managed under the circumstances; but I can’t help but wonder whether there was something else we could have done to create a better end result.

More generally, I think this says something about product management. First, this experience highlights the need for the UX designer to be involved in the development phase, not just the initial design. Even the most detailed plans will run into unexpected technical constraints or unforeseen use cases. If the UX designer isn’t in close contact with the development team, the developers generally won’t think of reaching out when unexpected things come up. They’ll implement whatever solution seems easiest to them, often at the expense of good usability.

This experience also illustrates the need for iterative design. Systems won’t always come out the way you intend; corners will be cut, exceptions will emerge that you didn’t think of. Consulting projects are often planned as if there will be no version 2 (or even 1.1), and a smart product owner needs to understand that the thing you launch now will need more work in the next release - even though it passed QA.

Earlier this week I conducted some user tests for a touch-screen system, using a low-fidelity clickable (touchable?) prototype built from wireframes. It was an interesting experience, both for what I learned about the client's users, and about touch-screen prototyping in general. I'll share some thoughts on the latter here.

The choice of software

I created the prototype was in InDesign, and exported as a SWF file. I had considered using Axure, but I'm not a huge fan (for reasons I'll leave for another article). I also wanted to take advantage of InDesign's ability to incorporate documents inside other documents - so I could create a full-screen wireframe for the prototype, then incorporate that wireframe inside a larger page to provide annotations.

In addition, I wanted the prototype to fill the screen of the touch panel, without browser chrome around it. I had conflicting information on the size of the client's touch screens, though (in terms of pixels), and wanted something that could resize itself to fit the screen. Two likely options were: 

• an interactive PDF document, run in display mode;  
• a .swf file, running without an HTML wrapper.

I was originally going to go with the PDF option, but I ran into some InDesign limitations. Most of the screens on the prototype were to have a menu which expanded to provide navigational options. This menu had several states though - at least five - so I needed the menu object to be independent of the page, or I would have to create countless screens for every permutation of page and menu. (This, incidentally, was also the reason I didn't use Balsamiq.)

It turns out, though, that while the requisite actions are available in InDesign, they won't actually export to PDF. (I'm using version 5.0; it sounds like 5.5 may have fixed this, but I'm not certain.) I did create  a clickable PDF as a fall-back option, with only a single page that had an expanding menu on it; but I knew the user test would flow much better with an expanding menu on each page. So I exported to .swf, and put the files on a flash drive, along with a Flash Player executable file as an additional option.  

Running the prototype

The challenge I found was running it on my client's system - a Windows-based touch-screen display which I wasn't able to access until about a half hour before the tests. The system wouldn't let me install Flash Player, or run it from my USB drive, so I had to use the browser - Internet Explorer 7.

Fortunately IE7 lets you show a page in full-screen mode, so we could eliminate the browser 'chrome' which could be distracting for my usability tests. (The software will eventually run as a stand-alone executable, not a Web app, and I wanted the prototype to reflect this.) To do this:

• Bring up the prototype (.swf file, opened from the file system)
• Disable the status bar (View > Status Bar)
• Switch to full screen (View > Full Screen)

This worked pretty well, with just one glitch. Part of the way into the test, one of my subjects uncovered a nifty feature of IE7, which unfortunately screwed up our test: Swipe navigation, or "Flicks". On a touch screen, this lets you navigate forward and back with swiping movements left or right. If you're navigating inside a SWF file, though, everything is on one "page"... so our test subject suddenly found himself looking at the MSN website. Worse, since our prototype was on a local file, we couldn't just swipe "forward" again; we had to again do File > Open, browse to the file, and click through several dialog boxes to confirm that it's OK to run active content.  This might have been acceptable once, but we had to go through the process several times with different test subjects. 

So, lesson for next time: Make sure "Flicks" are disabled. To do this:

• Open "Pen and Touch" control panel
• Select "Flicks" tab
• Un-check "Use flicks to perform common actions...", and Apply/OK. 

A possible second lesson: Bookmark the prototype file, for easy access, and set the security options to allow running active content from the location of the file (our USB drive, or the Documents folder). 

And lastly: Always leave a short break between your usability test sessions, so you have time to fix stuff like this. If someone else is scheduling them (as was the case here), make sure they do this.