“There are three basic approaches to conducting quick remote interface tests, whether you’re testing live websites, designs, wireframes, or prototypes. The approach you take will depend mostly on how you feel about people—do you want to talk to users face-to-face, or use one of the many new UX tools and let computers gather the information automatically?”

From A List Apart. Really practical and thorough with lots of links, funny (choose your usability test method based on whether or not you like talking to people), and mentions my favorite free screen sharing application, Adobe Acrobat ConnectNow, that works with any operating system, Macs included.

URLs

http://www.alistapart.com/articles/quick-and-dirty-remote-user-testing/
http://www.adobe.com/acom/connectnow/

“To date, the most common approach to propagating a single user experience standard is the development of UI guidelines and principles documentation within an organization. Development teams — usually incorporating a user experience specialist — then reference this documentation during implementation and upgrade processes.

However, as the numbers of systems grow within an organization, so does the effort needed to maintain the quality and consistency of the user experience. For many organizations, it is now impossible to assign much, if any, time of a user experience specialist to all implementation efforts, and experience has shown that the UI guidelines and principles approach to propagating a single user experience standard does not scale well.”

From Boxes and Arrows. Besides a quick discussion of issues around how traditional guideline documents don’t scale, and alternative solutions, this article includes an excellent set of links to UI pattern libraries.

“Such problems often come from trying to make a Web site accessible without understanding how people with disabilities actually use the Web. The challenge for UX designers is to find ways of including real people with disabilities throughout the design process, starting with initial user research and going all the way through final usability testing. This gets back to the issue of familiarity. The more we include people with a range of disabilities, the easier it will be to anticipate effective ways to design for them.”

From UX Matters. This article makes the case for including accessibility into usability testing, as well as some of the issues involved when well-intentioned rules actually make it harder for people to access a site, for example, using alt tags to restate what a screen reader already provides. Includes quite a few good links to other resources on the topic.

“Unfortunately, we’ve found that many teams don’t know how to iterate effectively. Good iteration is a deliberate activity, with four important stages: planning, implementing, measuring, and learning. The best teams focus on each stage appropriately, making sure they get the most out of it. While iterations can be very short, (we’ve seen teams that can iterate a dozen times in a single day,) the best teams don’t short change any of the stages.

If you’re familiar with Agile development, these stages will sound very familiar. That’s because there are parallels between the types of iteration we do when designing great user experiences and what developers do when building applications. The big difference between UX iterations and Agile iterations is that most Agile iterations focus on coding something, whereas UX iterations can have alternative deliverables, such as wireframes, or persona descriptions.”

From UIE. While this process works for usability testing and interaction design, it also works for solving any problem.

“It starts with any number of scenarios: Design and development have taken too long to produce a prototype, you need to release in three weeks, and you suspect there may be design flaws. You are trying to incorporate usability testing into an Agile development process. Or maybe you simply want to pare down your process to make it shorter and less expensive.

Completing usability testing quickly is a challenge anywhere but especially in consultancies, which have to overcome additional challenges, such as learning a new application. To assure success on these projects, I’ve developed a quick turnaround usability testing methodology (QTUT) that minimizes the time needed to complete testing. In Part I of this article, I discuss how to make the first three steps of QTUT—Sales & Kickoff, Recruitment, and Preparation—as short and efficient as possible. In Part II, I will discuss the final two steps: Testing and Analysis & Reporting.”

From Boxes and Arrows. This is a thorough overview of both the traditional usability process as well as an abbreviated way to do usability and still get meaningful results.

“I often tell clients that IA [information architecture] establishes the baseline, or foundation, for a solid site structure. It helps create the traffic patterns and navigational routes that get the customer from A to B in language that is helpful and easy to understand. In fact, IA is the first step in meeting customer goals and can therefore increase brand awareness and product or service sales.”

From A List Apart. This is an excellent description of what information architecture is and how it benefits the business and helps keep projects on track. Includes gory details like deliverables and how they work. Photo from Flickr by Kaeru.

“People constantly ask me what the best prototyping or mockup tool is.  My standard answer is “whichever tool you are most comfortable/experienced with.”  But just to cover all the bases and make sure that I’m not missing out on the “silver bullet”, I decided to do a review of all the tools that I’m aware of.  You could (and probably should) distinguish between pure mockup tools (e.g. “Pencil”) and tools for creating interactive prototypes (e.g. Adobe’s soon to be released product code named “Thermo”), but for the purposes of this matrix, I lumped them all together, and I noted which have interactive capabilities and which don’t.”

From Russell Wilson at Dexo Design. This is a very thorough matrix that describes many different tools based on task as well as functionality and technology. The comments also include a lot more useful information.

“So my choice of using FW for prototyping is most definitely not a statement about it being a great prototyping tool overall, just that it works great for me personally because I can go all the way from wireframes to final design within the same app. That’s going to be one of the main things I was going to demo – recycling art assets from the wireframes to the final visual mockups.”

From a thread at IxDA about using Fireworks as a user interface prototyping tool. The thread includes a link to an article, Review: 16 User Interface Prototyping Tools, as well as a Meetup notice for Tuesday, February 17, 2009 at 6:45 p.m. in San Francisco where the person who started the thread, Al Abut, will speak and demonstrate how he uses Fireworks to prototype.

“The user experience team members learned to speak the same language by collectively discussing our ways of working and our deliverables. This process started with the kick-off workshop, continued during the review process of the diagram and deliverables descriptions and continues to this day when we discuss how to combine smaller artifacts into project deliverables. This discussion translated into fewer misunderstandings about the contents of a document, the kind of activities expected and the required input. It increased the consistency of our work. Because each project’s deliverables were chosen from the same total set, we could reuse previous documents as examples or templates. This re-use in turn allowed us to document our work faster, leaving more time to study our design’s completeness, quality and effects on others.”

