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.
