Generally speaking I have 2 gripes with wireframes. One is that they're very limited and come with issues in terms of communicating design. Secondly, they're not fast and flexible enough as communication artifacts.
HTML wireframes and prototypes provide some relief from some of the issues, and I'd like to hear what other people are looking for when doing HTML wireframes in order to fix and overcome the limitations of wireframes made in graphics software.
First, here is my gripe list. And for clarity, I use OmniGraffle primarily to create wireframes now.
Limitations for communicating design
1) People have to learn to read low fidelity schematics
You end up with clumsy disclaimers about design, people focus on their rough aesthetics rather than on functionality, etc. This is why so many people find sketch-style artifacts useful. The "unfinished" quality allows people to get past the surface qualities because the final product obviously won't look like that.
2) People sometimes expect them to demonstrate final visual design
This is the other end of the fidelity spectrum. People just have a hard time with both gray box diagrams and with detailed wireframes. Some repeated education and introduction to the wireframe is needed to summarize the purpose it serves.
Limitations when producing wireframes
1) Components are not reusable as updatable instances
Some applications allow you to use stencils and external files imported into a document. But they don't have the behavior of instances, as Flash does, where updating the master object updates instances. You can fake this in some tools, and other tools provide real libraries, e.g. Fireworks. Flex's UI Component Library may come closest to what I'm looking for--library items that can be instantiated and properties customized. The extension of this is to allow the component to be saved and extended so it can be re-used, i.e. a private library.
2) Common behaviors have to be represented multiple times--CRUD, design pattern
A lot of these behaviors can be represented in a design pattern library perhaps. What I've done in the past is to create storyboards for common behaviors across a document, so that their behaviors need only be represented once. Something like this is useful if it can be used with the local library ideas mentioned above. Create a local library of components and they only need to be designed once. Insert where needed in the prototype and the behavior is identical. A separate document can be created to demonstrate all of these and perhaps organize them for developers to view.
3) Some people expect them to be updated constantly, which is hard given the re-use issues
The goal is to both make these easier to update globally and to make small changes. Issues related to this include version control and rolling back changes. This also would be an issue for library components. Documents and libraries can be backed up for brute force versioning, but use of version control systems would be ideal.
4) They're time consuming and therefore costly to make, as opposed to sketching.
I'm still not sure if HTML wireframes will come with time savings, but I am hopeful that their ability to demonstrate ideas more clearly and effectively wipes out those costs by allowing shorter iterations.
What are your gripes?
Do you have any other ideas about what needs to be fixed about wireframes? This is an effort at a "Pony" brainstorming meeting (as in "I want a pony!") to see what other people want to solve with html wireframes that graphic wireframes fail at.
If you want to participate in our project to assemble an HTML prototyping kit, please read our mission statement and find out how to get involved.
Flash Catalyst goes a step beyond what you like in Fireworks, giving you 'motion wireframing' capability and translating smoothly into code that is actually usable in Flex. Its ability to roundtrip with the CS4 suite is an added bonus. Your argument regarding time consumption is an all to valid one, though; I recently evaluated Balsamiq mockups for a project and found that a sketch that took me five minutes to do by hand, took two hours to complete using Balsamiq the first time. But the trade-of, for me at least, is that the Balsamiq mockup was much more legible.
I have worked with both OmniGraffle & Visio wireframes as well as XHTML wireframes. I even wrote about it once. What I find interesting is that while wireframes allows you to "get real" earlier in the process it sometimes comes to odds with the visual design (often created in Photoshop or some other tool).
Basically I found myself spending more time trying to take the XHTML wireframes and adopt the visual design components than it would have taken me to create a wireframe, then have the visual design applied, then build it out in XHTML.
Another point is that XHTML wireframes really only make sense when you have something that is not as visually rich of an experience. For example they work great for basic web apps and maybe even iphone apps where the UI is pretty simplified for the sake of ease of use. They, however, do not so well for experience such as a rock band website, a movie site, a online version of a printed magazine, or anything requiring several custom templates or intricate design details.
Yes, you can apply that level of detailed design once the XHTML wireframes have been signed off and the prototype is also signed off... essentially coming back to the design after the fact but it doesn't always work as smooth as you'd think... often times requiring a lot of overhaul of the XHTML to get specific design attributes to work with the CSS and layout.
I am not saying XHTML wireframes are not a good idea, they are, but only when the circumstances are right. The very notion of taking something and having to "port" it to another tool or develop it to a higher level of detail lends itself to an iterative process internally where you are making small refinements each time it moves to the next tool or platform... all outside of feedback cycles. Which in turn leads to a more solid finalized result.
So to that point doing sketches and refining those, then having to rebuild the same thing in a more solid form in OmniGraffle allows opportunity to tweak and refine some of the structure before applying it to compo in Photoshop an again from Photoshop to XHTML/CSS. More thinking time vs more doing time.. which would you choose?
- Nick
I have been a user experience designer on a number of projects. The approach on those project has been to use tools such as Axure to produce sitemaps and wireframes. The problem - once the project gets into build the prototype is out of date. Updating it becomes an overhead to the project costs. Once the project gets to live, the prototype is effectively a pointless asset.
I am now looking to use XHTML prototypes. In theory they will facilitate quick realisation of sketches to greyscale, to high fidelity interactive wireframes over a number of iterations. That way the effort and cost to create wireframes and prototype makes it way through to build and into the live product. Less waste.
Sketching is the answer on all accounts.
1) There is no dispute regarding is this sketch the final design because that's impossible. A sketch is not a website.
2) Same is true for visual design. A sketch is not a final visual design. Therefore people will focus on the problem and not the medium.
Limitations when updating:
1) Draw a line through the error. Make corrections in red. Move on. Unless your wireframe is going to become the final product, it's a waste of time. Paper isn't going to become the final product either, but you'll easily burn through 3 iterations or more faster than updating your digital wireframe once.
2) I don't do pattern libraries, I approach the problem fresh every time and reuse a handful of styles (e.g. typography, margins, basic layout stuff) to get the new thing built.
3) Version control works, I hear. Haven't had to work with any designers other than myself.
4) After sketching and understanding the problem thoroughly, I move to an unplugged (i.e. not connected to a database) prototype using HTML, CSS, and jQuery. It works pretty well for me. I can rapidly build a single-page prototype with all the interactions using one set of real data. At that point, the concept is proven to development and business folks, and we move forward with developing it (i.e. connecting it to the db, separate the screens).
I agree, for the most part, that digital wireframes aren't flexible and are limited in communicating design to collaborators.
Good read, thanks!
Jason R.
The line between wireframing and basic prototyping seem to be blurring, as it is becoming so much easier to bring wireframes 'to life'.
I have found, anecdotally, the more functionality I can actually demonstrate, the less they worry about attributing visual design standards to the wire/prototype.
I think when looking at static wireframes, it's easier for a stakeholder to instinctively observe the visual look (even though they shouldn't), and not the potential functionality (no matter how well its documented or storyboarded). When they can actually see the functionality, they tend not to focus on the state of design (they might dismiss it as needing to be 'skinned', but at least they aren't holding the wireframe up as final design).
So I'm jumping more quickly to something that is much more close to some level of prototype, usually then taking 'screen shots' (so to speak) for a wireframe to annotate specific details.
I used to bitch about not having good tools for wireframing (in 1998 when I started it was pretty much Visio, maybe some Powerpoint), but now I am paralyzed by the choice. But agree that editing and revising are the big challenges in a good tool when you have detailed pages and states. I am currently trying a Fireworks/Catalyst toolset in my process, but think it may eventually lead to html/css/js.
A small gripe: they can limit vision, and there is a risk of them being taken too literally as a visual representation. If they are detailed and at a high enough level of visual fidelity to make them useful for communicating design, whoever is responsible for the visual design (even if it's the same person who created the wireframes) may feel constrained by them and tempted to make the final design look like a color version of the wireframes. But if they're not detailed enough, they may not communicate effectively. It can be hard to find the right balance.
For the record, I would prefer to just sketch and have people read my mind than to wireframe or touch html. ;)
I am cursing on a daily basis about the lack of updatable instances/symbols.
OmniGraffle people, please, make sur this happens in the next release. I would be willing to give up any other updates in the next 5 years if you give us this feature.
Yup yup. Agree on all counts and think Jason nailed it above.
I think higher fidelity wireframes are needed to help clients look good to their peers and make it easier for them to transfer their knowledge, but have very little value in the design process. I only them them when the sketching is considered done and the client has requested them.
I sympathize with the designers that work in (or for) companies that require it during the process...
I haven't done enough HTML prototypes to add anything useful to the discussion, but usually touch base with the client when HTML/CSS is 50% complete--which is sort of the same thing.
I'd say I'm not too satisfied with traditional wireframing on at least two accounts:
1) Their lack of support for creating variety. Once you get into wireframing, often the tools we use force us to narrow down into a single direction, with alternative ideas being costly / timely. The "wireframe deck" or project file, very often is just one direction. I wonder, how could we contain or maintain a richer pool of ideas on a per project basis that would allow us to select better concepts?
2) The second thing which I feel continues to be a struggle is around the lack of support for a multiple state representation in wireframes. The documentation of rich interactivity, I think continues to be a struggle. My vote goes for unifying some sort of story based narratives provided by user flows, with the concreteness of the wireframe.
I guess in a way I'm trying to tackle some of these with the fluidia.org project. :)
I tend to use different tools for different projects, but generally always start out with rough sketches and then move directly into HTML/CSS/jQuery. In order to make quick changes to the wireframe I've adopted the use of the 960 grid system CSS framework, which makes basic layout extremely quick and relatively easy to change. Of course the resulting markup is rarely semantic or production ready, so some time could be lost there refactoring all of that, but it could be argued that the time is made up in how quickly decisions can be made, especially with projects that require more complex interactions.
I'm surprised no one has mentioned Blend/Sketchflow. It's the closest thing I've gotten to since HTML/CSS for wireframing desktop apps. I have my moments when I want to scream, but so far, I'm really enjoying the control I have over the design.
It comes with sketchy style controls. You can set up workflows. If you like working in Illustrator and Photoshop, you can import them into your project.
One of the best parts is your work doesn't have to be thrown away. You share your files with developers.
It still needs so more refinement, but I have to say it's better than what I used to do.
Thanks for the article, Michael. It's clearly a point of pain for a lot of people. I think it's helpful to back-up a little bit and consider why we need wire-frames as it's likely to answer some of the questions posed in your article and the proceeding comments.
I'm curious to hear - do people find wire-frames more use for defining functionality? content? both? Are they there strictly to inform the transition from design to development or to achieve some sort of client-defined consensus?
I believe there are a fair number of clients out there who don't really even care about wire-frames as long as stuff gets built, works well, and looks appropriate. In those situations, maybe it's fair to say wire-frames are for the designers, not the client.
Of course, a great deal of value comes in getting all the business owners to weigh in before a lot of time is invested in details. And there's the key, I suppose, "details". Wire-frames should steer clear of too much detail. But, provide enough information about behaviors that there are too many surprises clients start clicking around.
Wireframing and building prototypes are exploring very raw ideas. They are early testing/validation of approaches to a solution (based off of whatever discovery you were able to do). Most of these ideas will be thrown away. This phase is about failing quickly to get to the solution. We have to put away the thoughts about reusing pieces. This is about idea generation. These sketches are meant to be explored with a UX team or or developers that understand this is an idea phase and not being presented as the solution. I think that the wireframes we build from these ideas in Fireworks or whatever tool should be more reference for an internal team to use in building a prototype.
Once you have reached a certain level of satisfaction with the approach then it's time to move to a higher fidelity. At this point, taking the time to build and refine is worthwhile since you have cycled through some of the bad ideas. Build a visual framework and use it to build out key pieces of it in something closer to a final output like Flex > Flash. In this phase you can also explore some of the interactions and get a true sense of how they work; rather than just sketching arrows and animating a few screens together to sell the idea to stakeholders who likely can't picture the concept. Once this prototype is done it is easier to present the idea to stakeholders and/or do some user testing. I think building a prototype is not right for all types of projects (or budgets).
There are so many wireframing tools out there today. I'm not sure any of them really solve any of these workflow issues. One tool I've seen recently that was interesting to me though was SketchBook Pro. It might be an option in place of pure paper or whiteboard (http://wireframes.linowski.ca/2009/07/autodesk-sketchbook-pro-4-1/). At least some of the elements can be duplicated and or version controlled. It is still quickly hand drawn on a tablet, and it looks like what it's supposed to be: A sketch.
I wrote an article on Website Wireframing a few weeks ago: http://muiomuio.com/web-design/website-wireframes
I had came across with some limitations that are time consuming and like you said can be improved.
On the other hand I don't think HTML / XHTML wireframing is the best way to go.
It's preferable to print and specify they behaviors with notes, sit down with the programmer to give the insights.
One of the big challenges facing us today is the dynamic and non linear environments, rich applications, task and role driven for example. I try and tell stories through sketches a common approach taken from film, animation and gaming. Once this is agreed I then move to prototyping or wire framing relatively quickly depending on how evolutionary or revolutionary the story is.
I think it is important to understand where you are in any process before deciding on whether sketches, low or high fidelity prototype will do; who your audience is, their understanding and of course how much time you have. One principle from most end user point of view is the more realistic the better but that should not deter you getting concepts and the story you are conveying right first.
Ultimately we will always sketch (storyboard), wireframe and prototype - it’s been going on for 100’s of years in the field of design - I beleive the evolution will be sketching digitally, taking those same sketches (storyboard) and evolving them to a more detailed wire frame and then an interactive prototype and ideally production, in one holistic environment - Interestingly I don’t believe this is very different to the way the animators (at Disney for example) work. I’ve been doing some work with Microsoft Blend (Flash competitor) in which the latest version uses a module called sketch flow to sketch concepts and ideas that can be taken straight to prototyping and onto development, it’s not perfect but on the way.
One thing I would recommend, and something I am experimenting more with is using a tablet and pen, digital white board (and of course scanning) to capture sketches digitally that can be manipulated real time. Now I’m very comfortable with technology (MAC, PC guru and coder for many) so I can focus on the ideas rather than the technology to do this, but other colleagues have found this cumbersome, but the more they did it the easier it became and the more rewarding it has been.
After 7 years in the app design business, I have developed a love-hate relationship with wireframes. They help me clarify my thought processes and identify design problems very early on.
As a communication tool, I find them next to useless (except when communicating to developers).
Reason: ZERO SEX APPEAL! No one (except a fellow UI/UX professional) gets excited about the wireframe. In fact most of my critical audience (execs and customers) don't have the patience to look at them - and their lack of sexiness fails consistently to grab their attention and get their buy in - this is just too critical a step.
So for now - colorful, sexy (incredibly time-consuming) mockups for the VPs and wireframes for me and the coders (btw - I saw your review of Flairbuilder for interactive wireframes - it's a COOL tool - still pretty buggy, but it shows a lot of promise.)
Thank you everyone for your stories. I should preface by saying that I am currently an in-house UI designer, so when I do wireframes it is to specify decisions made with and for a development team that understands how to read them for the most part. When I share these with outside stakeholders, things get tricky, and the fidelity needs to go in one of two directions--high or low--for me to use them to communicate design. They usually cannot stand alone without me explaining them in either case.
A few wireframing packages now offer this sort of switching of aesthetic fidelity--basically going from sketch/jitter line styles to high fidelity styles. But that's purely an aesthetic shift. The fidelity of the what's being described isn't usually changed, e.g. from greybox zones to detailed UI. I'm not sure that modified line and fill styles alone constitutes fidelity.
Several people mentioned what I still consider an ideal and effective approach. Sketch to generate many ideas, refine and narrow, wireframe to communicate refined ideas. Prototype if you can. Go back to sketching to further ideate, refine, prototype, and repeat.
Below is an adaptation of the Pugh iterative funnel that's described in Buxton's Sketching User Experiences
" alt="low-hi-fidelity" />I think wireframes serve a purpose with specific audiences and used at specific times in design communication. They are artifacts for communicating decisions in detail. But static wireframes and storyboards are simply not quite effective enough for demonstrating interaction, which you may have read me bemoaning in the prototying article I point to above. This is why we build prototypes.
As I said above, tongue in cheek, I do think that I'd be happy to just sketch, but sketching gets you so far. I can't imagine that sketches and words/talk alone would work for most teams as the basis for communicating and agreeing upon ideas. It's hard for some (but not all people) to agree to what they can't imagine or visualize.
What I'm looking for is a way to smoothly transition from sketching/ideation to demonstration/communication. The artifacts I produce now demonstrate interactivity in one way, but I want to find a way to do it better without incurring too large a cost in time and effort. Simply said, I want to use time for idea generation, and save time on creating for communication.
I have always worked with paper sketches and moved on to html and css prototypes. This was a fast, iterative approach to quickly visualize and solve problems.
However, for our latest project I have tried blend sketchflow.
The pros are:
You can quickly and easily show interaction and work-flows which is really tough with paper.
You can give it to client or team for feedback. (It packages as a silverlight app with feedback capabilities). Which paper does not do well either.
The cons are:
You need much more time for the same screen. While on paper your done in 5 Minutes and can virtually sketch anything, in sketchflow you need one hour and only get certain elements displayed.
I've been working in-house on web teams for 10 years and I can say that a wireframe is a poor communication tool to the business, while being an invaluable team communication tool.
The wireframe doesn't really give the business (or an end user) a good idea of how something is supposed to work, and is too specific to give them an idea of flow. The latest mode of my ever-changing approach to communicating to business is using storyboards for flow and some level of prototype for how it works. This combination seems to reduce confusion about the design and focuses on the business person's care-abouts:
- What's it going to do
- How will it work
As for communication within the project team, wifrefames are essential for working through details between developers and designers. The more thought put into a set of wireframes, the less make-up work done during development for unintended paths and actions.
GREAT POST!
You're right on all accounts. How I solve these problems is to start the wireframing process WITH the client, so they understand. To do this, we made out meeting rooms 'mockup ready' by placing GuiBoards (http://www.GuiBoards.com) -special whiteboards for wireframing - in them. Works like a charm!
-Efraim
Wow this post has initiated one of the best discussions regarding wireframing and prototyping that I have come across. Lots of good stuff!
Pen and paper seem to always be a great way to get any type of brainstorming activity going, so this is one step I don't think anyone should give up. However, having a platform to discuss the wireframes really helps facilitate the planning process. Sharing these wireframes with clients (or end users) depends on the project you are working on, but if you do open up this stage to them, you really need to know your audience as to whether or not the wireframes should be low-fidelity or high-fidelity. (In fact, knowing your audience/client helps with planning for the project regardless.)
And, it is true, wireframing/prototyping can sometimes seem time-consuming - especially if you cannot reuse templates or elements that you mentioned some tools do not allow. However, in terms of project success (delivered on time, on budget), companies really can't afford to miss this step. Only 32% of IT projects are considered a success (Standish Chaos report) and less than 70% of web projects are a success (New Bamboo study). Not to mention that usability of a site or application can greatly impact your client's revenues.
It is important to find the process and tool(s) that fit your (your team's) needs. The right fit will help you streamline your development process, communicate more effectively, and deliver more successful, usable projects.
Andrea
@ProtoShare
I use wireframes to get to a prototype faster. Current method is:
1. Wireframe - Sketch with pen and paper
2. Prototype - Fireworks (with 960 GS and Flex) export to HTML
Improvements I'd like:
1. Wireframe
Sketches can be difficult to communicate electronically, and are sometimes tough to update. Best solution I can see currently is to sketch using Sketchbook Pro and a graphics tablet. Will trial this soon.
2. Prototype
Would love to be prototyping with a HTML framework. Flaw with my current process is that my PNG (Fireworks) files typically go to an Art Director/Designer to 'finish' the design (usually in Photoshop), and then it's cut up. Ideally I'd skip Photoshop by handing off my HTML prototype and have a front-end design/dev 'design it' in HTML/CSS.
CAN I HAVE A PONY? Here's my ideal HTML framework:
- Compliant code
- Easy to build (component approach)
- 'Ready' to be handed off to a front-end design/dev for design implementation.
Would really like to get involved. http://konigi.com/book/prototyping-framework is returning an 'undefined function' error at the moment.
Sorry, Andy. Broken page is fixed. You can view prototype page now.
Comments