From a Feb/Mar 2005 ASIS&T Bulletin. Found through an IxDA discussion thread that includes links to a blog post by Peter Boersma and slides (see below).

While these materials are older (aren’t we all?), this is a high level but thorough discussion about how to organize then integrate standardization of information architecture deliverables within any software development organization. Since 1995, when I first was paid to do web work, the field has evolved into a vast array of job roles and specialities. While it is useful to know a little about all the roles, and how they fit together, the real challenge is to do what is described here, to integrate the roles, starting by optimizing each role. These items describe information architecture but they also apply, and evolved, into other roles.

Overall, I thought this was an excellent introduction to the problems involved in integrating the different specialities involved in creating web applications.

“I think it is quite common for UX folks to view design as problem solving. For me, designing through the use of wireframes is a search in a problem space of alternatives; it’s a process of problem setting as much as it is a process of problem solving, which means that I always start with the context. To simplify, I pick my primary audience and the one activity which allows them to solve one goal quickly, effortlessly, elegantly.”

From Will Evans at Semantic Foundry, found through Wireframes Magazine, a very useful collection of wireframe related materials people send him.

While this is a short read with some interesting samples, what strikes me is that he gets to his destination first by walking away from it. Instead of assuming the requirements and other documentation are accurate, the designer ignores that material and instead tries to understand the underlying goals as a user and a human being. Then develops ideas. Then walks back towards the known world of requirements, client expectations, and all the rest. It’s wonderfully contrarian and, for a good designer, probably yields more interesting results than simply designing based solely on the refined ideas of others.

UserTesting.com provides usability testing for your site for $19/test. Their sample for Travelocity is interesting (not least because I really want to visit Waikiki). The tester talks their way through tasks defined by the customer. In the sample video, it becomes clear the sponsored ads above the web page fold distract the tester and force the tester to scroll down for the data they want. Indeed, it becomes clear the tester simply ignores these ads despite being distracted. Not good news for Travelocity on both counts. Distraction = aggravation.

The usefulness of this service depends on what you need. It looks great for getting unvarnished feedback from random testers. But clearly it is not systematic testing, doesn’t conform to standards that ostensibly remove bias, and doesn’t allow for interaction like follow up questions. And you can’t watch the tester to confirm where their eyes go as they complete the tasks. And it’s unclear how testers are selected, a key part of usability testing.

Will it help you find what’s wrong with your website, as they advertise? Maybe.

Bottomline, this seems like a great service for quick usability testing to identify problems you might have missed, as well as confirm more rigorous testing you have done. At such a low price, it is a great value. The real question is whether you need this lightweight service or something more rigorous to help improve your website.

I should note that this service won an Amazon award and has great buzz from people like Evan Williams, co-founder of Twitter and Blogger. I don’t respond to that sort of validation but you might find it helpful.

“Lists are a beautiful way to display content and information in a very easy to scan, easy to read method. Lists are found on most blogs to list posts, comments, tags, or links. In this post we will be exploring the modern practices of lists as an element of web design and I will be showing you how to design better lists to add to the overall design of your site.”

From WebDesignTuts. The article includes a massive set of examples. It’s a great way to survey all the possible ways to organize lists, one of a handful of basic tools to organize information on a web page.

“More and more applications these days are migrating to the Web. Without platform constraints or installation requirements, the software-as-a-service model looks very attractive. Web application interface design is, at its core, Web design; however, its focus is mainly on function. To compete with desktop applications, Web apps must offer simple, intuitive and responsive user interfaces that let their users get things done with less effort and time.

In the past we didn’t cover web applications the way we should and now it’s time to take a closer look at some useful techniques and design solutions that make web-applications more user-friendly and more beautiful. This article presents the first part of our extensive research on design patterns and useful design solutions in modern web applications. Below you’ll find a collection of 10 useful interface design techniques and best practices used in many successful web-applications.”

From Smashing Magazine. It’s a nice collection of ideas to help evaluate a web application design. There’s also a lot of comments worth reading on the topic.

“Ben pointed me to an interesting set of HTML wireframes which use Polypage. Polypage expands HTML wireframes or mock-ups and allows for the creation of page states. Furthermore, the various states are independent of each other and can be toggled on a small top menu to affect the page view. Say for example you want to show your wireframes to your client in the “logged out” and “first time visit” states. Polypage allows you to click through all your wireframes to demonstrate such a case. Later on when you decide to demonstrate the “logged in” state, all you do is toggle it in the top menu and continue your presentation.”

From Wireframe Magazine. PolyPage is amazing technology, although their home page is wonderfully inscrutable. There aren’t any of the usual visual markers for software product sites, for example, a big download button.

“It’s hard to imagine a form that could be simpler: two fields, two buttons, and one link. Yet, it turns out this form was preventing customers from purchasing products from a major e-commerce site, to the tune of $300,000,000 a year. What was even worse: the designers of the site had no clue there was even a problem.

The form was simple. The fields were Email Address and Password. The buttons were Login and Register. The link was Forgot Password. It was the login form for the site. It’s a form users encounter all the time. How could they have problems with it?”

From Jared Spool at UIE. His post highlights the need to look at every little detail on a web page, even simple forms. I also liked the first time user comment they got during usability testing, “I’m not here to enter into a relationship. I just want to buy something.”