Wireframes or No Wireframes

Posted by Vikas Hazrati on Jun 01, 2010

Sections

Process & Practices,

Architecture & Design

Topics

Usability ,

Agile

Tags

UX

The adage “A picture is worth a thousand words”, is sometimes forgotten in the Agile world. At least, that is what many designers believe. In some teams, designers are required to create small increments of the design and this process does not necessarily produce the best results. For other teams wireframes are considered to be bureaucracy which gets in the way of effective development.

Booshtukka mentioned, that in the current scenario, it is hard to blame the designers for their grudge against Agile. The process tries to shoe-horn designers into delivering design in small increments. This makes creativity tough.

This doesn’t make sense – a design is a holistic piece of creativity in its own right. Imagine if you were asked to draw a house, but piece-by-piece. First, draw the chimney. Now a window box. Now a hill in the background. Now the front door. It would drive you crazy, and of course, whenever you sketched the next bit in, you would have to change the previous ones to keep the composition sensible.

Sam started a similar discussion on the Agile Usability group to understand the relevance and importance of wireframes. Responding to Sam, William Pietri mentioned that it is mostly a function of individuals and teams to decide, whether they would need wireframes and if they would, how detailed they need to be. According to him,

I don't think there's a general-case answer to these: you're looking for the intersection of individual variation, team variation, and minimum waste. To me, the only way to find that is to be continually tinkering with your process, seeing how little you can get away with and still produce great work.

Gene Arch and Paul Spencer, mentioned that according to them, wireframes have a definite value and in many situations it has helped them foresee difficult situations. For them, their designer starts working with the PO designing the highest priority items for the next sprint.

Pat Cheung quoted the article 'HTML Wireframes and Prototypes: All Gain and No Pain' when he suggested that for them, wireframes is the way to go. According to him, the benefits of wireframes are even more pronounced in the Agile world.

Producing HTML wireframes & prototypes really brings the development team as close as possible to the end product. It helps disqualify poor ideas, and qualify ideas that work…especially if the wireframes can show user flow and page flow...

The biggest gain comes when the wireframes get the green light; everything is already in place to implement for back end coding. There’s no transition from paper to computer, no translation from PSD to HTML, many of the CSS styles are already defined, and implementation is immediate because HTML wireframes are usually more defined in scope.

Responding to a similar discussion, Sascha Brossmann commented that the single most important reason to do UX in an agile environment is to get the bigger picture clear before development starts and keeping it updated. He added that it is also helpful if wireframes are created one iteration ahead of development. Yoni added,

I've found interactive prototypes (of varying levels of fidelity) to be the most effective deliverable in agile environments (and others as well). The communication gap is implicitly reduced by providing an artifact that is of a more familiar vernacular to developers, and which requires less explanation (and hand-holding) after delivery.

William suggested an interesting approach to validate the need and significance of wireframes for a team. According to him, generally there is a difference in perception of the developer and the designer towards wireframes. It would be helpful for the designers to demonstrate the value of the wireframes.

It may be that to persuade developers of the value of your approach, you need to try some stories each way, and talk over what happens in the retrospective. And if you can see things that they can't, find ways to demonstrate it to them.

Jérôme Gravel-Niquet added what has been working for them. According to him,

• From the basic description of a user story, we rapidly create wireframes;
• As soon as those are ready, we present it to the end user in an interview and gather feedback, we adjust the wireframes accordingly;
• When we're confident we have a solid based (approved by the user and the committee), then we design the interfaces right away;
• With those in hand, we create the documentation explaining the different interactions and features (wiki-style).
• As a UX designer who's also good at integration, I also integrate as much of the interfaces and its interactions as I can before the development teams begin working on these stories.

Thus, there is a general agreement on the significance of wireframes. It helps the team to communicate better internally as well as with the stakeholders. The key lies in doing just enough and keeping the process lightweight. It is also important that the wireframes are of a decent quality because according to Alex Jones, sketchy wireframes are the comic sans of UX.

1. Back to top

   The missing full picture

   by Udayan Banerjee

   Vikas - I agree with you.
   
   Same argument applies to product itself - setandbma.wordpress.com/2009/06/18/why-am-i-unc...

   Reply

2. Back to top

   Design Increments in an Agile World?

   by Franz Allan See

   I don't understand the first argument against the design process in an Agile environment. You're talking about increments and not iterations. Even the example does not seem iterative to me:
   a.) The stakeholders wants a house. The logical thing he/she would ask you to do is the house itself and not the chimney (But if he/she does insists on the chimney because of some importance, then you already have a clue that the big picture is not really the house but the chimney), and
   b.) You will not get much feedback on just giving the chimney. Main difference between increments and iterations is that the latter has feedback. And you won't get much feedback on just the chimney (assuming that the big picture is the house).
   
   Can you kindly clarify?

   Reply

3. Back to top

   Depends?

   by Kulbhushan Sharma

   I agree with the statement - "I don't think there's a general-case answer to these: you're looking for the intersection of individual variation, team variation, and minimum waste."
   
   We worked incrementally but found that maximum time was spent in wiring/re-wiring the (ever changin) UI. This may be related to our lower expertise on the Presentation Layer. But we changed to a mockup which had all the elements so that the changes later on are minimal to implement in the UI layer. This seems to work better for us.

   Reply

4. Back to top

   Re: Depends?

   by Sawan Ruparel

   I agree with Vikas.
   
   Wireframes are really helpful especially
   
   "The communication gap is implicitly reduced by providing an artifact that is of a more familiar vernacular to developers, and which requires less explanation (and hand-holding) after delivery"
   
   Also I would say wireframes provides quick start to project.

   Reply

5. Back to top

   Wireframes are important

   by Rohitha Perera

   It certainly goes without saying that wireframes are useful. Many a client can easily be won over by using a very convincing wireframe to showcase what you are offering to your client. Needless to say, the software you are prepared to use needs to be convenient in its uses. Using something like Creately (creately.com/diagtype/wireframe) should put you in good stead.

   Reply

• Older >