The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the

design

24/10/11 11:18

Boxes And Arrows : The Design Behind the Design

September Issue, 2011 The Guided Wireframe Narrative for Rich Internet Applications
Case Study: Prototyping Complex Interactions
by Andres Zapata on 2006/05/10 | [25 Comments]
Wireframes. Weve all done them. Weve all had to make sure our clients look at placement, labels, flow, and real estate distributionbut ignore color and design at all cost because, after all, they are wireframes.

Just as IA/UX/ID designers were settling into a comfortable working rhythm, the next step in the never-ending information architects challenge arrived: designing for rich internet applications (RIA). The problem is both predictable and inescapable: our technologies improve faster than we know how to effectively design for them. It may be that AJAX, Laszlo, Flex, and other technologies enhance usability and challenge the way we think and design but, more importantly, they also put a heavier demand on our deliverables. We were all told in Writing 101 to show, not tell. And in most cases this approach makes sense: there is no better form to express structure, conventions, and flow than showing the client a prototype. However, when projects are tightly constrained by time and cost, we have discovered that telling the client is an acceptable second choice. Fortunately, you dont have to settle for second best: composing a narrative that shows requires only the tools and techniques that you are already familiar with: Microsoft PowerPoint and wireframes. This case study covers the guided wireframe narrative technique used to design a typical web-based application. Business problem: The client, an industry leader in commercial and residential fencing and related products, wanted to update their webbased application used to perform key operational tasks. It was a big project, and as with all big projects, business and technical requirements were abundant. The client was also adamantly committed to and expected the highest levels of usability and user experience possible, under the ever-so-typical time-and-cost constraints. Solution: Non-RIAs could satisfactorily accomplish most of the applications requirements. However, we realized that building a rich internet application was the only way to reach the expected level of usability and user experience. The strategy to enhance usability and experience was twofold: improving feedback and response time, and contextually guiding users through tasksperfect for RIAs. Understanding the time and budget project constraints, we decided the best way to illustrate our design was through the guided wireframe narrative method. Guided wireframe narrative The key to using a low-context medium (wireframes) to illustrate high-context information (rich internet applications) is to narrate the information in layers or in dimensions. In short, because we couldnt build a prototype (due to time and budget constraints), we built a story. But because it wasnt a linear application, multiple stories needed to be constructed. We call these stories the Guided Wireframe Narrative. Our story or narrative focused on four main dimensions:
http://boxesandarrows.com/view/the_guided_wire Pgina 1 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Hierarchy Screen real estate Design conventions Interaction patterns Presenting one dimension of information at a time allows clients to focus on one particular aspect of the design at a time, avoiding information overload and the inevitable resulting confusion. This approach also works because we (the IA/UX/ID designers) can focus on setting patterns, not designing or documenting every single page or state. We simply design the patterns and the exceptions. This is done by developing a click-by-click walkthrough in PowerPoint using commentary bubbles, progressively narrating each convention or process. The architect must hit every convention and task to illustrate all design conventions and patterns of interactivity. The only thing left to do is to design the exceptionswhich, by definition, are few. The narrative design process:

1. 2. 3. 4. 5. 6.

Do preparatory work (client meetings, requirements review, user interviews, establishing creative strategy, etc.). Design as you would any other wireframe. Import the wireframe images into PowerPoint (or something similar). Focus on one of the four design dimensions. Point out the different aspects of the given design dimension using callouts. Sequence each callout such that one callout is revealed at a time, building to comprehensively describe and document the dimension.

Before moving forward with this case study, we have to address the question that comes up again and again: Why continue using wireframes? At all? Wireframes are our friends because they are: Familiar. We know how to make them, clients know how to read them. Cheap. It takes a lot less money to put together ten screens in wireframes than in HTML. Quick. Producing wireframes in Visio (or something similar) is simply faster than hacking at HTML. Understood. If you can click on it, then people expect it to work. Wireframes are generally not expected to work affording a higher tolerance for discovery and strategy.

