Posts Tagged ‘priority’

Wireframe-Mockup Hybrid

Tuesday, January 5th, 2010

Recently, a visual mockup technique by Alex Faaborg on the Mozilla blog caught my attention. As Alex has been thinking about the merits of searching and browsing through bookmarks and history for the next Firefox version, it seemed like in a way he merged the traditional wireframe with a detailed mockup. While parts of the interface schematics are faded outlines devoid of any colour, other parts are represented in full colour and contain rich depth. Interesting? This effect enables the designer to emphasize the more important parts of an interface and focuses the viewer’s attention on what matters most. These wireframe-mockup hybrids perhaps reaffirm the importance of designing UI parts in the right fidelity and at the same time remind us that it is ok to leave stuff out.

Credits: Alex Faaborg

Prioritized Stickynote Requirements

Thursday, September 17th, 2009

Des just sent me a link to where he describes his early design process with a few whiteboard wireframes. One thing he does is create some sort of inpage requirements with the help of sticky notes which are placed alongside the UI work for inspiration. These rough and abstract textual ideas or requirements guide his thinking during the wireframing process. More so, he goes even further and uses colour coded stickies to denote priority.

In his own words:

They’re colored by importance. For this project it was:
Yellow = super important, site is useless without
Pink = nice to have, but requires restaurant owners to do some work
Orange = social features, relies heavily on people using the site (might not be there at all).

At the same time, I also found it very interesting that Des explores variations or alternatives as not to fall into the pattern trap. There is another interesting article related to this which he wrote about, Thinking in Patterns, on his company blog.

Credits: Des Traynor

Emphasis Techniques in Sketching

Tuesday, May 26th, 2009

Just found these layouts on flickr belonging to James, which rely on a number of interesting emphasizing techniques. These include:

  1. Border thickness – thicker lines definitely are a quick way of making an element stand out.
  2. Tonation – darker backgrounds (in this case with the help of diagonal lines) can be used to emphasize an area (also see Matthieu’s sample).
  3. Isolation or incompletion – it’s very easy to draw attention to a particular element’s importance if the sketch is incomplete or only partially drawn (the sample by Jonas shows this nicely as well).
  4. Depth – drop shadows or three dimensional drawings are a quick way of making elements come out.
  5. Size – smaller sketches of course are less emphasized than bigger ones (see Little Frames).

Although not present in the above example, applying some colour to a sketch can also be a way of underlining desired elements.

Overall, emphasis is quite central to sketching as it sheds light on what is important and varies the visual priority. A sketch can also indicate its importance not only to the people being presented to, but also straight back to the original designer of the sketch. In The Reflective Practitioner, Donald Schön writes that design activity is a form of dialogue between the designer and the material of the situation. In other words, sketches, wireframes and prototypes are all things which in a way talk back to us. In this dialogue like metaphor, once an idea manifests itself in a visible form such as a sketch, it often leads to new ideas and the “conversation” continues on. Visual emphasis in sketching then plays a central role in keeping such cyclical dialogue alive.

Credits: James Bates

Pattern Based Sketching

Friday, May 15th, 2009

Ryan Singer of 37signals has written about and recently reaffirmed his satisfaction with a sketching technique he uses. The technique is inspired by Christopher Alexander’s book, Notes on the Synthesis of Form, and supports a number of important design qualities. It abstracts the starting point away from the specifics of UI elements, toward requirements or design considerations such as human needs, tasks or behaviours that are to be fulfilled. The technique emphasizes the interaction and forming of relationships between various requirements into manageable chunks or patterns. Prioritization of these patterns is then suggested. Finally, this approach also affords the exploration of multiple alternatives for each pattern or chunk followed by a unifying synthesis. In the end, the central ideas of Alexander are about letting design ideas emerge into unified and contextually fit forms.

Here is how Ryan describes the approach:

1. List all the things a screen should do. What should the customer be able to accomplish? What information are you sure should be displayed? Which affordances are necessary for customers to start a process or reach a goal? Label these things with numbers.
2. Look for any numbered items that relate to each other, conceptually or spatially. Label these groups of numbers with a letter.
3. Sketch a design (or multiple designs) for each number or letter group.
4. Combine the individually sketched blocks into a unified design. Let the pieces fall together into a whole.

Credits: Ryan Singer

Page Description Diagrams

Friday, April 3rd, 2009

Page Description Diagrams are pretty much wireframes devoid of any layout representation. Page content chunks are described textually and also prioritized on a horizontal axis.

Here is a snippet of what Tom, of Blue Flavor, writes.

One of the main reasons why I love pdd’s is that they effectively remove visual design and layout-based discussions (which should be reserved for the visual design phase of the work) from the IA process. Presenting and discussing only content forces a client to focus on choosing what is and isn’t really important on a given page, helping to communicate their core message.

In addition, a good article on PDD’s exists over at boxesandarrows, and Garrett Dimon has posted a PDD template for Visio.

Credits: Tom Watson

Prioritizing Elements with Numbers

Friday, March 20th, 2009

The bubble frame has stirred up some commotion on twitter the other day, and Tyesha reacted with her own variation. Her sample however sheds light on something else – the idea of prioritizing elements. She uses a very simple tactic that relies on numbered circles to denote the importance of an element. The really nice thing about communicating thoughts on priority in such abstract ways, is that it creates more flexibility for a visual designer to interpret the representation. This perhaps gives the designer more room to apply his/her own expertise as well.

I find it really interesting to see information architects thinking of such priorities behind various items on a page. There seem to be quite a few other ways in the realm of visual design which can be used to increase or decrease importance. Some less direct tactics include: the control of element size, emphasis through isolation, variance of depth (foreground, background), and of course a recent example that denotes priority with the use of tone.

Credits: Tyesha Snow

Wireframing Visual Priority with Tone

Thursday, 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