Think Vitamin's Clive Howard says "Wireframing is one of the first steps in your planning process and arguably it’s one of the most important ones." In this article, Howard goes through the wireframing process, discussing who should be involved, which tools to use, and offers sound tips to enable you to make better wireframes.

Among my favorite points are those about ownership and involvement. This is to do with ensuring that someone is driving the process and iterations, and making sure that the interaction design process doesn't happen in a vacuum, but is reviewed, validated, and informed by key team members, e.g. engineers, as you're creating them.

I also like the points about fidelity, and avoiding doing too much design. That said, if you're also the visual designer, or can base the visual language of the wireframe to the visual language of agreed upon visual design specs, then I don't see a problem doing that.

What I don't agree with, is that you want to avoid designing behaviors such as Flash or AJAX. Wireframes, storyboards, and sketches are the precisely place to explore how websites and applications should behave. You needn't be as specific as specifying types of transitions, just generalized behaviors and relationship to system logic. If you don't specify behaviors, decisions will get made without your input. If that's fine with you, leave them out. But you're supposed to be the expert on your users, how they've modeled the site or app, and what they expect to do there.

Lastly, one point that is missing for me is know how to pitch/present the wireframes. These aren't just documents to be chucked over the wall. While they should be able to stand on their own when it comes time to design or develop what you've specified, your job is not done when you've shipped the doc. You have to present and justify, explain details, and answer to questions that will undoubtedly arise about how things behave. For this reason, I rely very heavily on annotating wireframes and storyboarding behaviors. Those questions will need to get answered eventually. If you don't think you deserve to be in that conversation, leave them out, because someone else will make those decisions without you. But if you intend to be involved in the user experience, why not be involved in every aspect of design, and make sure your wireframing process allows others to be inform what you produce.

There's quite a bit of good stuff in Howard's points, so be sure to read the article to find out what each of the bullet points above refer to.

The JQuery'd Breadcrumb is an odd breadcrumb interface that collapses all nodes in the branch upon page load, and then expands to show each node the user mouses over. Their explanation:

This collapsible breadcrumb was developed to deal with deeply nested, verbosely named pages. Rather than limit the amount of elements shown on the sever side, we decided to go with a client side solution for usability and SEO reasons.

I don't see how this is a usability improvement over an exposed breadcrumb. If they needed/wanted to use breadcrumbs for whatever reason, it would seem more usable to show a larger truncated portion of each string with an elipsis, and expose the string on hover, rather than just show these strange portions of the string. I don't even see the whole first character, so it just looks kind of broken in a way.

I like the attempt to do something about minimizing breadcrumbs in deep paths. But it might even be more useful to use something like the path control we're accustomed to in the Finder and Windows Explorer. You'd have to do a lot to make it look less like a form control to make it unobtrusive, but provide some context. Do it with ULs and CSS, and I think you'd still be ok with regard to SEO, although someone might correct me if I'm wrong. I don't know why you'd allow horrendously long titles as in their example, but clearly you don't need to have the current node in the branch visible if the point is to minimize the weight of this UI element.

The New York Times' Article Skimmer prototype provides a nice gallery view of top articles, and utilizes a categories sidebar to filter articles. Keyboard shortcuts are also provided to navigate prev/next category, or to jump to a specific category. Very nice way to view articles. The dense tabloid style of the regular site can be overwhelming sometimes.

Via SwissMiss

If you've been following this blog, you may know how I've wanted to do sketch/jitter line styles in OmniGraffle to produce sketchy diagrams and wireframes. After David's demo of his method for doing sketch shapes on the Design Commission blog got me started figuring out how to get the effect natively in OG, I've started to finally create sketch versions of the Wireframe Stencils. Above is a screenshot of the forms set. I expect this will take me a few days, but hope to release these in a few weeks.

The New York Public Library Labs has begun testing a light usability testing system to supplement their formal tests, inspired by the Five Second Test method which was devised by Jared Spool and turned into a service by the guys at mayhem(method). The service, nicknamed Infomaki (info roll?), combines the type of service 5 second test provides, as well as allowing single question surveys for checking on things like simple labeling issues, which you might have tested using card sorting.

The test lets you answer only 1 question, or continue answering as you like, which makes the task feel very game like, and reminds me of crowdsourcing apps like Amazon's Mechanical Turk. I love that the types of questions you can ask require simple twitch-like responses, so you can get through a lot very quickly. Here's a bit more from the NYPL Labs site about the project:

It has become apparent that we needed a tool in our kit that would allow us to get simple usability questions in front of users with a minimum of fuss.

[O]ften, what is needed is just a sanity check– a reassurance to our team that we are on the right track.

Our design sessions frequently result in debate about which of two words is more compelling or accurate for our users, or whether a particular button is noticeable in a particular location. When we can, we test designs on real people using paper or digital prototypes, but it is impractical to test every day; sitting down with real people is not always as simple as you’d expect, what with the schedules of busy New Yorkers.

