Archive for May, 2009

It was very interesting that we were just recently talking about what it would take to make documentation actually useful, and a couple of weeks later I heard about a new book by the GuiMags guys (creators of a magnet-based prototyping tool for interface design) titled “The Unplugged.”

What I find very interesting about it is that as part of being a UI designer, I’ve always had a passion for creativity in general — tools, techniques, case studies, etc. — and one of the common themes that comes up in relation to Creativity and Design is that sometimes, the only way to design something right is to go analog.

Analog? Let me clarify. What I mean by that is that before you write your first line of code, before you create the first page of that design document, before you draw that first block in your call flow, you need to turn the computer off, step away from it (yes, laptops too), grab a pad of paper and a pencil, and start drafting your ideas.

I know it sounds counterintuitive, but sometimes all those software tools we’re so used to in fact hinder our creativity because they force us to adapt our way of thinking to the inherent rules and restrictions of each individual software package. We’re visual creatures: anyone can take a napkin and a pen and quickly sketch a new idea or a solution to a problem (this is my favorite book on this subject), yet those same individuals often remain quiet during design meetings and let the “creative” members take the lead role since they can create breathtaking digital images and amazing presentations with digital effects.

Next time you’re faced with a new design challenge, give it a try, unplug yourself, go analog for a little bit and let your brain and hand take control. Great things will emerge, believe me.

I was recently reading an article about the future of wireframes in the context of user interface design documentation. Wireframes have been used mostly for visual elements and became a critical building block in the early days of the web.

But since I like drawing analogies between other UI fields and the VUI field, there were a few quotes that struck a cord because of their universality:

“The object was to create as many wireframes as possible, of every screen in the entire site, in big, monolithic and hugely detailed chunks. Rather than exploring different approaches to the information and structure of the site, the emphasis became entirely focused on using all of the time available to build a collection of wireframes, regardless of whether they were the right wireframes.”

Ouch, how much of that is still taking place nowadays? You create as many “detailed individual states” as possible sometimes loosing track of the real intent of the document. Nevertheless, some of those risks can be lowered by using a layered approach where you start as simple as possible and then start adding details to the design that make sense from a design perspective and that help clarify the overarching intent; for example: starting with a high-level, 1-page interaction flow, then adding details in the form of sample calls, which then evolve into detailed flows and become the source for an initial or “skeleton” specification document (containing mostly initial interactions, without error strategies) which after various reviews (including Usability) become a complete or “full” specification document.

“Why hold the information in a document that’s no one wants to read?”

Thank you, thank you, thank you. How many times designers have to create alternative “views” of their documents because some groups may not be able to use (or care) about certain aspects of the design, which might be buried with other details or is presented in a format that is neither usable nor efficient. But of course, the question that begs to be answered is “What’s the ideal document the developer would like to see to build a system from?.” Suggestions anyone?

“In a previous life at a big ‘old style’ new media agency, there often seemed to be a one tool fits all approach to projects. This applied to information architecture too.”

I’m sorry to say some of might still be living that life. Methodologies/Systems anyone? I totally agree with the notion of finding out what’s the best tool for a particular project. Not every project requires the 12-step program, and not every customer processes information the same way.

“The best sites are those where there’s a seamless divide between the look, the content and the experience.”

This one I would like to borrow and extend as a closing statement: “The best systems are those where there’s a seamless divide between the look, the sound, the content and the experience.”

Time to rethink our current documentation practices…