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.

Along the way we’ll share some of the tweeters, books, and resources we found useful for budding information architects. Even if you’re familiar with the discipline already, you can probably pick up something you’ve missed.”

From UXBooth. This article is comprehensive but the data is presented in neat little boxes, for example, links to the Twitter addresses for several information architects and links to software used to create information maps, not a ton of prose. But the insights are thorough. Information architecture is both a distinct skill set requiring you hire someone to do it and a skill that business and software program managers should possess.

Possibly the biggest mistake in any development project is failure to plan. Recently, the owner of a prospective start-up told me that planning was unnecessary and a good developer could just start coding. This, I promise you, will end in tears.

Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones. This is when the idea starts to take shape as an application, becoming boxes and buttons that users will interact with. This article will take you through a wireframing process; who should be involved, the tools to use and tips to enable you to make better wireframes.”

From Think Vitamin. I chuckled when I read the first paragraph above. If only it were that easy to develop online applications. Been there, done that. This is a quick but highly useful checklist for developing wireframes, whether you are a business person or an interface designer. I especially recommend #9 (UI is not UX) and #14 (Look for Repetition).

As a writer, I notice that a lot of business processes like wireframes are similar to writing. Repetition, in particular, is both a boon and a curse. With interface design, repetition can help people learn an interface more quickly but it also can make a user’s eyes glaze so they become blind to parts of the interface.

From Adobe’s Developer Connection. This is a clearly written, easy to understand, overview of prototyping for interactive design, what prototyping is, how it’s done, and its limitations. Includes a link to an interesting article about how to use Adobe’s Fireworks to create prototypes.

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.

From the Mind Mapping Software blog. I’ve got way too many pages of iPhone apps on my phone so I’m a sucker for new software. These look particularly good for mapping ideas when you’re not near a desktop or laptop computer. Of the 8 software tools reviewed, Zeptopad looks the neatest with its ability to hand draw objects and relationships.

From UIE. This is a good overview of how you can take interactions within a software application, and across software applications, and distill them into patterns. Doing so helps reveal some of the strengths and weaknesses of those interactions. More importantly, thinking about interactions as a pattern helps identify opportunities to improve the interactions. And maybe even subvert or replace an interaction with something more direct and useful.

From Boxes and Arrows. Designers taking control of software interfaces can be a good thing and a bad thing. You start, of course, with common user assumption, for example, most software follows the Microsoft model and has the upper left navigation begin with File which leads to file management choices on a dropdown list. But these assumptions should be challenged over time and so this trend should be a good one.

What I liked most about this article, however, is that it is a great overview that explores how photos are used in software. For business people, it’s a great way to build a vocabulary that lets you discuss what you really like or don’t like in a software application that uses photos.

From Wireframes. This article makes a nice contrast to the Boxes and Arrows article about using XHTML for designing interactions within software applications.

In contrast to wireframes, XHTML is a standardized notation, anyone who knows XHTML can read your document. More importantly, it is a language spoken fluently by a key target audience of your design documents, the developers. And those who don’t know or care about XHTML can view the part they do care about, the page design, by opening the document in a browser.”

From Boxes and Arrows. It took me awhile to get the point of this article but it’s a terrific argument for using XHTML as part of the interaction design process.

From Boxes and Arrows. This is a moderately technical discussion of how best to use patterns in interaction design. They also discuss how patterns and style guides compare and contrast. And the use of patterns and pattern libraries as competitive secrets, even patent-able.

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.

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.

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.

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.