Wireframes are dead, long live rapid prototyping
5 minutes read
Wireframes, your time is up. You’ve served your purpose. You’ve brought order where there was once chaos and provided gainful employment for thousands of UX designers, but I’m afraid now it’s time for you to go to the big recycling bin in the sky. You’re just no longer cut out for the cut and thrust of UX design and have been replaced by that young upstart called rapid prototyping. In this article I argue why you too should ditch wireframes and embrace rapid prototyping.
What are wireframes?
In the same way that architectural drawings might outline what goes where for buildings, wireframes outline what goes where for a set of UI screens. Wireframes typically outline the components for a screen, together with any associated behaviours, such as what happens when a button is click and where a hyperlink should go. They don’t show exactly how a screen will appear, only how it will be composed and how it will behave. For example:
Wireframes are usually put together by a UX designer (or designers) prior to any visual design work and are typically constructed using diagramming tools such as Visio and Omnigraffle, or design and drawing tools such as InDesign and Fireworks. They typically form part of the functional specification for a system, outlining all the requirements for each screen, and as such are usually annotated (as is the case with the example above), often in excruciating detail.
Why ditch wireframes?
So what’s so wrong with wireframes? Well wireframes themselves are not necessarily bad; it’s more the sort of design behaviour they encourage and the way they are often used (and abused) in projects. Here are some reasons why for the vast majority of projects wireframes should be consigned to the rubbish bin.
- Wireframes (which are static by nature) are not well suited to defining dynamic on-page interactions, such as expanding content, AJAX style reveals and animations. As the boundaries between web and desktop applications become increasingly blurred and on-page interactions become more common place wireframes simply no longer cut the mustard.
- Wireframes are not very user friendly (which is kind of ironic for a UX design tool). Project stakeholders are often intimidated by what they perceive to be very technical documentation and find it difficult to understand exactly what wireframes are, and what they show.
- Wireframes are typically very open to interpretation. Wireframes look like they’re very exacting and specific but because behaviours and interactions have to be described they are by nature very open to interpretation. One project stakeholder can read a wireframe very differently from another which can lead to confusion and misinterpretation.
- Wireframes can encourage the ‘lob it over the fence’ approach to design. Designers can spend ages meticulously creating, annotating and updating wireframes and then lob them over the fence for the development team to build; safe in the knowledge that everything is documented, so any dialogue can be avoided.
- Wireframes can be too prescriptive. Many visual designers can feel that wireframes reduce their role to little more than a colouring in exercise; one of applying the necessary branding and look and feel for each screen rather than carrying out proper design work.
- Wireframes often add unnecessary drag to the design process and can encourage death by documentation (a particularly nasty way to go). Creating and annotating detailed wireframes takes considerable time and effort; time and effort that is usually better spent iterating and improving designs, rather than specifying them.
Bypassing wireframes with rapid prototyping
If wireframes are so flawed what’s the alternative? Simple, the alternative is to bypass wireframes altogether and either go straight from sketch / outline designs to developing working code (in an Agile fashion), or as is more use common use a rapid prototyping tool to create a prototype. There are now loads of great rapid prototyping tools out there such as Axure (my own favourite), Balsamiq, EasyPrototype and iPoltz. If you’ve got mad web design skills you can also always create a prototype directly in HTML and CSS.
There are a number of advantages of rapid prototyping over wireframes including:
- Prototypes are a much better at communicating a design. It’s much easier to sit down with designers, developers, product owners and of course users to get feedback and to run through design ideas if everyone can see how things might work with their own eyes.
- Prototypes are more user friendly. Where as people are often scared off by wireframes everyone understands what a prototype is (just make it clear that prototypes are very different from the finished article).
- Prototypes require less documentation as they are less open to interpretation and on-page interactions can be mocked up. If you do need to document your prototypes (hopefully with an emphasis on ‘just enough’ documentation) then you’ll find yourself having to write many fewer comments for a prototype than a set of wireframes.
- Prototypes better support user-centred design. It’s much easier to carry out usability testing with a prototype than a set of wireframes and to get lots of juicy feedback from users in general.
- Prototypes require less work. If you are careful to prototype ‘just enough’ to get the feedback that you need then prototypes typically require less work than wireframes because you’ll need to write (and maintain) less documentation.
Of course like wireframes, prototypes can also be misused. A classic mistake is to mock-up a design to the nth degree and then chuck this over the fence for the development team to build. Prototypes can also be even more prescriptive than wireframes, so it’s just as easy for visual designers to get upset because they feel left out of the loop. This is why it’s so important to always prototype ‘just enough’ to get the feedback you need and to approach prototyping as a collaborative exercise. Designers, developers, product owners and of course users should all be involved in creating, critiquing and evaluating prototypes. This is why I’ve found it best to sketch designs before you even think about touching any prototyping tools.
That’s great, but I still need a paper trail…
If you work in the sort of place where documentation still reigns supreme and the project manager will look at you like a crazy person if you tell him that a prototype with some comments is all the specification required, then fear not. If you absolutely must have wireframe like documentation you can still get by without wireframes because some rapid prototyping tools such as Axure will automatically spit out specification documentation for you. Granted what it spits out isn’t fantastic but it’s much easier than having to maintain a prototype and a separate set of wireframes. As a last resort you can also always screen grab pages using the excellent Screengrab! Firefox plugin and create your own specification document. On screen annotation tools such Protonotes and WebNotes allow you to easily add comments to your prototype so there isn’t even a need to add footnotes to your screen grabs. You can simply grab the pages with the comments shown, so you see, there really aren’t any excuses for not ditching those wireframes!
21st November 2010 @ 12:01 am
I’m a UX noob and one thing keeps confusing, also in this article….
You suggest ditching wireframes and instead use tools like Balsamiq. But isn’t Balsamiq a wireframing tool? (they actually brand it as “Balsamiq mockups – rapid wireframing tool”).
Mockup, wireframe, prototype – what’s the difference?
22nd November 2010 @ 11:00 am
Jens, I suggest you read Bill Buxton’s book “Sketching the User Experience” for a fantastic explanation on the difference between sketching, prototyping, mockups etc.
Wireframes are specs. Prototypes are simulations of the product. Mockups are cross-sections of a prototype, think one-dimensional vs two-dimensional.
That’s my opinion anyway.
24th November 2010 @ 4:08 am
Nathanael, you are dead on. There is no one goto method to plan interactions. Because UX is user centered, there is a nice gradient of prototyping tools that blend into the screen protyping methods. I think the more hands-on at the beginning the better. For instance, experience prototyping (jane fulton suri’s work), which is physically putting yourself in the same environment as your users, and imagining which steps are ‘keyframes’ your users will experience before the designing phase happens. Mapping qualitative factors are arguably the most important things to identify. Then take these keyframes and imagine ideal changes in the qualitative experience that would be improved, such as feelings they might want to have in certain steps of a process. This kind of thing allows you to get more specific and after iterations, get you testing paper prototypes of screen based steps, physically adding paper and taking it away, while testing it on a ‘user’. This will teach you about things that people assume they can interact with and then you can replicate these handmade ‘tools’ into storyboard like steps to present how these will play out, with the reactions of you fictitious user as the footnote to how these steps play out.
24th November 2010 @ 7:16 am
Boring conversation about semantics. InDesign would prototype better than balsamic if you know how to use it. Balsamic is a wire frame tool It has a forced look to it. With InDesign I could add all kinds of library items to visualize something in several ways.
A wireframe is supposed to be fast. Do it on a napkin. Prototyping would take longer. I wouldn’t claim either is “dead” unless I were trying to pull people in with a headline. Ooops, that’s what it was.
7th November 2011 @ 7:34 pm
@smick Yes! There is too much time spent arguing over semantics and tools in UX. The bottom line is you need to develop a plan before you build a website. Developing this plan should be fast, clear, and your tools should not get in the way. Use what works for you.
22nd November 2010 @ 10:40 am
@jens I find there’s not a real big difference, a prototype is actually an interactive wireframe 🙂
22nd November 2010 @ 11:57 am
Having recently used Balsamiq for the first time, I have to agree that what it builds are barely more than wireframes. They are wireframes with hyperlinks. I think I can do in PowerPoint everything I can do in Balsamiq, and more. Balsamiq of course has the advantage of having a UI optimised for prototyping.
There are more sophisticated prototyping tools that allow you to illustrate much more complex behaviour (animations, conditional behaviour, persistent states etc.) However these more sophisticated prototyping tools can suffer from the problem prototyping tools have always had – the danger that the user starts to design not the RIGHT solution, but the GOOD ENOUGH solution that they know how to mockup in the tool they use.
I for one am a big user of SketchFlow from Microsoft (I used to work there). Even as an advanced SketchFlow user I sometimes find myself thinking “why don’t I do it that way – it’s almost as good and I know how to do that…”
22nd November 2010 @ 7:52 pm
The only real difference is probably static vs. interactive. You can click and test in the tool but not in the wireframe.
That cleared up, I want to note, that the wireframe is not dead, yet. It will still be used but for different purposes (like telling the designer where one want the search-button) and we are back to good ol’ saying, that one has to choose the right tool for the right job.
Rapid prototyping seems like a good tool for bigger, more complex and interactive UIs, while wireframes deserve their use for “smaller” stuff.
23rd November 2010 @ 2:59 am
You should look at a tool called Flowella.
http://www.forum.nokia.com/info/sw.nokia.com/id/7557c13f-0b43-4805-85ce-8414bfbade57/Flowella.html
I like this one. It’s pretty lightweight
23rd November 2010 @ 12:28 pm
Hi there,
Another great tool for software prototyping is Justinmind Prototyper. One of its main good points is that is a flexible tool which lets you create wireframes but also evolve them to achieve extremly high fidelity, both in visual and interactive aspects.
Another interesting service we’re offering is Justinmind Usernote, which lets you publish these prototypes to share them, gather your user’s feedback and even perform usability tests online.
Best,
Dan
@Justinmind
23rd November 2010 @ 9:54 pm
Agreed. Wireframing is only part of the design process. How users interact with the application is the other. LucidChart just released superior rapid prototyping capabilities to their web-based diagramming software. Basically, you can quickly mockup how a website with full navigation.
http://lucidchart.com
23rd November 2010 @ 10:06 pm
In theory omitting wireframes is great, but the business world at large requires the paperwork from my experience. Without it, you’ll run into more communication problems for development teams needing the ink in their requirements/planning.
23rd November 2010 @ 10:13 pm
I don’t think it’s an A or B argument as your article seems to be based on bad designers/clients rather than the tools themselves.
Truth is, whether you’re relying on wireframes or prototypes, most of the cons to wireframes and pros to prototypes rely on different Designer pools it seems rather than the strengths/weaknesses of the tools.
Wireframes work better with demanding clients prone to Scope Creep, indecisive tendencies and without web experience while Prototypes work much better with more up-to-speed clients (usually 2nd-time/repeat customers) that can be trusted more without a complex paper-trail of approvals. Prototypes and Wireframes should be available tools depending on the project and not viewed as either/or from my experience.
23rd November 2010 @ 10:28 pm
I think we need to differentiate the act of sketching out a UI and the act of making that sketch interactive. Two completely separate things in my mind.
The act of sketching out a UI bring about new thoughts, issues and ideas about the content and user interaction with that content. Once you’ve nailed what is believed to be the best UI experience it can then be quickly mocked up. Why spend the the time creating interactions before you’ve actually determined what is the best UI experience?
What you present to the client is also based on the deliverables you’ve set out with them, their expectations and the grasp they have on the difference between a wireframe, mockup, prototype and a beta version of a website or application. It may in everyones best interest to show only wires for a particular client/project.
I don’t think the act of sketching out an interface will ever or should ever be replaced by prototypes. It seems to be a step backward. Prototypes should live in conjunction with wires and just another step(optional) in the process.
23rd November 2010 @ 10:49 pm
Hello
I wish I could agree fully – I’m a big fan of good prototypes especially as they can be easily subjected to user testing.
I think that Balsamiq (and similar) are little more than clickable wireframes, and frankly I’m not too keen on the finished product. I heard someone say that “Balsamiq is to wireframes what Comic Sans is to typography”. A bit harsh, but they had a point.
Axure, on the other hand is a different kettle of fish. It allows non-coding UX Designers like myself to create fully interactive prototypes that deliver on all but one of the advantages you list in your post. In my experience, I don’t feel that creating an Axure prototype is “less work” compared with wireframes in Omnigraffle. It takes me much, much longer to wireframe in Axure than in Omnigraffle, and that’s before I’ve added the interactivity. I also find that working with particularly complicated prototypes becomes unwieldy as page objects are obscured by dynamic panels etc. Now, if someone could come up with a way to faithfully import Omnigraffle files into Axure, I’d be a very happy man indeed.
P.S. I totally agree with your comment about sketching before you even think about prototyping or wireframing. Apologies for the blatant self-promotion, but I also wrote about this a little while ago!
@jamesdownes
23rd November 2010 @ 11:29 pm
I’ve been using Axure RP for a while now and it’s the best of both worlds. You can easily create wireframes and export them into a clickable prototype or a document which explains the various pages and its components. There no need to make a decision or dich a tool. It’s better to choose a tool based on the problem that needs to be solved, the size of the project, amount of pages, budget, type of customers, type of users, etc.
23rd November 2010 @ 11:42 pm
I tend to agree with Jens (even though he seemed confused by the jargon and what is proper use – probably rightly so given the liberal overuse of such phrases).
It’s all prototyping, from the very first sketch to whatever it is you and your higher ups invoke as best practice… right up until it starts being built / developed it’s all still an experimentation.
What really bugged me about your write up was your analogy for architectural documentation and how it relates to the “wireframe” in web design. There are several similar professions that produce construction drawings – but none of those professions produce architectural documentation. There maybe some very thorough practitioners who do, but for the most part its a sub-standard, and cost driven exercise where the result IS the bare minimum.
Architectural documentation is the record of all the forethought and planning, yes it a recursive process, but the priority is to encapsulate all the prior experimentation, problem solving, and decisions made into a record that the client, builder, regulatory contractors can make sense of. There is an inherent type of legalese about these documents but the inclusion of a visual reference along with logical units of measurement make it easier for a lay person to understand…
I hate spec writing so nothing would please me more than to have it removed from the process, but how are you proposing that the documentation void be filled?
“Granted what it spits out isn’t fantastic but it’s much easier than having to maintain a prototype and a separate set of wireframes.” Yeh easier, lesser thorough…? That’s not a viable option for me, and I suggest a lot of other people that need a proper record of my decisions and recommendation – for sake of accountability.
…“everybody needs the results, anybody can do it reasonably well with a bit of training, and yet it takes a master to produce a gourmet outcome”…
Pushing for the reasonable result in the first place means there is just going to be a bastardising of fees, and lowering overall quality of output (something that is also inherent in architecture – the result being a plethora of crap buildings).
Different strokes… I work in a consultative role and have worked in architecture, so maybe I have a different perspective. Wireframes are not the best tool to show off your UX / ID decisions to your client (I have enjoyed the blank face look before, so I completely agree with you there) but if we’re talking about ditching wireframes as a form of documentation (to hand to developers) what are you using in place? You’re happy with the Axure output that is “not great”?
23rd November 2010 @ 11:55 pm
Great post. We agree that rapid prototyping has many advantages over static prototyping. We are building a web-based product called Tiggr, http://gotiggr.com which allows to do exactly that. Any time during prototype design, you can do a Web Preview which generates HTML/JS/CSS for the prototype. The prototype is now interactive, you can interact with any controls and even navigate between pages. Furthermore, the prototype can be viewed in any browser, any mobile device and tablet such as iPad.
24th November 2010 @ 1:32 am
Prototypes certainly have a role. I use both and both have pros and cons depending on the case. The arguments you use against them are insufficiently nuanced to support your headline. Your headline should be “The Benefits of Prototypes Over Wireframes for Particular Contexts”, or something cooler, but since you overplayed your hand here are a few things to consider.
1. Argument about designers “coloring in” is outdated and/or based on weak process and client expectations management failure. Wireframes can be incredibly high-fidelity to support client comprehension as they are easier to read as interfaces. But even the highest fidelity wireframes can be completely overhauled in the design process, and it is easy to manage client expectations around this if you know what your doing with educating the client and if you have a good process in your team that allows for such iteration. If you don’t know how to do these things, that is a process you need to learn and had nothing to do with how high-fidelity your wireframes are. This argument also is limited to an understanding of old school wireframes that show very little in terms of the interface. When I make mock-ups, I mock up content architecture and other communication layer elements as well as interaction design patterns. Your concept of wireframes does not embrace this use of them, which is a highly valuable differentiator for teams who can produce them. The benefits to efficiency and legibility of the deliverables is considerable whether they are high fidelity wireframes or prototypes.
2. They can work together. I’ve have had great success (including recently with 3M) importing Omnigraffle jpegs into Protoshare, which benefitted from combining the design superiority of Omnigraffle with the full testability of the prototype. But the wireframe documents were much better for notation and approval before committing to interactivity. The notation capabilities of the static diagrams are still superior to prototyping environments, at least in how I do it.
3. Prototypes are not inherently easier to understand just because they are clickable. Both formats present challenges to comprehension that can be addressed within each format by the skilled practitioner. But one is not inherently easier to understand than the other. They come down to information design skills of the practitioner, and limits of the environments authorship capabilities in the prototyping tool.
4. Prototypes do not permit simultaneous diagrammatic viewing of asynchronous state changes or screen flows that are ESSENTIAL to understanding certain concepts. Sometimes the client or team members need to view several screens or states at once with interconnecting explanatory material. You of course could make such a static document from screen grabs of the prototype. But this is one of many benefits to documentation that your article does not explore for sake of a balanced perspective. This also gets at your first point about state changes.
5. Documents are hard work. Bwing a client buying say, a web application, is a serious deal. You don’t go buy a house without expecting to have to do some work learning a thing or two. It’s not different with an application that might coast as much as a house! If you are on the client side spending half a million dollars on an application, you have to get ready to spend serious time reading, clicking, meeting, answering emails, etc. It’s work. If there is not someone on the client side prepared for this, that is their problem which we need to help them with as best as we can, but it’s bullshit to think that there is a way to “make it easy”. We can make it easier, but not easy.
6. Prototypes are hard work. Just because it’s clickable does not mean that there are not the same amount of screens and elements of them that the client needs to understand and weigh in on. Either way it is work. And why to clients want print versions of their prototypes? So they can spread them out on the table, write on them, pin them on the wall. Documents are not evil. They are necessary for particular workflows.
7. Lobbing over the fence comes down to poor project management and process design. If your dev team was not shown early and often that has nothing to do with documentation, that had everything to do with communication.
24th November 2010 @ 2:18 am
I couldn’t agree more. We shifted from wireframes to prototyping a few years ago at my design firm messagefirst. I’d felt that wireframes fell flat when trying to communicate AJAX style transitions in our designs. Since most of our work is web application design, these types of transitions are commonplace and wireframes just cannot communicate a self heal transition as well as a prototype can show it.
Once we starting making the move to prototyping, our designs got significantly better. We spent less time explaining our designs to clients and more time showing them and letting them play with the designs. More show, less tell.
If you’re looking for some additional insights on prototyping and a comparison of tools with hands-on tutorials, I wrote the book on prototyping, Prototyping: A Practitioner’s Guide.
24th November 2010 @ 4:34 am
Very good article. I’ve used Axure and I still prefer to create the design in Photoshop but quickly convert it using HTML and CSS. This way I get to define my font sizes, colors, background images and area I’m going to work with. That said I agree with the article that wire framing will never depict any type of animation or dynamic controls of a page thus when I present to clients the prototype usually sells it self because the client can interact with the site and the feedback or comments are much more useful than asking questions about a wireframe and me trying to explain what it will do.
Cheers,
24th November 2010 @ 5:28 am
Thanks for a great post Neil!
I guess yet again it’s horses for courses, and the key is to get the level of detail right so that you design and communicate (just) enough, without spending ages on the (likely throwaway) prototype.
As an aside, most of the wireframing and prototyping tools out there focus on designing screen-level detail, which is understandable as this where a bulk of the IxD design effort takes place. It is however a good idea to first draft out what the overall website structure looks like.
It’s a shameless plug but I’d like to add our Naview service to the list of prototyping tools. Naview lets you work out the sitemap and prototype & test the main navigation of your site in isolation. It can also help you refine the labelling and terminology that are especially important for larger websites. With regards to the paper trail, you can also easily export your sitemap into OmniGraffle or Visio. Once you have the sitemap sorted you can then move onto screen-level detail using any of the other prototyping tools.
Thanks again for your thought-provoking post.
24th November 2010 @ 6:37 am
Thanks for the good article.
Another tool missed here is http://cacoo.com/. The thing that adds zing to this one… is that it aids, real time collaboration as well.
br,
@wordwhacky
24th November 2010 @ 7:40 am
We’ve been using Protoshare for some time now and found that it helped explain what we were going to deliver to our clients and saved time when we got down to programming by avoiding unforeseen changes to the spec.
Recently we have been experimenting with using our own CMS to build the wireframe prototypes. The main advantage of this is that we can quickly present dynamic wireframe version of the website and make alterations to refine the wireframes based on client suggestion (as you would normally. However when the client signs off the wireframe concepts you have a live version of the website that only requires the addition of styling and content. Saving you the time/cost of transferring the ideas of the wireframe model into a web version as well as any subscription cost for wire framing software. Everyone’s a winner. The client gets a real feeling of how the website will function and you can deliver the project quicker.
24th November 2010 @ 10:39 am
Hi there
I find that for every project I use some kind of wireframe, depending on the time available, client, project etc. Sometimes I sketch on paper or wall, sometimes in omnigraffle. I consider sketches to be a kind of wireframe. As far as I’m concerned the wireframe is very much alive and kicking, it’s just much more flexible than it used to be and easier to turn into a prototype or evolve from a sketch.
24th November 2010 @ 1:43 pm
it’s kind of weird to replace wireframes with prototypes if on the course of the project both become irrelevant.
Ditch wireframes, yes. Use html for prototyping, yes yes yes. Although it needs to be said that some teams need to use wireframes as the process is to granulated – that’s possibly the only place for old WF, otherwise waste of time.
html prototype can be easily converted into a final product – without wasting time, resources… recycle!
24th November 2010 @ 6:05 pm
In my view wireframes are more important than you make them out. Here’s the full response 🙂 http://bit.ly/ejIf5K
24th November 2010 @ 7:17 pm
Hi there
I enjoyed reading this a lot, great article. I do feel though that you’re doing wireframes a diservice.
I wireframe daily in Axure and have never encountered the problems you’ve listed as reasons for getting rid – even designers and their interpretations of your work – our designers are always grateful they have something to work from and never feel they are just painting by numbers . Any of your wireframe concerns can be elliviated through communication with stakeholders.
I do agree with your ‘lob it over the fence’ ideas though. The IA/UX designer should be involved through out!
Thanks for the article!
25th November 2010 @ 9:19 am
To be fair, most of the tools and techniques described pretty good. What matters more is the experience and skill to PLAN which to use to create the right process suited to the project and the people. At the end of the day, software won’t save you, people will. Talent, experience and process. But if you have to start somewhere, I’d go for a collection of pen, paper, balsamiq and axure
27th November 2010 @ 3:53 pm
I’m not keen on the “wireframes are dead” part of the title. Prototypes have their advantages but to imply that wireframes are going away completely is very inaccurate. Every project has different needs and requirements. One project may not require the detail from a prototype when a simple wire frame will suffice.
28th November 2010 @ 6:30 am
Wireframes are not dead. And prototyping still involves more time and talent (a.k.a. budget) than is often available at the earliest stages of development. In organizations where they are ineffective, perhaps their purpose, and the process in which they are utilized should be revisited and improved upon.
29th November 2010 @ 4:42 pm
Neil,
Great article on the benefits of rapid prototyping. I’m on board with your process and reasoning. Prototyping is very important, but I also believe that wireframes can help to get you to the prototyping stage depending on your team, stakeholders, or the project – as many of the commenters have stated.
If you’re building a sophisticated website or web app with complex user flows or Ajax functionality, wireframes aren’t good enough. For this, prototyping those flows is important to gain early feedback from stakeholders.
Wireframing still has its place if you are either eliciting feedback on a very simple website, or as a first step in an iterative prototyping process (i.e. nailing down some basic structure and placement).
Here is also an example of a company that used wireframes prior to jumping into Agile sprints of design and development to help get them off on the right foot. And as @CarlosAbler mentioned, his team uses wireframes to move into prototyping. It is dependent on your team’s needs and processes.
Finally, you write, “approach prototyping as a collaborative exercise. Designers, developers, product owners and of course users should all be involved in creating, critiquing and evaluating prototypes.” I couldn’t agree more. A collaborative approach to prototyping makes it easier for all teams and stakeholders to have visibility and input into the process, discussions, and decisions being made as the project evolves.
Andrea
@ProtoShare
30th November 2010 @ 11:18 am
Good info and good comments as well. Depending on the nature of the project and the documentation needed, wireframes still have a place and purpose. That said, you raise a good point about streamlining and speeding the process by moving more quickly to rapid prototyping and design.
We have used Axure (powerful but a little clunky), Balsamiq (fast, easy, purposefully “sketchy” looking) and we use ProtoShare (a web-based, collaborative prototyping tool that leads into requirements and design documentation). ProtoShare is great because multiple team members can collaborate and clients or other project stakeholders can also collaborate online in the design process. In addition, we have used PowerPoint and Photoshop or Illustrator in the past. The new generation of web-based tools makes the process easier, more effective and adds great features like collaboration.
Cheers,
Greg Mattison
Habanero
@GregMattison
@HabaneroWeb
Weekly Reads – 12/1/2010
2nd December 2010 @ 4:12 am
[…] Wireframes are dead, long live rapid prototyping […]
26th December 2010 @ 11:17 pm
Highly depends on a client you’re working for.
Wireframing is a way when you’re timed. Prototyping needs at least your pc with a projector (it isn’t useful to make rapid prototyping while sharing your screen with more than 2 persons at a time). In case you have a meeting out with a group of people – leave your notebook alone – all you have is a paper, pen and your skills to make it quick.
Just another thing is that rapid prototyping doesn’t always work with some clients. Haven’t you heard “Let’s use a different font for it?” and, after yours 1000000’s explanation that it isn’t the final graphic design – “Sure, we understand it, but… will you, please, use a different font?” That’s one of the cases when wireframing rules.
Some packages have sketchy modes, so Axure RP in it’s upcoming ver. has, but! It works only when it’s rendered.
The best scenario IMHO is to have a Wacom monitor accompanied with a regular one and a software (hope sometime we’ll have it) that allows to prototype in a sketchy mode.
Happy prototyping,
Rey Mayson
29th December 2010 @ 1:40 pm
Close, but nope. Prototypes are just too slow for some stages of a process.
axplock 2010-12-30 | axbom
30th December 2010 @ 6:12 pm
[…] » Wireframes are dead, long live rapid prototyping Japp, ofta så gör jag prototyper i WordPress innan wireframes är på tal. Det skapar bra och givande diskussoner, men det är inte alltid rätt. Tricket är som alltid att veta när det är rätt att gå direkt på en prototyp och när det krävs ett gediget pappersarbete och diskussioner med många intressenter. Det hänger förstås både på applikationen och på organisationen. Och på att vi är överens om att en prototyp inte bara är klickbara wireframes… och att wireframes faktiskt inte är döda, bara förfinade. Och att prototyper alltid behövs. […]
2nd January 2011 @ 7:05 pm
I really like these kind of provocative and controversial articles – Interesting and correct rudiments and approaches but you came to a wrong conclusion
Wireframing is only part of the design and development process. BUT Prototyping is just exactly the same – it’s also just ONE part of the design and development process.
The purpose, object and aim is different – But what is more important is that the deliverable’s target group is different.
You already got a whole train of proper comments – And I agree with quite a lot of them.
Prototyping and Wireframing – It’s your choice which diagram tool supports your work best
http://ux4dotcom.blogspot.com/2010/12/prototyping-and-wireframing-its-your.html
Before you consider “ditching” or “killing” one of your deliverables – you should ask yourself what supports your approach and project steps / milestones best.
And that will change from project to project and from client to client and from year to year.
Significance of UCD, IA and UE (User centered utility and usability)
http://ux4dotcom.blogspot.com/2009/07/significance-of-ucd-ia-and-ue-user.html
Why and why not … Wireframing
http://ux4dotcom.blogspot.com/2010/01/why-and-why-not-wireframing.html
10th January 2011 @ 6:41 pm
This is an important discussion. I like a lot of the commentary here.
It seems we have jargon problem here. We all have different definitions and words for the tools we use and the phases of creating software.
I think in the end we want to think fast, make a lot, and discuss the tangible, for better decision making. We need a metaphoric and literal wind tunnel. Rapid prototyping is this wind tunnel to get to the right design faster and better. A prototype can have different fidelity levels. The higher the fidelity the prototype the more realistic the learnings are that coming back. Therefore a prototype can be from a napkin sketch to a after effects movie to a fully interactive CSS. As we make these prototypes we hone our design. Once the design is settled on, a Spec is put into production and followed exactly and produces.
that is the process I know and live.
greg melander (gregmelander.com) http://gregmelander.com/post/1124641927/your-wind-tunnel-the-wright-brothers-were-kind
11th January 2011 @ 8:56 am
That was an interesting, if not infuriating read. A few counter-arguments;
“Wireframes are not very user friendly…stakeholders are often intimidated by what they perceive to be very technical documentation”
Quite possibly, but that isn’t the case if you communicate to the client exactly what you’re showing them.
“Wireframes look like they’re very exacting and specific but because behaviours and interactions have to be described they are by nature very open to interpretation.”
Well that depends entirely on the description. You could argue that the why’s and the how’s of an interaction being exemplified in a rapid prototype are open to interpretation, it’s about how they’re presented.
“Wireframes can encourage the ‘lob it over the fence’ approach to design. Designers can spend ages meticulously creating, annotating and updating wireframes and then lob them over the fence for the development team to build; safe in the knowledge that everything is documented, so any dialogue can be avoided.”
If your designers are encouraged to ‘lob it over the fence’ and avoid talking to your developers, then you need to sit your designers down and let them know they’re buffoons.
Your next point about wireframes being too prescriptive is also ridiculous. If your designs approach wireframe > design as a colouring in exercise, let them know they’re buffoons.
I think most of your points are clutching at straws to be honest. Would love a reply though.
links for 01/12/2011 « Alan Vonlanthen's blog
12th January 2011 @ 12:39 am
[…] Wireframes are dead, long live rapid prototyping « UX for the masses […]
Conexão TE » Blog Archive » Protoshare – prototipagem interativa e colaborativa
14th January 2011 @ 11:37 am
[…] Wireframes are dead, long live rapid prototyping ” UX for the masses (uxforthemasses.com) […]
Protoshare – prototipagem interativa e colaborativa « Enio de Aragon
14th January 2011 @ 6:54 pm
[…] Wireframes are dead, long live rapid prototyping ” UX for the masses (uxforthemasses.com) […]
6th February 2011 @ 5:23 pm
Defining the problem first will tell you what process and tools to best communicate with stakeholders. You’ve already jumped to a specific tool.
People are unfriendly, and processes are unkind. Wireframes are agnostic.
Uproot - Creative Technologists
18th February 2011 @ 2:53 pm
[…] and toward creating prototypes as part of our Interaction Design practice. This is an approach widely discussed in our industry and certainly not novel to Uproot, but still in it’s […]
Lean UX and Agile Design Development | Take 5: Interactive
18th February 2011 @ 9:57 pm
[…] Wireframes are dead, long live rapid prototyping ” UX for the masses (uxforthemasses.com) Tags: agile, Agile management, Agile software development, Barclays, design, lean ux, Native Instinct, Product design, San Francisco, Tim McCoy […]
21st February 2011 @ 4:24 pm
Great idea; take the design and organization of content / functionality out of a UX Designers hand and into the hands of developers… way to set the web back 15 years to when developers / programmers did the coding and design and we all remember how well designed and user-centric those designs were.
The more I think about this article the more absurd it is… instead of creating wires to make sure everything is accounted for and presented in an engaging manner, you are suggesting one should do prototyping, which is more cumbersome and technical of a task.
Wires and sketches work, because there’s no technical limitations and one can create / sketch what’s appropriate to solve UI requirements without getting stumped by any tool.
21st February 2011 @ 4:43 pm
I guess that’s one possible intreptation of the article, although certainly not the one I intended. I certainly don’t view prototyping as a cumbersome or technical task because with tools such as Axure you can quickly create something that conveys a UI in a much more engaging and dare I say it, user-friend manner than wireframes. You’ll also notice that I don’t talk about ditching sketches or quick mockups, simply that it makes more sense to go directly from these to an interactive prototype, rather than a static wireframe.
21st February 2011 @ 8:08 pm
My bad, I must have misunderstood the title and the parts saying to scratch wireframing – lol
Even Axure as nice of a tool that it is, it doesn’t pull of all UI interactions that one would like to implement and I’ve had my guys spend lots of time trying to figure out how to pull off (prototype) complex interactions… what I’m trying to say and the main reason I embrace sketching and wireframing is that they should be done early in the process by a UX Designer without limitations of the tools at hand or their knowledge on how to use them.
Why use Axure or any prototyping? Should they not know jQuery, CSS and HTML where they should be able to go right into creating the presentation layer code? As 37 Signal recommends? 🙂
http://gettingreal.37signals.com/ch06_From_Idea_to_Implementation.php
21st February 2011 @ 8:07 pm
My bad, I must have misunderstood the title and the parts saying to scratch wireframing – lol
Even Axure as nice of a tool that it is, it doesn’t pull of all UI interactions that one would like to implement and I’ve had my guys spend lots of time trying to figure out how to pull off (prototype) complex interactions… what I’m trying to say and the main reason I embrace sketching and wireframing is that they should be done early in the process by a UX Designer without limitations of the tools at hand or their knowledge on how to use them.
Why use Axure or any prototyping? Should they not know jQuery, CSS and HTML where they should be able to go right into creating the presentation layer code? As 37 Signal recommends? 🙂
http://gettingreal.37signals.com/ch06_From_Idea_to_Implementation.php
Are wireframes dead? - Zuni
22nd February 2011 @ 6:36 am
[…] rapid prototype. After lively discussion within Zuni, I changed my mind. You see, the concept of rapid prototyping sounds fabulous, but in reality, the skillset that you need to create the prototype and the time […]
26th February 2011 @ 6:35 am
Even with a rapid prototype you still need something to build. You can’t just pull it out of the sky. That means designers need to have their head in the game from day one. Indesign, Photoshop, Omnigraphical all seem too limited and already behind the times. What you need to do in get your idea out there…rapidly hence the point. I can hack together anything with our without graphics in Keynote and clients get it, sign it off and then we go rapid dev to show true interaction. Huge time saving and we have reduced our creep on scope.
23rd May 2011 @ 2:28 pm
Great point on reducing creep on scope. Rapid prototype the interactions and let users/clients experience it. It’s the best way to ensure everyone share a common understanding of how the upcoming app should behave and look before formal development starts. Static wireframe is a good starting point. But it leaves too much of a gap between clients’ mind and the dev team’s regarding the interaction flow.
Being a tool developer (http://www.appsketcher.com) myself, I might be biased. MonkeyMan8383 above mentioned using jQuery, CSS and HTML to get right into the game. I think it’s a good approach – if you are prototyping for web-app, why not doing it the web way. Granted, most don’t want to deal with the code directly in prototyping phase. Tools can help here. Take a look at App Sketcher and see if it fits your rapid prototyping needs.
28th February 2011 @ 2:27 am
I wonder did Axure’s devs wireframe OR rapid-prototype it?
21st March 2011 @ 5:16 pm
We use what ever is appropriate for the need. Sometimes it will be a sketch for a new datagrid layout or sometimes a wireframe for a static screen or maybe its a RIA that has heavy interaction and a truck load of new features that need to be developed concurrently and justifies rapid prototyping/proof of concept. All techniques offer value in the right context.
24th July 2011 @ 8:47 am
I am absolutely agree with you. Radip prototyping will long live in UX, even all over the world.
25th July 2011 @ 4:33 am
MockupTiger is enterprise class prototyping/wireframe and mockup tool. It is absolutely free to use
25th July 2011 @ 2:03 pm
Hi! Great blog post. While I TOTALLY agree with the process of rapid prototyping for the build/user test phase, I think ‘wireframing’ as a process is still needed, but its just an early sketch phase, vs the actual deliverable.
Its all just means of communication, right? So if we’re in an agile environment, we need to communicate our design to the prod mgr and developers. We could do that with a prototype, but if we’re all collaborating, and your project team understands the symbols you use to draw your sketchy wireframe, you can iterate SO much faster with sketching wires than you can with a prototype. Yeah, iRise/axure/protoshare(or other tool) allows you iterate pretty fast, but not on detailed interactions.
I would be curious to see you rapid prototype 10 different ideas faster than it would take to sketch them. Especially if it involved a process flow, an accordion, tab panels, search, etc.
Rapid prototyping is good, but so is sketching/wireframing/whiteboarding.
7th July 2012 @ 9:34 pm
True. for getting much into depth about the application flow, wireframes are a must for a UX designer to go with. As the user’s intution will also follow from the every single element that is put up in the screen design.
as of Rapid Prototypes, we have a limitation and time taking procedures to follow.
So it is wrong to say wireframes are totally dead.
They are the underlying parameter for a good interaction design.
29th July 2011 @ 11:19 pm
I just happened upon this interesting BLOG post. I think much of what’s being discussed is semantics. Yes Bill Buxton put forth a definition of prototype vs wireframe, but it’s not universally accepted. With the advent of sophisticated wireframing tools like Axure, the line between wireframe and prototype has blurred. Many of us, me included, think of wireframes as low fidelity to high fidelity. Low fidelity being sketches and such. High fidelity including click-through capability for testing and to replace much laborious documentation. In between – I guess that’s medium fidelity. Then, of course, there’s the concept of mixed fidelity. . . I do agree that higher fidelity wireframes (or rapid prototypes, if you prefer) are often superior communicators – less subject to misinterpretation. It’s much clearer to ‘show’ rather than ‘explain’ how something is supposed to work. I suppose it depends upon the expertise of the creator on a specific tool, as to whether it’s faster.
On the topic efficiency – I teach a class that includes a section on wireframing and in one exercise, one group of students decided to change-up the exercise and use their company wireframing tool instead of sketching. They were surprised to find themselves working through the break to get done, while all the other students enjoyed warm cookies. It’s okay though – we brought them some cookies.
17th August 2011 @ 10:54 pm
The OP is completely missing the point and value of wireframes and low fidelity prototypes in the iterative design process. Talking of ‘Prototypes’ to mean highly interactive representations shows shallowness in understanding. Paper prototypes are little more than wire frames being completely non-interactive and not user friendly. But then they are not designed to interact with.
As others have said, wireframes act as a specification for screen layout and they should also include interactive specifications. For example if a page may or may not display a login module. The suggestion that wireframes are dead is merely an indication of inexperience.
The point of wireframes is NOT to make some paper trail in a backward and archaic organization, which I’m sure the OP would never be seen dead in. It’s to deliver a specification of layout and interactivity and rules regarding how the interactive components work. Without this, it’s simply down to the interpretation of the observer which is unacceptable. Wireframes provide clear guidelines by which designs can be assessed and lead naturally into processes such as usability testing. Just dumping out wireframes as a waste of time is pointless if you then go on to talk about interactive prototypes. Why not just go straight into coding. Oh hang on that’s exactly what you said! Not a UX approach that’s for sure.
Low fidelity prototypes allow ux people to focus on content and layout without being blinded by design. It allows users to focus on getting the basics designed well in an environment where designs can go through rapid iterations, made by non-techies, and get the fundamental design sorted before investing in the bells and whistles. Being able to make changes and just print out or deliver prototypes to PDF is invaluable. It’s not about being old-fashioned or a luddite. Clients often ask this very question and that’s my response. You don’t turn a crappy website into one of the world’s best by skipping all the prototyping levels and just going right to design. And I am behind some of the world’s most successful design projects.
I think this article is extremely damaging to uninitiated ux people, and hope that people treat it with caution.
13th March 2012 @ 2:11 pm
The headline drew me in! I agree with Paul above, in that client expectation plays a bit role here. We build all sorts of software from bespoke digital interactive solutions for large blue chip clients to smaller website projects for SMBs and we’ve found that getting something quick and easy that helps them (and us) get the basics right, identify new requirements and problem solve before it gets to a prototype stage is useful. Using tools we’re already comfortable with means wireframes aren’t a drain on time – quite the opposite in fact. We blogged about our favourite wireframe tools here: http://www.signals.co.uk/blog/2012/3/7/wireframes-made-easy
25th January 2012 @ 1:07 am
You forgot to mention Keynotopia 🙂 Gives the user the option to choose between low fidelity AND high fidelity and you can go from one to the other in just a few clicks. Rapid prototyping UI libraries with no coding required and it looks AWESOME when done! Got mine at Keynotopia.com.
16th February 2012 @ 8:30 pm
I recently wrote an article called “Information Architecture without wireframe”, bringing dozens of arguments in this regard. The article is in Portuguese, but you can read it in English with a translator, this link: http://bit.ly/zFCQhu
3rd April 2012 @ 6:53 pm
After playing with Axure for the last week I came to the conclusion that if you are a developer it takes less time to come up with a prototype using the final platform than trying to make Axure to do the same. It takes me a few hours to do an initial prototype that I can use for the final product. It takes me forever to get anything done with Axure and it never looks good. IMHO is not a good product, limited, hard to modify (those dynamic panels!!!) confusing and resulting in a big bowl of spaghetti with little resemblance to the final product; worst than that… you’ll have to convince your customer that your final product will look much better.
19th April 2012 @ 6:57 pm
Read this: http://www.alistapart.com/articles/dive-into-responsive-prototyping-with-foundation/
Found my new rapid prototyping tool!
Review: Create Interactive HTML Prototypes with Livetyping | UX Mastery
9th April 2013 @ 3:00 pm
[…] then I do wish that my front-end skills were better, so I could prototype an idea in the browser—static wireframes just don’t cut it, and neither do many tools that implement basic linking between pages, but lack the ability to […]
23rd June 2013 @ 1:46 pm
Very useful article. I was about to have a wireframe designed, but now think I’ll take a look into rapid prototyping. Thanks for the info
13th January 2014 @ 9:29 pm
Im a developer (c# & html5 (Sencha/JQuery)) and consultant whom creates wireframes and I am more successful wire framing much more than rapid prototyping. Since I work on many different platforms (web services, web, compact framework, iOS, Android, Winphone, desktop “Mac/Win”, etc) sometimes for the same project & client, look and feel of my wireframes are very quick if changes are to be made with turn around times and customers get accustomed to the idea and not the tool being used.
I then may move into prototype mode, but only its required to clarify complexity. Everyone knows what a drop down is or how a toggle control works. Im not so sure touching one makes a stronger product.
One caution, is if one decides to use rapid prototyping, that the end result does not turn into production code.
Anyway, Balsamic is my tool of choice with help from OmniGraffle and Snagit for Mac. As Beans says ” There is too much time spent arguing over semantics and tools in UX. The bottom line is you need to develop a plan before you build a website. Developing this plan should be fast, clear, and your tools should not get in the way.”
I agree but I also with Smick whom says “Prototyping would take longer”, and depending on how you bill, longer is not good.
23rd January 2014 @ 6:15 am
Hard and fast rules really don’t make sense. Wireframes are useful and so is rapid prototyping.
Saying ‘Wireframes are dead’ is a ridiculous statement.
27th February 2014 @ 6:37 pm
To the Author of this article “Wire frames are dead, long live rapid prototyping”, I first saw the article, laughed, then I came and read and started to agree with lots of points then ultimately started to disagree with some. All in all, I feel good about articles like these because I believe the Author gave it such a Juicy headline almost like something out of the New York times to get people feeling so much different kinds of emotions.
@Stuart Davidson :Very useful article. I was about to have a wireframe designed, but now think I’ll take a look into rapid prototyping. Thanks for the info”
Seem like you just jumped ship with after reading this info. that concerns me as see what can happen with a little info and no research.
I am a UX Designer and I find that as one blogger said “Yes! There is too much time spent arguing over semantics and tools in UX”. agreed.
Stop knocking methods of design and design. Wire frames have their purpose, trying to die them away would be the same as trying to die away prototyping, they are not the same word nor serve at all the same purpose, they are milestones in the process depending on which process you use. That process is by choice of project, client, organization and particular design scenarios, some times one or the other are not needed sometimes all are.
I create and utilize wire frames whether I create them in Fireworks, Balsamiq, Axure, Illustrator, Hand drawn, On napkins what ever have you and they form a very vital part in saving money for companies before committing themselves to lots of the unknown. Now one may agree or disagree however, what we should all agree is, is that we should strive to enhance our skills and methods of selling our concepts more effectively and stop knocking the tools. They cant speak for themselves but with a little creativity we can sure make them seem like they can,
that’s called innovation and design magic.
This article gets us thinking about the pros and cons of and should of been named as such but hey! the title was to juicy to resist so for that i say dam good article, provocative and tasty.
However, stop trying to “MASS MURDER” methods of design instead, start cloning Innovation.
Cheers