February 11th, 2009
Sometimes it’s better to design collaboratively in the open instead of doing it from the safety of the solo oriented computer. If done right, more feedback can be harnessed quicker with higher quality returns. Agile programmers have been doing this with their paired programming approaches which apparently pay off by diminishing bugs and increasing code quality. Here is a sample from Michael drawing up wireframes on a whiteboard for the redesign of Jive Software’s website – visible and affording collaboration.
Credits: Michael Sigler
February 9th, 2009
I would like to announce fluidIA.org, a second project of mine with the intention of creating an open source and agile UI prototyping tool. The project is just beginning but anyone who would like to contribute in terms of design ideas, comments, or code is more than welcome. The site is still evolving as I am the only who has been working on this project since March of last year. I assure you however it will evolve. I might post another thing or two about the project here in the future once things start rolling. If you would like to work as a designer (by submitting sketches, wireframes, or other visuals) on this design tool with me, then please email me. I will be handing out accounts allowing to post and upload images. Enjoy. – Jakub.
February 9th, 2009
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
February 6th, 2009
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
February 4th, 2009
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.
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
February 3rd, 2009
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
February 1st, 2009
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.
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
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
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
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