A great design researcher is always...

Astute readers will notice that some of these qualities can be quite contradictory. It’s hard for a researcher to maintain his empathy when he must also be ornery with his product team to ensure his knowledge and ideas are heard. Likewise, when a researcher develops deep domain expertise to help him become more articulate, he may find it difficult to remain inquisitive - he may come to believe he knows the answers, and mistakenly thinks this means he can skip asking the questions.

Great design researchers must strike a balance between these four qualities so that no one quality becomes too dominant. It is a balance they must maintain throughout their careers, and it scarcely gets easier as the years go by. Perhaps this is why there are so few great design researchers.

In Chapter 8 of the FIG, I discuss ways to make your application safer and more secure through user-centered design. One of the principles is to clearly communicate consequences, and I rant at length on how poor of a job most browsers do when attemping to communicate the security ramifications of trusting a particular website. The tiny lock icon in the bottom of the screen and/or the series of arcane "Don't Show Me Again" dialog boxes that both IE and (formerly) Firefox employed weren't cutting the mustard for me.

Firefox has made a huge step forward with this new design. They placed the site's verified credentials in a place that people already look to tell where they are on the web: the address bar. This decorator is much more likely to get noticed than the old tiny-lock-in-the-bottom-right-of-the-screen was. The decorator is also clearly visually distinguished from the address, making it more likely that users will come to recognize and trust the decorator, and think something is amiss if they don't see it (perhaps because they have clicked on a phisher's link that is only pretending to be the real Paypal, Inc.)

The solution isn't perfect - it could be clearer that the company name's placement in a green box implies that the connection is verified. It also doesn't make clear the risks of sending sensitive information in the insecure (i.e. normal) state of the web. But it's a huge improvement over the old model, and if widely recognized by web users could significantly reduce instances of fraud on the internet, especially if adopted by IE as well (hint, hint, Microsoft).

Now it's four months later and I finally have something to show for it. NJ released a new test build, 0.38 TEST, which includes my Google Reader integration feature. After backing up your Snackr database and your Google Reader feed list, download the test build and let me know what you think.

1. Click on the Options icon to bring up the Options popup.
2. Click on the "Google Reader" tab.
3. Check the "Enable Google Reader synchronization" checkbox.
4. Enter your Google Accounts user name and password in the text inputs below.
5. Click "Connect".

If all goes well Snackr will ask you how you want to initially sync up your Snackr and Google Reader feed lists. Pick the appropriate option (be careful - if you say to use only Google Reader's or only Snackr's, the other feed list will be deleted) and press "Ok". Snackr will hold a lengthy conversation with Google Reader to figure out what the new feed list should be, but soon you should be synced up and ready to go. From then on, all operations you perform in Snackr (adding and removing feeds, marking items as read) will be reflected in Google Reader and vice-versa.

Send NJ and I feedback via email or log a bug if something isn't working. However, keep these things in mind about the test build:

• At the moment, all feed add and removes and item reads are synced automatically between Snackr and Google Reader. It's kind of like your iPod and iTunes in their default mode - both clients must match each other exactly. I'm curious if this is how people expect this feature to work - shoot me an email and let me know. If it isn't what you expect, write me with what you're trying to accomplish and if you have any thoughts on how Snackr ought to work.
• When you initially set up Google Reader integration, you may see some items scroll by in Snackr that you had marked read in Google Reader. For technical reasons Snackr currently may miss some items on its initial sync, but don't worry - if you let Snackr run for 10 or 20 minutes it should eventually sort itself out. If you are still seeing items you'd marked as read, please log a bug and include the url of the feed that isn't syncing.
• If you add a feed or mark an item as read in Google Reader, this will not be immediately synced with Snackr. This is because the Google Reader API doesn't allow us to register Snackr to receive updates as they happen, so we have to poll it and right now we're only doing that on Snackr startup and every 10 minutes thereafter. If you wait awhile you should find that the sync has gone through.
• There are some minor performance issues with the sync and item read operations. I'm working on ironing them out.

Keep that feedback coming!

• You can drag the ticker to any of the edges of your monitor, including the edges of a second monitor.
• You can change the ticker speed via the preferences (second icon from the left). I like to slow mine down all the way since I find the default speed too distracting.
• You can add feeds just by copying the feed URL, clicking on Snackr, and then doing Cmd/Ctrl-V to paste.

Now, quit reading this and go check it out!

Found via Ethan Eismann.

With Thermo, however, I had no choice. There were so many new and untested concepts that we had to start iterative design and testing as soon as possible if we hoped to make the product usable. Although we had working code in various stages of completion, the “real thing” lacked the refinement I needed. Besides, testing on the real build is dissatisfying during early-stage design. Code changes take time that slows the process and leads to fewer opportunities for design exploration and iteration. Building interactive prototypes in Flash or another rapid-development technology can help ameliorate this problem if you have the resources to do so, but even they take longer to change than I would like (Thermo, of course, will make it even easier to build interactive prototypes for testing, but we have a bit of a chicken-and-egg problem there… And even Thermo prototypes will still be digital, which is never as malleable as paper). So NJ and Ethan and I bit the bullet and sat down to build a paper prototype of Thermo.

I affectionately call it "Thermo: The Board Game".

Surprisingly, the prototype actually worked out extremely well. Although there are definitely aspects of the interface we could not express via paper (detailed content manipulations, low-level feedback such as rollovers, and subtle motion effects are all examples), we were able to express enough to get really good data on where our design was helping users understand the new concepts and complete the key tasks and where it was leading them astray. We conducted eight rounds (!) of iterative redesign and retesting, not stopping until we were convinced our target users were grasping the key concepts and applying them to accomplish their goals after only a brief period of experimentation with the product.

During the course of designing and running the study, I learned a few things about paper prototyping that I’ll definitely be keeping in mind for the next time.

1. Figure out up front what parts of the design you’re likely to get relevant feedback on via paper and what parts you aren’t. This way you can guide people past the parts where paper just doesn’t provide enough information for them to figure it out on their own and get to the parts of the task it does test well. Ideally, you’ll have a chance later on to study a higher-fidelity prototype to get full coverage of your workflows.
2. Sketch out the workflow via hand-drawn storyboards before you or your designer starts cranking out high-fidelity comps. This will help you understand what pieces of the UI you need and how the user might interact with them. In the worst case, you can always hand-draw something on the spot, but it sucks to be missing whole sections of the product.
3. Make sure you have high-resolution printouts or your participants will have too much trouble viewing your UI elements. Laser printers are a must. We forwent color in favor of high-quality laser printouts and just used colored pencils to draw in the parts that had to be in color to support user comprehension of the design. If your design uses color more extensively than ours, get a color laser printer.
4. If you have lots of fiddly little bits of UI that need to be individually moved around, consider printing out your interface on large-sized paper to make them easier to grab and manipulate. I used tabloid (11x17) printouts for everything. This obviously doesn’t simulate how well your design will perform at lower screen resolutions, but paper isn’t the right way to simulate this anyway (see point 1 above).
5. Running paper prototypes is slow. Don’t be afraid to stop the participant from going down a path that is really going to get them into a bad state and waste lots of time in the session. However, use this as an opportunity to see why they wanted to go down that path - understanding their mental model will help you fix your design.
6. Strike a balance between formal study techniques and informal conversation. Avoid guiding the participant, but feel free to chat with them as they go to understand what they’re thinking. Correct any mistaken assumptions that are an artifact of the low-fidelity paper, but make sure you record points where you have to help them or explain something - these are design problems you need to fix.
7. Have lots of scrap paper, printouts of UI elements, and scissors with you when you run the prototype. You’ll be doing a lot of on-the-spot arts and crafts as you adapt the UI to what the participant is doing.
8. If the participant is really confused, feel free to make on-the-spot design changes to see if it helps them understand what to do next. In your later iterations, you should find yourself doing this less and less.
9. Have someone else take notes. You can’t take notes and interact with the participant and run the prototype all at the same time, and it’s important for the researcher to be the one running the prototype and interacting with the participant. Although not all note-takers do as good of a job as you might, I find almost everyone can do a good enough job after 5 minutes of training and viewing an example of a well-recorded session.
10. As with any iterative testing session, schedule debriefs and redesign sessions soon after each round. Digest the problems quickly and help your design team to come up with solutions and rev the prototype. Problems always tend to get solved quicker when there’s a hard deadline - I only allotted one week between rounds.

Even though designing the study and constructing the paper prototype was a huge undertaking, I’d definitely do it again. If your product makes use of new concepts or patterns that your users may not be familiar with, it’s an invaluable way to get feedback quickly, incorporate that feedback into a new design, then retest to make sure your solution works. Paper allows for a turnaround time that no other technology can match. I’ll paraphrase one of our senior engineers, Mark Shepherd, who said “it may have taken you eight rounds to get this far, but back in the old days it would have taken us until Thermo version 8!”

Although one might quibble with it's means, the Wifi autoconfig program depicted here does an excellent job of following the FIG best practice "Use the impeccable memory and powerful processing abilities of computers to eliminate work for your users." More systems should attempt to follow this autoconfig program's good example.

Dilbert.com recently relaunched with a new site design that uses primarily Flash. Good technology choice. Unfortunately, it seems to have gone downhill from there.

The new design has received quite a bit of negative user feedback, and much of this is quite justifiable. The new Dilbert may use Flash, but it uses it in many of the wrong ways.

First off, notice the fairly small amount of screen real estate devoted to the content the user cares about (the comic strip itself). Only one strip, today’s, appears in a fairly small box - the rest of the screen is given to ads and overly elaborate navigation. What’s worse, the Sunday comic (which has always been larger than the weekday strips) is still crammed into the same small box! To see the whole strip, the user must use arrows to scroll from frame to frame, a ridiculous amount of navigation excise!

The Dilbert.com designers had an opportunity to make the site more effective at viewing and browsing the comic strips than was the old, fairly clunky HTML site. For example, they could have implemented smarts that recognized the last time the user had visited Dilbert.com and displayed all the comics he hadn’t yet seen. They could have provided filtering tools that gave users easier access to the archives, or allowed them to view top rated comics without navigating to a new screen. The new “Mashups” feature could have been implemented in-place by clicking on the comic to modify the last panel instead of creating a whole new screen and scattering the main page with navigation links. Sadly, the design team dropped the ball and chose to create a traditional HTML application with a sprinkling of animation.

Speaking of animation, the new site design uses motion in all the wrong ways. For the first week it was launched, there was a continuously playing movie plopped in the lower-left corner of the screen. This is almost always a bad idea - continuously playing animations distract the user from main content. They’re annoying and they often don’t even serve their intended purpose of drawing the user’s attention; most web users have been “trained” to ignore animation since they equate it with useless banner ads. This was quickly removed, fortunately, but the site still uses motion gratuitously. Text bounces and icons jump, but the design never employs motion to help users understand the structure of the site, how to explore their content, or how to accomplish their goals. The ability to employ motion to help guide users through the site is one of the biggest advantages Flash gives to designers, but Dilbert.com fails to take advantage of it.

On the positive side, the site does do a good job of preserving web idioms such as bookmarking and back button support, something many Flash sites fail to achieve. The site designers seem very familiar with traditional HTML website design, which served them well when managing URLs but poorly when designing the actual screens and navigation structure.

Overall evaluation: Thumbs down.

Dilbert.com - List of broken FIG best practices

• Eliminate unnecessary navigation in your applications.
• Integrate highly related information into a single content display whenever possible.
• Avoid splitting information across multiple screens or states.
• Only use page-to-page transitions when the user is pursuing a clearly different goal.
• Use intra-screen changes to modify the screen as the user advances through tasks that are related to the same goal.
• Employ sound visual hierarchy to communicate the important elements on the page and to guide the user’s eyes to the next part of their task.
• Make it easy for users to not just find content, but explore content.
• Display controls in the context of the content they manipulate.
• Avoid gimmicky or gratuitous motion
• Employ motion to apply physical principles that help users understand the workings of your application
• Use the impeccable memory and powerful processing abilities of computers to eliminate work for your users.
• Discover your users’ real tasks to better understand what flows you must make more efficient.

Unfortunately, disabling controls without explanation is often a pathway to confusing your users. The problem is that disabling a control does not, by itself, provide the user with any indication of why the control is disabled. It may seem obvious to us, the system’s designers/developers, but to a new user experimenting with the application’s functions the reason the control is disabled may be quite opaque, especially if the function is far away from the means of enabling it (e.g., with application menu items). Time and again in user testing, I’ve watched participants fumble when a function they were expecting to be able to perform is inexplicably disabled.

• If the user must select additional content before the operation makes sense, as in the example above, consider keeping the control enabled but asking the user to choose the second item in a pop-up box. Consider including help text in the box informing the user that they could have multi-selected list items using control-click to avoid the dialog.
• If the user needs to do something more complicated, consider leaving the control enabled but providing help text explaining how to get the function to work when the user hovers over or clicks on the control. Remember that modal dialog boxes are bad, so consider using something less intrusive like a callout to provide this information.

If anyone has other ideas on how to avoid the disabled state, please do email them to me or post them in the comments.

NJ and Steven are here as well. If you ask nicely we would love to show you the Thermo demo and get your thoughts on what we should be doing with the product!

We're looking for someone who can help us create learning material to help designers get up to speed on Thermo, a new tool that will allow designers to create the next generation of rich application UIs. You'll work closely with myself, Ethan, NJ, Mark, and Steven to design and develop the way people will learn this exciting new tool. Not sure if that's an incentive or a threat, but there you go :).

If you're interested, check out the job description and email Randy Nielsen if you think its a good fit. Don't write me about it - I'll just have to forward it to him and I can't guarantee I'll do so in a timely fashion :).

However, this doesn't mean we're done with the Flex Interface Guide or our efforts to provide you with guidelines, components, and other useful material to help you create the great experiences we all dream about. We're currently working on adding more sample components and we still have a placeholder for an official set of interface guidelines, as you may have noticed. In the meantime, it would be great to hear your feedback on what we've already published (Is it useful? Is it correct?) as well as hear what else we could be doing to help you more.

Feel free to get in touch with me directly or post to the Flex Interface Guide forum.

I actually just sent the final edit of Part 7 along to the Dev Center folks, so that article should show up in a couple of weeks. Part 8 should follow shortly after the holiday break. Once I've got those off my plate, I'm hoping to pick up the slack on this little blog project you're reading right now...

Now, ever since the early days of the Americans with Disabilities Act, government websites have had to adhere to minimum accessibility requirements defined by the section 508 guidelines. In general this is a good thing - government websites should be accessible to all citizens regardless of their physical capabilities. However, privately owned websites were not, to my knowledge, generally considered to be under the same constraints. Following the section 508 guidelines was generally considered a best practice, but it was up to each private company or individual to determine how closely they needed to adhere to the guidelines for their business goals.

The second problem is that section 508 offers minimum guidelines for accessibility but doesn't mandate a great experience for disabled users. All too often, designers and developers use accessibility checklists to adhere to minimum requirements at the expense of creating a great experience for able bodied and disabled users. Section 508 provides no incentive for providing some of the accessibility features most needed by disabled users. I discuss this in a bit more depth in the Flex Interface Guide article on Merging the Web and the Desktop. So forcing section 508 on private companies may make web experiences worse across the board for everyone for marginal gains for some disabled groups.

On the other hand, section 508 does at least guarantee a minimum level of accessibility for certain groups that rely on screen readers and other assistive technologies. Most web sites and web applications should take these guidelines seriously. But there is a big difference between "should" and "must", and we should be careful about the unintended consequences of applying "must" too liberally.

I wanted to point out that, contrary to popular misconception, accessibility is not an issue of "HTML supports it but Flash does not". The Flash Player has supported accessibility features equivalent to HTML for several releases now and this support is baked into Flex (although not, unfortunately, enabled by default - be sure to compile with the -accessible compiler flag or by setting the "Generate accessible swf file" option in the Flex Compiler page of the Flex Builder project properties page. Instead, it's an issue of "rich" user experiences versus cookie cutter widget-heavy UIs. Widget-heavy UIs are easy to make accessible in Flex and HTML, but richer experiences built in AJAX or more fluid Flex techniques require more work to achieve minimum section 508 compliance. Yet it's these very techniques that create more usable and enjoyable user experiences on the web.