March 9th, 2009
Here is an interesting way of approaching state changes using UML notation, and more specifically state charting. Perhaps the learning curve of documenting such technical interactions is not the lowest. However, once the team agrees on using such an advanced notation system, the represented interactions and state changes can be explored with greater accuracy and detail. Some interesting symbols include: loops which imply refreshes; brackets which suggest conditionals; forward slashes which suggest system actions; and larger rounded area containers representing nested states which are always accessible.
Yohan also sent me two interesting UML references. One simpler PDF reference explains very well the notation used in the above example, and a second extended reference explains additional UML diagramming notations.
Credits: Yohan Creemers
March 6th, 2009
Here is an interesting technique which uses multiple pieces of tracing paper combined with sketching and scanning. It kind of reminds me of Photoshop layers except these exist in the real world. First, Jennifer drew various interface elements separate from each other on tracing paper and overlaid them together to form full page screens. These various combinations were later on also digitized using a scanner and then shared with others.
This technique shares some similarities in terms of flexibility with sticky frames. Just as with stickies, the designer can undo and rearrange elements very flexibly. Also, similarly to the sticky frame example where the designer used photography in order to reuse the various elements (and speed up the design process), here a scanner performed the same function. Tracing paper however has an additional characteristic of allowing to represent interesting transparency effects as is visible in the top right example suggesting an overlaying lightbox image. Tracing paper perhaps also affords a little bit more change and rearranging than sticky notes. All in all, such awesome tactics provide us with more speed and agility.
We’ve also found that sometimes taking your design out of the computer screen forces your audience to focus on the concept rather than the execution, which is very helpful if your audience gets hung up on colors and buttons and the like. Frankly, it’s helpful to everyone involved: good design, I feel, serves the content, and all the flashy Flash/AJAX/JQuery what-have-you won’t save a poor design. I also believe that while good web design does not translate into good book design, etc., every designer should learn to use paper and pencil. Like the codex, it’s worked for 500 years; it’s not going anywhere soon.
Credits: Jennifer L. Anderson
March 4th, 2009
Sometimes the designer wishes to focus feedback and discussion only to certain areas of the interface. Knowingly that firmer and more defined styles suggest completion, while empty spaces and sketch styles invite discussion, the designer here has utilized this knowledge to channel feedback. This sample is a hybrid between a wireframe and a sketch. It has been started off using the computer and then printed out, while leaving a central area blank for sketching with the stakeholders. This interesting combination suggests to the stakeholders very clearly that the computer based areas are more defined and less open to feedback while the empty and sketchy areas are in need of refinement and more open to input.
Credits: Hans Nieuwenburg
March 3rd, 2009
As the fluidIA side project is rolling forward, I thought to drop a quick announcement here that some interface sketches about how the new prototyping tool could work, have been posted today. I am doing some quick design this week, followed by some development next week. So if you feel like sketching additional or alternative ideas, feel free to send them over to me and I could post them up as well. If sketching is too much, I’m also open to feedback through commenting (on the fluidia.org site) or by email. Cheers. Jakub
March 2nd, 2009
Jumping over to the computer does not necessarily mean that the wireframe ought to look rigid and clean, suggesting a higher degree of completion. Occasionally, the designer still feels the need to communicate the interface with a style which invites change by suggesting incompletion. One way of doing this is by means of a more sketchy style. Here is a sample of Hans using Visio loaded with a sketchy stencil designed by Niklas Wolkert. Jonathan Abbett has later on revised the stencil here.
Credits: Hans Nieuwenburg
February 27th, 2009
The need for flexible design documents such as sitemaps has already been noted in the past. In this example however, instead of using the computer, a very similar style of exploring and representing site structure has been accomplished with the use of sticky notes. Indentation has been applied to the stickies in order to suggest multiple levels of structure. Why not just do it on the computer then? Well, I think that such a rough approach invites more collaboration and input from others. Paper, sketching and stickies all invite change and feedback more so than computer based tools. Here is what Dave has to say:
It is an early stage in the development process, and the use of post-its allows quick iterative thinking, and opens collaboration across the project team. Taking photos at different stages meant that versions can be kept. This was the final version, before being drawn up in Illustrator for client sign-off.
Credits: Dave Needham
February 25th, 2009
A sketch drawn up by an interaction designer and a sketch drawn up by a visual designer will emphasize slightly different things. An interaction designer likely will focus more on multiple element states, and events (or links) which glue them together. Whereas someone with a more traditional visual or graphic design background will put extra effort on sizing, alignment, positioning and visual priority, which all work together in establishing proper visual relationships between elements. This second case is perhaps visible in a sketch submitted by Mike. The sample here makes use of graph paper, straight lines, and explores block and element relationships.
A sketch like this is just more evidence that the wireframe overlaps greatly with graphic design – a case made earlier. This overlap suggests once again that the wireframe can be grounds for collaboration between information architects, interaction designers and visual designers.
Craving more graph paper? Konigi provides a number of awesome stencils aimed at IA’s and visual designers which can be downloaded. Of course writing about graph paper and wireframing, one could not overlook another awesome blog about a similar subject matter over at graphpaper.com.
Credits: Mike Rohde
February 23rd, 2009
At least two rough sketching tactics can be identified in this submitted drawing which make it lean very much toward the low end on the fidelity scale. First of all a great deal of the text has been represented using simple squiggly lines as opposed to using real words. Secondly, the interface page boundaries have faded as some elements have been drawn floating independently of any screen edges. Such roughness has definitely a place while designing as it provides ever greater speed of generation. This value does come at a price however as hinted in the previous entry. The lower the fidelity, or the rougher the sketch, the more difficult it may be to understand by others and thus it may require support by explanation.
Credits: Darren Azzopardi
February 20th, 2009
Recently as I was thinking about an assignment of designing a new playlist system at work, a number of ideas collided all into one and resulted in this design sample. The desire was to explore alternatives, quickly, of high level activities, which would have to support interactions between a number of actors or people. So I jumped back into pencil, paper and marker mode. As simple or obvious as it may seem, what I think might of worked well worth noting is the use of colours to denote different (or same) people. Another thing that perhaps worked out was the use of one activity as a starting point in the center and then branching out toward alternatives.
I think this little sample was influenced by other’s work as well worthy of noting. First of all, here at TU Delft we were exposed to quite a bit of mind mapping exercises which in a way resemble the interface sketches of Jonas Löwgren. Then again, this sample also shares the high level characteristics of a user journey submitted by Steve Johnson. Finally, as I’ve written in my personal blog I’ve also began questioning the sterility of one path user flows wondering about how to explore the diversity of activities.
The sample isn’t perfect, and as is argued in Pencils before Pixels, the lower the fidelity of the sketch the harder it is to use it to communicate with others. However when I showed the sketch to others, and supported the sample verbally, it enriched the conversations.
Credits: Jakub Linowski
February 19th, 2009
Here is a sample revisiting the problem of exploring multiple element changes all over the screen as a result of an interaction. Traditionally a full wireframe would have to be redrawn in order to document such subtle and multiple changes. Here is a quick solution that avoids having to wireframe the full page and thus decreases effort and increases document flexibility. Fabian has achieved this by combining state based wireflows with miniframes which act as references for the elements which do change. Overall, this document reminds us of an important consideration relevant in wireframing richer interactions. This being that one interaction can have multiple element reactions. Just to recap, Bill Scott has used an alternative method of documenting a similar case with a multiple elements & state conditions matrix.
Credits: Fabian Nöthe