Just found a nice HTML prototype sample using the CSS 960 Grid System. The CSS grid allows to align elements more easily across pages. Although it can be said that the technique is perhaps more useful for developers, some people also use it to create wireframe prototypes. In addition, Mushabar Iqbal also ported the fluid grid to a jQuery template allowing for smoother template interactions. Adam Hawkins explains how to use the 960 CSS Grid System for interactive prototyping, but at the same time warns of the inflexibility and rigidness of such an approach. Apparently, once the grid foundations are laid down and multiple pages start making use of it, it becomes more difficult to adjust the grid. Finally, a Twitter follower (wrenbjor) also provided me with a nice and elaborate list of even more tutorials on the 960 grid.

Credits: Lachy Groom

While designing, it’s not rare that at times detailing is avoided and more rapid exploration is favoured. This very much applies to wireframing as well and in particular content or section areas. When wanting to document such an area or content reference quickly, I fell into the habit of using the less than and greater than signs to suggest generic labels or variables. Using these signs allows to visually distinguish real content from the labels. In addition, this technique also allows for more granular fidelity in design documentation as some things are more detailed while others are left undefined. In a way then, using such generic labels moves wireframing one step closer toward sketching by allowing for such incompleteness.

A couple of years ago Dan Brown has also written about such different content representation techniques and also created a nice summary poster. It would be interesting however to see some stronger visual language or styling to help distinguish all of Dan’s different content representation types: actual, dummy, labelled, symbolic, and lipsum.

Credits: Jakub Linowski

How do we document states changes when the page gives way to richer interaction? Here is one sample of my own work where I began to document state changes in a separate document away from the wireframes. Having access to detailed visual samples I cropped parts of the interface and layered flow arrows to represent these interactions. Typically however, these would not be so stylistically detailed and would probably be more wireframe like, or even sketched if speed mattered more.

Now to the meat of this sample. There are at least two things that I find useful which come to mind when documenting such interactivity in detail. First of all, transitions matter. Bill Buxton recently mentioned in his latest book, Sketching User Experiences, that interaction designers have too much focused on the states and not enough about what is in the space between them. To fill the states gap I personally find it interesting to seek inspiration about transition possibilities from JavaScript events such as the ones provided by jQuery. There are quite a bit of these events available and they range from key presses to double clicks, to mouse scrolls. Secondly, I sometimes complement events with conditions. Conditions are basically some form of written logic which applies to the event. For example: sometimes a state does not change on a mouse click alone, the mouse click has to be held down for more than 3 seconds and only then the new state kicks in. To represent these conditions, I put them right under the events in a smaller font. This is just one way of doing it. If you have other ways, please don’t hesitate to submit.

A word of caution. This one can be considered a form of a detailing technique where it’s really up to your best judgement when to perform. I definitely don’t do this for all parts of an interface. As others have mentioned in the past, sometimes things like this are best resolved through dialogue with the developers while the prototype is being built. Sometimes however, when the user experience can really be affected by how these states transition, it really helps to put it on paper.

Here is also an interesting article on the same technique.

Credits: Jakub Linowski

Tara has been designing the Mozilla Community Store and did a couple of wireflows at the page level. Having shrunk down the wireframes to thumbnails, this diagram provides a very nice overview of page-to-page link relationships that the user might take. nform Trading Cards however warn us that these documents could be very labour intensive if the design changes (which I also experienced). Now what if this view was automatically generated with our favourite design tools?

Credits: Tara Shahian

Jim just sent me a very nice and developed sample of an interactive HTML prototype done in Axure. The prototype is clickable and provides a richer understanding of what happens from screen to screen. As a standalone document however, in order for someone to understand this sample they are left alone with exploration as the means to do so. So for user testing and walk through situations this works out nicely, but what about if we wanted to send this to someone else for review and have the sample communicate use on its own without the designer being present? I am now wondering if it would be useful to overlay some sort of scenarios to guide first time viewers of the sample about the most important flows. Just a thought. Jim also sent me a link to a comparison between the prototype and the final product.

He writes:

We used Axure RP for creating these interactive wireframes which we tested volunteers on, to see whether they understood the ‘flow’ of the intended site. Using Axure made it clear for the client to understand what they were getting delivered, and also to see whether we had interpreted the ‘mental model’ correctly from earlier card sorting excercises:

