When to Use High Fidelity Wireframes

When I say ‘high fidelity’ for a wireframe, I mean it looks almost the same as the actual interface you are going to publish.  It most likely means there’s no design document (like a Photoshop design) based on the wireframe, and the wireframe is all you need to give to the UI developer.  The wireframe is proportionally accurate in terms of layout, spacing, font size and colours are very close to the actual thing.  Creating such a thing is actually quite easy using modern vector design software (Visio, OmniGraffle, InDesign, etc.).  It should cut a whole design step out of your process and speed up your specification-to-build cycle. However, you should not take this approach unless certain conditions exist:

This is a great approach when the visual design has been nailed down already.  That means there’s a styleguide with design rules and patterns already established and fixed.  Essentially you are dealing with Lego blocks – you have an array of modular features and the wireframe is just to show how you want to stack them together for a particular page or screen.  The best way to know that the modular pieces will fit well together and lay out well on the page is to make them as realistic as possible, and hence the high fidelity approach.  

The scenario when you absolutely should not use this approach is when the design is in flux.  As I’ve stated before, wireframes should never dictate design (nor vice versa). It’s also not the right approach when you’re breaking out of existing capabilities of the user interface, because that’s basically creating new design. This is an important realization if you’ve been in evolution mode for a long time – try to spot early on that you’re not re-using existing features and switch to a concepting and design mode instead.  The high fidelity wireframe is 100% evolution not revolution, and trying to apply it when you need to innovate will end in poor results.

Filed under: creative delivery, information architecture, method, user interface , concepting, design, evolution, high fidelity, indesign, information architecture, lego, method, omnigraffle, revolution, visio, wireframes

Prototypes Are Essential for Web Projects

The long standing ‘page’ paradigm of websites is on its way out, and the complexity and functionality of an individual page is becoming more on a par with a software UI.   Before, it was quite reasonable to map out your user experience with static page designs and do some user testing to iron out any issues.  Now, the only way to be sure how the interactive functionality within each page will work is to build and a prototype. 

Forrester recently put up an article pointing out (and they’re not the first) that with the power of AJAX, Flash and other web 2.0 techonologies comes responsibility.  The complexity of these features is unpredictable as a customer experience.  The experience and knowledge of how to successfully implement these things hasn’t yet grown much in the web community either.  

Prototypes are the best way to cut through these issues.  You’ll see the UI in action and immediately spot interaction flaws that weren’t apparent on the static designs.  You can put it in front of customers and identify areas that need better usability – ideally several times, so you can chip away until the solution is 90% good.

Prototypes offer value beyond developing a good user experience too: They’re a great sales tool for showing clients or internal stakeholders your vision, for getting that all important buy-in.  They’re also a great way of pulling your team out of a linear, waterfall process and having everyone actively engaged at the same time on developing the solution.

A final thought: The best scenario of all is that you can actually develop your site in place of the prototype and iteratively test and refine the site itself.   If you’re in a position to do that, you can take the same approach but with your actual site build.  We don’t all have that luxury though.

PS. There’s a good rounded article about the value of prototyping on A List Apart

Filed under: creative delivery , AJAX, buy-in, Flex, prototypes, prototyping, user testing, UX, wireframes

Wireframes are for evolution not revolution?

I’ve been a part of some very interested conversations recently about a user experience we’ve been developing and whether they making evolutionary improvements to a website or revolutionary change.  In the course of these discussions we’ve developed some concept sketches of revolutionary user experiences that we are contemplating.  The interesting thing about the concept sketch is that it is a hybrid between a boxes-and-arrows wireframe and a visual sketch.  

I’ve written before about the fallacy of wireframes being independent of design, however I’m very interested in the thought that wireframes are not a one-size-fits-all approach, but in fact come in different flavours with different levels of specificity.  Wireframes typically exist at a level of detail where content and functionality is already defined and their task is to optimise which elements are on which page and when.  The inherent assumptions of this type of wireframe regarding the interface layout make it extremely unlikely to revolutionise the user experience.  However, the artefact that you need to create when starting on a revolutionary concept is decidedly not a piece of graphic design, it’s a content/functionality sketch… which to my mind is a form of wireframe.  

Filed under: creative delivery, folly, information architecture, method, style, user interface , design, evolution, IA, revolution, user experience, UX, wireframes

All requirements and no concepting makes solutions dull by design

It seems to me that design processes fall somewhere on a continuum from rigorous process to chaotic and unstructured.  If you’ve been following my posts you’ll know that I’m all about smart methods that use the minimum of process and maximise adaptivity and creativity.

I’ve seen companies standardise their project management practices (clue: your company has a ‘PMO’) on a structure that includes stakeholder interviews, documentation of requirements, prioritisation of needs and so on.  I can see how this is intended to make some basic good practices systemic.  However, I think there’s a management fallacy at work here that given the right set of rules and steps anyone can run a project successfully. On the contrary, I’ve seen this approach done ‘by the numbers’ and the projects have delivered average or worse results.

At the end of the day, there’s no document or rote system that will deliver great ideas.  Original, smart concepts need space to develop outside of spreadsheets and requirements documents.  If your method is focused on creating documents, that’s what it will succeed at – but if your method is about fostering design concepts and delighting customers, it will more likely succeed in delivering strong solutions.

On a related note, don’t get too detailed on your wireframes before you’ve worked on design concepts.

 

UPDATE:  I just enjoyed this post about decision-making on iCrossing’s blog.  Makes me wonder how many formal documents are about putting an objective-appearing wrapper around choices and decisions which are quite subjective and emotional?

Filed under: creative delivery, folly, method , concepts, creativity, design, methods, PMO, process, project management, wireframes

Wireframes

Wireframes usually come with a disclaimer like ‘not representative of actual design’ – this meaning that it’s an abstract schematic of the content and functions that need to be on the frame.  How abstract are they really though?  How many times has the final design radically deviated from the wireframe that you’ve seen?

A design process without wireframes is likely to be error-prone and unlikely to be well thought through.  I’ve done quite a few wireframes myself over the years and I’m a big fan.  However, I’ve also learnt that wireframes can be much more influential on final solutions than they should be, locking down the creative process and fixing a solution that isn’t the best.  

My approach: always work on creative concepts before or in parallel to the wireframe. I mean creative design and unfettered ‘what if’ solutioning.  Never let the creative be a step after the wireframes unless you’re able and willing to re-architect them as you proceed.

Filed under: creative delivery , information architecture, wireframes