We’ve used SurveyMonkey in the past for full-fledged traditional surveys, and we’ve also evaluated OptimalSort for online card sorting, and been inspired by the Five Second Test. But none of them were a perfect fit, for reasons including complicated interfaces, inflexible setup, privacy policy hassles, and/or lack of a way to embed a link back to our site when the test is completed.

So, we set out to create our own rapid-testing usability laboratory from scratch, and last Tuesday we launched it, in rough beta form.

Having worked on information systems in research libraries, I'm always excited to see libraries that are ahead of the curve in terms of technology, and the NYPL never fails to impress. The NYPL Labs is testing the system with a small number of usability questions related to NYPL sites now, so you might get some repeat questions, as I did. It would be great if the system could cookie sessions to ensure that questions aren't repeated. This is a terrific start though. The NYPL Labs plan to release Infomaki as an open source application, which is great news for us.

Requested Reading Recommendations from the School of Visual Arts, MFA in Interaction Design program.

Upon the request of readers, we asked faculty to recommend books for an interaction design reading list. These could be landmark texts, underdogs, or critical reads, or stepping stones to other fields. The following is what resulted from our request, comprising in part: a sneak preview of what will be assigned in courses; what some consider to be cornerstone interaction design texts; and what some consider important connections to other fields.

Joshua Porter's post about whether good design can be replicated is fabulous. What I like is the idea that there isn't a solid set of methods that you can reuse in every case and think it might guarantee success or "good design". There's an interesting thought in there about process:

I wonder if the real issue is that most of the time designers simply don’t know if what they’re building is great, and they end up relying on process to get as far as they can. If they go through the right process, they think, then they’ll produce maybe not the best solution, but the best solution possible. This may be true…and it is comforting, in a way, because if you feel like you are doing it right then you can sleep soundly.

Couldn't we just say that all this activity that leads to design, whether it uses one methodology or another, just helps frame the problem and start the discussion about understanding what you're trying to solve before the eureka moments hits. We're not talking about sticking to rigor here, but maybe using tools and methods to get to some moment of clarity before carrying on to the design that can now be given focus.

The Michael Bierut passage is a great one, in that he suggests that he works at the problem in one way or another until the solution manifests almost magically. And Joshua suggests that perhaps it's just hard work, and I would say experience, that makes good design. I'd side with that opinion, if I had to side with anything.

I love what tiny gigantic has written in this great short post about designing by writing (or the non-iterative design process). I agree wholeheartedly, although I think of writing as part of design to be accretive and/or iterative.

A few choice bits from the entry:

[W]hen someone asks you why you used green, or why you included that crumpled-paper background, or why there’s a bird in the logo, you’re gonna need to know. What’s more, you’re going to need to be able to articulate it in a way that makes them care. I’ve been in graphic design classes in which I’ve asked students presenting their work why they did what they did. And 90% of them have said something like: “because it’s like, I don’t know. It’s like I thought that color looked super good right there. And I like birds.”


It’s not enough to make pretty things. You’ve got to be able to talk about them, to present them, to parse their meaning. And the truth of it is that if you can’t articulate what the thing you’re making means, you’re gonna have a helluva time making it mean something to someone else. Which is a problem, because that’s the job.

I like to write before I do anything related to interaction design. I like to read, gather and summarize loads of user feedback, to talk among my team about ideas we have to solve problems, and then distill it all into statements of the problem, proposals for design concepts, and stories (use cases and scenarios). This is all the intellectual work of design. Where I work now, it happens in a wiki article with users adding paragraph comments, all before I start to sketch. Then it continues to happen when my team annotates sketches.

In any case, the point is that the thought process that leads to design is what's important, and if there is none, then maybe writing can help in that case. Perhaps not everyone needs to write so much as communicate and capture in some way, even if it's only in discussion and notetalking or what have you.

Interesting discussion in M. Jackson Wilkinson's blog about the altnernatives to hierarchical sitemaps, and the use of concept maps or user flows as alternatives when hierarchy doesn't work in your documentation.

I have to agree with one point, in that site maps don't always serve documentation well when the notion of a strict hierarchy just doesn't exist. But I think there's utility in sitemaps at conveying the organization of a site or application at some level. It may be a very high level visualization that maps concept model/mental models to navigation or application menus, and provides a way for a team to visualize the connections between what the user sees and what the system represents in UI.

I don't do sitemaps very often anymore, especially when working on application design. They get you far enough in terms of conveying a 1,000 foot view of the landscape, but the meat of the documentation seems to be in uncovering topography. And that can be the stuff of quite a few deliverable types, including user flows, use cases. A nice list of deliverables that might be suitable is in Peter Morvilles' UX Deliverables run down.

Creatica writes about the redesign of FaveUp, which will be relaunched as Creatica Inspire. The lengthy article discusses the process of designing Creatica Inspire and includes links to HTML mockups for the new site, and for illustration purposes shows the evolution of PSDtuts, which will also come in line with the new Creatica family of sites. Great read for anyone considering redesigning an existing site with an established set of users, especially with regard to improving funcitonalities, IXD and IA, without upsetting users.