Example: The images bellow illustrate a simple narrative that progressively reveals some of the design conventions. Imagine only seeing frame six. The end result would be patchy understanding and maybe even confusion. This is why focusing on one design dimension and progressively revealing one concept at a time through a narrative is effective.

http://boxesandarrows.com/view/the_guided_wire

Pgina 2 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Admittedly, the example above is relatively simple, but after all, thats the point, right? Its almost like designing a userfriendly presentation of your design. Developing narratives for the visual hierarchy, screen real estate, and design convention dimensions should be relatively straightforward. The real challenge with this technique is nested in developing the interaction patterns narrative. However, if you have experience developing storyboards, this dimension shouldnt be too difficult to design since some of the basic ideas are very similar. As with all dimensions, the key is to place unwavering focus on the type of concept or pattern that you are trying to convey, ignoring everything else. For example, if the task is to search for a customer, only the steps in that process should be narrated. This approach keeps the process clean, allowing you to set the pattern with more ease. In this next example we narrated the flow for creating a new customer. The process for creating a new customer is very
http://boxesandarrows.com/view/the_guided_wire Pgina 3 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

simple:

a. b. c. d.

Search for the customer to make sure it doesnt already exist (a business requirement). Select from search results or select Add New Customer. Enter New Customer information. Validate entered information.

e. Provide feedback.

In this sequence, we talk the client through the process, narrating animation, flow, and functionality. Notice that four different things were said in this one sequence, yet only one wireframe was used. Before moving onto a new wireframe image, it is important to connect the two wireframes through narrative. For instance, the client should not be surprised that the next wireframe sequence contains the search results pane.

http://boxesandarrows.com/view/the_guided_wire

Pgina 4 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

It is important to introduce a new sequence before the current sequence gets too complicated or textured. The next sequence is the final sequence before the task is complete.

http://boxesandarrows.com/view/the_guided_wire

Pgina 5 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Without explicitly saying so, this simple narrative successfully established several fundamental interaction patterns that could be applied to other tasks across the application without actually having to explicitly express them in wireframes. Interaction patterns covered in this simple narrative: How to search How search results are displayed When to fan panes close When to fan panes open How to transition from one pane to another After narrating other processes, all interaction conventions were eventually captured. We typically opted to flesh out the most common tasks first because, in addition to setting interaction patterns, it also documented the most important user flows. It is important to have a full understanding of the entire application before design starts. That way you will specifically know which tasks and exceptions to flesh out. Lessons learned and other observations Clients are always open to money-saving processes and techniques that work. As with anything else, be sure to manage their expectations. The client normally asks something along the lines of What do you mean you are not going to flesh out every task? They become more receptive to the technique after we tell them the work we have to do is not throwaway. The work has to be done regardless of the technique used. Showing them an example and quantifying the time and money savings extinguishes any lingering doubt. In this particular case, the clients understanding of the design was greatly improved by presenting the design. We

http://boxesandarrows.com/view/the_guided_wire

Pgina 6 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

now budget time for a presentation whenever we use this technique. The projects technical team found the output of our process equally as useful as the clients did. They were able to write their detailed technical requirements from our deliverable. No detailed UI/UX design was needed to complete the UAT release. We did, however, have to provide clean wireframesdevelopers found the bubble-ridden printouts from PowerPoint too difficult to read and code from. The UAT release looked and behaved exactly as we had envisioned and how the client understood it. As with all Internet-based projects, the ink never dries. Changes will come up. When they do, keep the techniques principles presentdesign for the pattern while considering how that pattern applies to the specific task or convention. This technique is not appropriate for every project. You have to use your best judgment and decide if the output is appropriate for the project and the client. Wrapup It is true that RIAs make our jobs harder. But it is also true that they introduce some very exciting opportunities that can significantly improve user experience and flow. The Guided Wireframe Narrative technique allowed us to quickly and accurately articulate different design dimensions using familiar tools and techniques. If the job fits the technique, its a win-win.