Credits: Jim Callender

This little design documentation pattern has been with us for a long time and yet it’s still worthy of mentioning. The idea of annotating wireframes using droplets or circles with one pointy edge is a nice visual technique. The coloured circle is what grabs the attention quite well, combined with the pointed edge that allows to reference a very specific area. Will Evans allowed me to post this sample and he also has an interesting write up on his wireframing process. Finally there is also a Konigi Omnigraffle Stencil which uses these droplets as well. I’d also be very much interested to see what others are doing in terms of annotation. If you have interesting visuals, please send those samples over! :)

Credits: Will Evans

Sacrificing details for speed can be a very powerful design approach whenever the design space is to be widened and more concepts are to be generated. Creating such small wireframe sketches, as Ash has done here, can truly be a great tactic to get these ideas out on paper rapidly. Such little wireframes ignore detailing anything textual, content oriented or behavioural in nature. These representations perhaps get at the most basic and fundamental characteristics of what makes a wireframe a wireframe. These drawings only represent element positioning and layout. Having so many holes and uncertainties, the power of these drawings is their ability to pose more questions than answers back at the designer. Their lack of detail however makes these documents also weaker as stand alone documents. These little things require hand holding and explanation in order for them to be shared with others. Then again, whatever stirs open discussion and conversation can be very valuable in the first place.

Credits: Ash Berlin

Sometime ago I felt a need to represent in wireframes everything that could be clickable or actionable. This came largely from people asking me where one could click on inside a wireframe during presentations. When I just presented black and white screens it was not always easy for them to distinguish standard content areas from clickables and people would ask for confirmation. For this reason I began using one colour, usually red, to denote any interface areas, buttons, or text links that could be acted upon. In this regard, I found that this justified and consistent use of colour worked out pretty well.

Credits: Jakub Linowski

Here is a little challenge: wireframes don’t have to be dull. I’ve seen many wireframes, including my own, represent section areas in very monotone ways by using only single values of grey or just straightforward outlines. In such a case, all elements are perceived equally. Sometimes however as a function or section is being drawn up, thoughts surface about how important or unimportant a particular area really is. Often this thought is shoved aside as information architects by definition are not visual designers and hence it’s best to leave all things related to style alone. But is this really true? Perhaps it’s too early for styling at these phases, but I don’t believe there is anything wrong with documenting (or discussing) visual priority. Matthieu does just that. He varies tones of his sections and it really helps to rapidly visualize which areas are more critical than others. Secondly, in this same sample, font size is also used to denote the importance of text.

Such techniques open up doors for dialogue between information architects and visual designers. If waterfall methods are being challenged by more agile approaches, wireframes can become less hand off documents and more discussion tools. The reality is that traditional wireframes in themselves already steal two core design elements from visual designers. These two elements are positioning and sizing. All wireframes make use of size and position for all text, boxes and content areas. In this light it only makes sense for IA’s to work more closely with visual designers, because visual designers do not just style elements. Visual designers are masters in setting visual priority and controlling element relationships using alignment, positioning, sizing, tone, colour, text size, typography, etc. Talking with them early on could only result in better interfaces.

Quoting Matthieu :

My work is also the result of a method, mostly based on a daily collaboration with Interaction designers, interface designers and marketing strategists. I never work alone, isolated, producing wireframes and then trying to impose them. It is the result of frequent exchanges and documentation on strategy, benchmark, functionalities, and methodology issues. Designing wireframes is the last and (usually) the easiest part of the conception phase.

Designing the information architecture on a page is not only about placing the elements at the right place, it’s also deciding what’s important and what’s not on an editorial perspective. The level of importance of an element is not necessarely related to its size. For instance, an “Add to Cart” button can be highly important but will only cover a very small part of the page. Putting it inside a (visually) strong box can help emphasize it.

Credits: Matthieu Mingasson

As the design process unfolds on and we begin to tend to the details, form element rules are one area which may be elaborated. From the same designer as in the previous post, comes a sample which specifies form elements in depth. Minoru documents such things as element types, multiple values, default values, character limits, validation rules, etc. Although this is not something that would be typically done in the early phases, such form considerations still can effect the user experience. Thinking about it and putting it down on paper could definitely be worth while.

Credits: Minoru Uchida & Mark Hines