Annotation Droplets

January 30th, 2009


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

Little Frames

January 28th, 2009


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

Colouring Clickables in Wireframes

January 25th, 2009


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

Wireframing Visual Priority with Tone

January 22nd, 2009


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

Specifying Form Elements

January 21st, 2009


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

Error Handling in Wireframes

January 19th, 2009


As we begin to think about, sketch and specify multiple interface states, it quickly becomes apparent that error handling is one potential candidate which is rich in state complexity. Looking around for an example of how to document errors I found a very interesting sample of such an error wireframing technique. Minoru Uchida has agreed to showcase and share it here.

The technique is quite simple. Similarly as in the previously described In Page Events example, coloured lines are used to denote user actions. If however there is a conditional error, a red arrow is used to guide the reader to a new page section with the error message in red. The nice thing about this technique is that the page can be further divided horizontally and only a few elements which change are duplicated. The remaining elements such as the header and footer are shared across the full page.

Credits: Minoru Uchida & Mark Hines

State Based HTML Wireframes with Polypage

January 17th, 2009


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.

The technique was initially developed at Clearleft, and Richard Rutter explains how to use it better. Here are two more sets of wireframes using this technique which contain more page states to explore.

As a side note, here is also an interesting debate as to whether these things are wireframes or prototypes.

Credits: Ben Sauer

Push & Shove Rules

January 15th, 2009


Changing elements on a page can be forceful. Traditionally, the popup or the dialogue box is an example of a rather unforceful behaviour where the overlaying element does not affect the underlying interface. It appears on top and nothing underneath changes other than a drop shadow or a grey out. This does not have to be the case however. One example of such more forceful push and shove behaviours can be seen during dragging operations. Bill documented this nicely in such a diagram. As an item is dragged and its position changes, the surrounding items are affected as they are pushed around. Using key frames, one can imagine the underlying rules during such an operation.

Finally, these push and shove rules do not have to be limited to dragging alone. As RIA elements become more flexible to resizing, dragging, animating or any other positional and size changes, such behaviours could be considered.

I found this example on Bill Scott’s superb companion flickr page for his upcoming
Designing Web Interfaces book.

Credits: Bill Scott

Stickyframes

January 13th, 2009


There is a fuzzy line between what constitutes a paper prototype and a wireframe sketch loaded with sticky notes. Although Danny originally tagged them as prototypes (which is perfectly valid in my opinion), I would like to expand the possibility that such design representations may have uses beyond paper prototyping. Instead, sticky paper can also be used in the conceptualization stage in which wireframe generation and sketching fall into. Could this then be called a stickyframe?

Stickyframing, or the idea of using sticky notes combined with sketching can bring great value for a design process. The strength of such a combination is the decreased effort for changes or modifications provided by stickies, while at the same time having the immediacy and flexibility of ideation that sketching allows. Sometimes during paper sketching we’ll draw out an interface element and then we’ll want to reposition it. At other times, we’ll want to redraw an element while the remaining interface parts are perfectly fine. In both of these situations, we’re often forced to redraw the whole page view as we generate more design knowledge. Stickies of course help combat such inefficiencies.

On the same note, an emergent thought comes to mind which further could extend stickyframes – digital photography. Just the same way as Danny Hope took pictures of the various page views and posted them on flickr, the same could be done in a design setting. Photography could not only allow for the various interface states to be frozen as a future reference. More so, photographing sticky wireframes could allow for a reuse of various elements (or their states) across different pages. It’s just a thought, as the fight for increased document agility continues on.

Credits: Danny Hope

Isolated & Referenced Elements

January 12th, 2009


This is an interesting sketching technique provided to me by Jonas Löwgren, which separates individual interface elements from the page. Here, individual elements are taken out from the page view and then referenced back to a mini version of the page which contains a structural representation. More so, the page structure only lives in one area (the centre). Nearby each sketched element there is also some faded hinting of what is around the element. Taken together, this increases the speed in which the sketches can be generated, as there is less need to redraw full pages with all other elements.

Secondly, this technique also has the strength to emphasize particular elements as they speak back at us with a louder voice. The isolation of various items, freed from the page view makes them stand out more. There are also other submitted samples (here and here), which also made use of this technique in a wireframe context.

Credits: Jonas Löwgren