0
Share on Facebook

Readers' Comments (25)

Bruce Pomeroy
1 Reputation points Posted 2006/05/11 @ 02:35AM with +1 vote Thats cool, I think it is most common to present idds as PDF files but in a way, PowerPoint is more suitable for presenting designs where there is a flow or process going on between screens. Regarding the bubbles; one thing that would make it even more awesome is if the newly added annotation on each screen was highlighted. Sometimes it takes me a while to figure out which one is new and which ones I have already read.

Sanjiv Sirpal
2 Reputation points

http://boxesandarrows.com/view/the_guided_wire

Pgina 7 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Posted 2006/05/11 @ 09:31AM with +1 vote Interesting article. I guess this level of design documentation *is new to the information architecture* field, *but it isnt at all new to those of us who have been designing user interfaces for (desktop) applications*. For us weve had to describe the interaction and workflows for complex forms (inter page, and page level) and complex interactions for direct manipulation tools and widgets for eons. I reccommend looking at how this has been done in the past. The real challenge faced by RIAs is that they have to blend web-centric patterns with desktop centric patterns. Back to your storyboard convention. I like the bubbles you have as they indicate on the screen whats happening. The only problem is that they dont clearly indicate the order of events and are visually heavy. I suggest you number your bubbles, and only provide a light description of what youre trying to show. Then below the wireframe create a numbered list for the bubbles and further desribe the interaction and maybe other thigns that need to be communicated (perhaps to the development community). This way, you can lighten up the size of the bubbles (you may want to just display a number and title), and have a place to explicity describe the step in detail in the list below (or beside) the diagram. No use re-inventing the wheel.

Andres Zapata
52 Reputation points Posted 2006/05/11 @ 10:03AM with +0 votes Bruce and Sanjiv both of your comments are along the same vain. The one thing that I am now realizing is that the images included here dont flow as well as the presentation does in PPT. In PPT, it is very clear which bubble the client should be focusing on at any given point. Future use of this method will include bubble numbering and adding visual focus on the active bubble. Good thinking. Cheers, Andres.

Nanotim Nanotim
2 Reputation points Posted 2006/05/11 @ 15:30PM with +2 votes I first used annotated screenshots when I was responsible for Support Documentation. Quickly, I realized that the client really needed this type of information in the beginning of a projectnot just the end. So, I stopped writing such verbose functional requirements up front, and started doing more wireframe, maintaining the annotations. In the last couple of years, Ive started building wireframes in Flash with the annotations and prompts to guide the user. While its a bit more work than doing it in PPT or Visio, it begins to portray more accurately the tasks and flows in the application. The next step for us is to make our prototypes more durable prototyping in HTML/JavaScript, and iterating right there in the presentation code. Were going to need to build a toolkit to make it easy to get going quickly but, Ive seen some good examples, linked from articles like this one: http://particletree.com/features/ajax-wireframing-approac

http://boxesandarrows.com/view/the_guided_wire

Pgina 8 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

My mission is to give clients a more realistic view of the application earlier in the project (in order to iterate earlier and have a more valuable list of features) while economizing the efforts spent developing IA and controlsto create a more usable/accurate/mature handoff for engineering. Thanks for showing us how you do your wireframeslooks pretty familiar. Good to know there are lots of folks doing valuable work.

Sanjiv Sirpal
2 Reputation points Posted 2006/05/11 @ 15:32PM with +1 vote More ramblings Perhaps you can see why the developers may be having problems with the bubble versions of the wireframes. The steps are not clear. I believe its a fallacy to think that you dont have to create formal design documents. We all know that nature abhors a vacuum. So these stories become the formal UI/UX design doc. Balancing both audiences needs (Client & Developers) in one artefact is challenging because both are looking for (almost) completely different things. But it seems like youre already creating two sets of documents (one with bubbles for your clients, and one without for your developers). What youre proposing works very welly to communicate the flow of your design to your primary audience. By incorporating the suggestions, you may be able add enough detail for your other audience (and formally recognize that your developers need more :) Heres what Im thinking [http://www.culturesculpture.com/scrap/randomize.jpg] Last point powerpoint sucks for writing requirements, I suggest you stick to visio, and just add in navigation buttons to go from one page to the next (slideshow like functionality). When its time to do a slideshow, turn off the requirements layer, show your story to your client.

srinivas ramshetty
1 Reputation points Posted 2006/05/17 @ 08:05AM with -2 votes well it is an effective approach to communnications design :)

http://boxesandarrows.com/view/the_guided_wire

Pgina 9 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

AS Ali
0 Reputation points Posted 2006/05/21 @ 19:15PM with +0 votes I have to respectfully disagree with Sanjiv Interactive prototyping done by the C/S Desktop product development folks have been a mess. The typical MS stipulated workflow. Web-native product developers have taken the prototyping to the next level. Prototyping for the C/S world was a subset of project management killing trees nothing more than that. In the C/S desktop world, prototyping means windows forms on Visio and then wait three months to look at the pre-alpha to realize that everything was wrong. Bubble and numbering are both ineffective ways to show micro connectivityuse the hell out links once the prototyping is done and dump it in your Garage web server and you have the pre-alpha version done for the idiot boss or visually impaired client . Just a little frustrated theresorry . Excellent site for InfoVis designers and architectslearning a lot from comments of some very smart people.

The Dashboard Spy

0 Reputation points Posted 2006/05/22 @ 09:47AM with -1 vote Thanks for the excellent article. What would you think about the following? Would it be too dangerous to also include some powerpoint pages that have some wireframing elements that are editable by the user? I find that, after presenting the type of slide show you describe in your article, the users have lots of ideas that the want to try out. Rather than longish cycles of them trying to express their latest thoughts to you and then you adjusting the wireframes and then representing, how about including a powerpoint template that is prepopulated with editable blanks. Sorry, Im not being so clear maybe I can show you the concept: I work with a lot of enterprise dashboard projects. After determining an initial dashboard layout, I give the users a powerpoint dashboard template blank to fool around with. Can you take a look at this dashboard wireframe PowerPoint template and comment on this approach.

Andres Zapata
52 Reputation points

http://boxesandarrows.com/view/the_guided_wire

Pgina 10 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Posted 2006/05/23 @ 13:49PM with +0 votes Some very good and passionate discussion around these issues. Clearly, this is a source of anxiety for us all, and we are simply trying to feel our way through it. The second we think we have a handle, something changes and we have to adjust again. And thats ok, as long as we continue to share and learn from each other. For example, I wish I hadnt had to spend the time to develop, document and then write about this method. I wish I had read about it here, picked it apart and made it my own. In response to The Dashboard Spy: I havent had much luck designing on the fly with clients. Mainly because one change that we do on the fly might have up or down stream effects that we cant think about right there on the spot. I see the value in what you are suggesting because it would reduce time but only the short run. In the long run, it is better to take the time to think it through than to get people excited about something that might have issues as code begins to be written. Although, it might just work for pre-developed and designed products such as yours.

Johnny Welch
1 Reputation points Posted 2006/05/23 @ 14:47PM with +1 vote When there is little time to build out a prototype (in most cases), I find this approach to be extremely effective. I found this to be an excellent article. Thanks Andres!

kaizan kaizan
0 Reputation points Posted 2006/05/30 @ 00:58AM with +0 votes Nice. I use powerpoint generally but also provide static PDF snapshops for quick paper based referance. We are looking at moving to Visio now though.

Suzanne Sheppard
0 Reputation points Posted 2006/05/31 @ 12:06PM with +0 votes I find that (I believe its because Microsoft bought Visio) many of the features from Visio are in PowerPoint 2003 and quite often you can get away without Visio.

http://boxesandarrows.com/view/the_guided_wire

Pgina 11 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

rajat julka
3 Reputation points Posted 2006/06/01 @ 04:01AM with +0 votes This is a nice article which talks about creating wireframes instead of working HTML prototypes for the client to have a better and common understanding at the design level phase of the project. The approach is best suitable when we are working on not very big project may be around 600-900 hours project. Bruce as you said that Sometimes it takes you a while to figure out which one is new and which ones you have already read. you can also just take the jpgs for the design (with annotation) and import the same in flash and it will only take maximum of 8 hours to give a little interactions (you can just define click events on actual button area to call next screens)... and that can help the user to understand it better and will be more impressive way to present the UI wireframe (now interactive) to the client.

ed.j. bowers
4 Reputation points Posted 2006/06/02 @ 11:16AM with +1 vote Back before I knew any of these concepts had labels I always tried to find the balance between getting the client to understand (and agree to) the process or functional flow and avoiding getting locked into a design discussion. (Or the other way around when I was discussing the visuals) I started with yellow pages on the floor, index cards, blackboards. I like powerpoint because it is fast and visually close to a browser look but I have also taken a rough jpeg and used it as background of an html page with basic mapped links so that we can load it into a real browser. It all starts with understanding your audience; which I suppose can apply to everything out there.

Scott Newcomb
1 Reputation points Posted 2006/06/10 @ 03:28AM with +0 votes I think wireframes only work when the content is well-known by the client. Youre talking about RIAs. I understand RIA is a broad term used very loosely by many in programming and design but when youre talking about true clientside RIAs, user experience is everything. If the client has not had the experience, you cant wireframe it for him.

http://boxesandarrows.com/view/the_guided_wire

Pgina 12 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

The client will look at any wireframe and imagine html. Hell imagine every little decision requiring a page to refresh. Hell imagine old, serverside scripting with a little javascript sprinkled on it to make it a little more tolerable. Ive spent many wasted hours trying to explain clientside Actionscripting to programmers, designers, businessmen IN the internet field and THEY dont get it until they experience it. For RIAs you must either have previous work or a demo. The simplist/quickest RIA demo will win over the most complex, well-planned wireframe.

Jonathan Baker-Bates
20 Reputation points Posted 2006/08/03 @ 03:38AM with +0 votes Scott I dont anyones suggesting that you wireframe rather than showing a demo. The guided wireframe technique is for when you dont have anything to show yet, and need to specify it for those that need to build it, as well as allowing that spec to be digested, at least in part, by those that just need to sign off the concepts. Its basically a two tier approach to the granularity, but in the end were talking about documenting for build, not pitching general ideas.

Scott Newcomb
1 Reputation points Posted 2006/09/02 @ 08:32AM with +0 votes At any point, for any reason, why spend time working with the guided wireframe instead of simply building whatever you need to in whatever language you use? Why create an extra step in the process? Youll still have to go through the demo stage with the client. Wireframes have no time advantage. Anything can be far better represented in the same amount of time with html or Flash. The wireframe isnt necessary unless youre trying to create work or dont do websites.

Andres Zapata
52 Reputation points Posted 2006/09/18 @ 07:35AM with +0 votes Scott,

http://boxesandarrows.com/view/the_guided_wire

Pgina 13 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Creating wireframes have worked really well for me and every other IA professional I have talked to. It is not a perfect method, granted but the alternative can be catastrophic. I have gone down the path that you have described, and some times, I admit, it worked out well. The client had really well formed ideas, robust funding, and a healthy schedule. Having said that, the success rate on that approach is very low and most clients that I have worked with dont have an appetitive for endless spin. As a rule, I try to put some stuff on paper before I have anyone start hacking at code. Code is much slower to put together than paper comps and I say that with unwavering certainty. At the end of the day, I wouldnt feel safe if a team of builders just started building a house without at least a sketch so that everyone can say yes, thats the direction that we want to head in. Yes, I know they are different metaphors, but the idea of arriving at a collective understanding before substantial work begins is a no-brainer.

Scott Newcomb
1 Reputation points Posted 2006/09/27 @ 22:45PM with +1 vote Of course if you have problems doing more than wireframes, then dont do more. If your success rate is low with doing anything more than a sketch on papar or wireframes, then stick with wireframes. To me, just a sketch of a house is in no way comparable to a simple 3D model. Also, building a simple 3D model is far superior for arriving at a collective understanding and is not substantial work. Arriving at a better collective understing is also a no-brainger. Lines on a piece of paper, framework, sketch, whatever, can deliver only a fraction of the information as a simple demo or simple 3D model.

Manish Pillewar
0 Reputation points Posted 2007/03/14 @ 23:06PM with -1 vote Bubbles and the wireframes: I reckon this level of detailing for the wirefrmes is required when the designer is not present while presenting the concept. Have been working in a constantly changing client scenario, I find it easier to just blurr out the concept details: what section would load, whats on focus and how does it appear etc. The rest is self evident. Normally even for a RIA, the wireframe would be used only to show placeholders and the IA and Navigation concept. Maybe, content at times. A clients development team would definitely catch up on the nature of the UI elements within minutes of the presentation. A Powerpoint low/medium fidelity prototype should be enough to get across the ideas. Else, get it simulated on Visio/asp/etc. I find this level of detail unnecessary when the designer is there to explain it.

http://boxesandarrows.com/view/the_guided_wire

Pgina 14 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Alexis Brion
1 Reputation points Posted 2007/09/20 @ 03:33AM with +0 votes Thank you, Andres, for this article, I found it very useful. This method seems to be very logical when time and budget are limited.

Stuart Cullum
0 Reputation points Posted 2007/09/24 @ 02:45AM with +0 votes Wireframes are, for me, ideal when presenting the essence of an idea to a client. The client understands how they want the application to work from a business logic pov, but needs to see this replicated in the screen design this immediacy, even in the very early analysis stage, can give the client and team confidence and give you important feedback. Generally, my next step is to produce a high quality / detailed PDF demo of the proposed app, only a couple of important screens required this generates excitement and enthusiasm for the project, mainly because the client is now able to visualise how the app will function for them. Then task a developer to produce a simple coded demo, involve a bit more logic and then when sign-off is achieved, go into production with the team knowing what the end product will hopefully function / look / feel like. I find most techniques work and have value, its down to your experience to decide which to use and when. Great article and discussion, thanks.

alhnuf ameer
0 Reputation points Posted 2007/10/10 @ 03:45AM with +0 votes that was helpful .. thank you . tag

http://boxesandarrows.com/view/the_guided_wire

Pgina 15 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

Venkat Ganjipally
0 Reputation points Posted 2007/12/27 @ 05:57AM with +0 votes Fantastic :) really inspirating!!

Giacomo Guilizzoni
0 Reputation points Posted 2008/07/23 @ 04:39AM with +0 votes Thanks Andres for the nice blog post and interesting discussion. I too believe that wireframes are an essential part of RIA development, and presenting them like this in a narrative sounds like the right thing to do. I wonder if youd be interested in a little low-context wireframing tool I built. Its called Balsamiq Mockups: http://www.balsamiq.com/products/mockups let me know if youd like a license for evaluating it properly. Thanks again for the insights! Peldi

http://boxesandarrows.com/view/the_guided_wire

Pgina 16 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

http://boxesandarrows.com/view/the_guided_wire

Pgina 17 de 18

The Guided Wireframe Narrative for Rich Internet Applications - Boxes and Arrows: The design behind the design

24/10/11 11:18

http://boxesandarrows.com/view/the_guided_wire

Pgina 18 de 18