Wireframes are one of the main tools in the user experience designer’s toolkit. Most usability and web design books devote a considerable section to sketching, paper prototyping, and other forms of planning. But while I agree wireframes can have their place in some projects, I think they are actually detrimental in a lot of cases.
A new environment
In recent years, a few factors have started shaping the world of web design and development in a new direction. I’m talking about things like:
- The emergence of frameworks like Rails or jQuery, and services like Heroku or EC2, who all contribute to minimizing development time.
- The success of 37Signals and other bootstrapped companies which show that you can be successful with limited resources.
- The lean startup movement and the notion of minimum viable product.
All of these things have come together to create an environment where web products are quicker to develop, focus on fewer features, and are flexible enough to adapt to a changing market.
The downsides of wireframes
I’m increasingly unsure that traditional wireframes have their place in this new landscape. It’s a basic truth of the design process that the more time you spend working on something, the more attached to it you get. So if you spend hours on a Photoshop mockup, you’ll probably hesitate to discard it even if it becomes apparent that your design doesn’t work in the browser.
A wireframe’s rigid boxes and simple aesthetic can provide comfort compared to the web’s chaos. So even though we should all know better, it’s easy to get attached to a wireframe. You might not think this is a problem. After all, we often hear things like “a good prototype is 50% of the work”. But think about it, this means that you’re restricting your options at the earliest stage possible, before your product has even been used by a single customer!
What’s more, obsessing over wireframes can eat up valuable time, without much to show for it. You can’t even be sure that the solution you found is really better than any other. Wireframes are usually not interactive, and unlike Photoshop mockups they don’t show you contrast or hierarchy, color or typography. It’s easy to find a solution that “works” when most of the problems aren’t addressed at all.
The right way
So what are you supposed to do? In many cases, wireframes are used to kick off a project because they’re relatively fast to create. But many designers work just as fast in Photoshop, and good coders can whip out a html/javascript prototype in a couple of hours. So first, you should ask yourself if you need to use static wireframes at all.
Pinboard: probably didn't use any wireframes (or Photoshop)
If you do use them, make sure everybody understand that each step of the process exists to support the next one, not dictate what it should be. The wireframe should remain a tool that helps with the creation of a higher fidelity mockup or html prototype, not a perfect blueprint for it. This means that no part of the wireframe should be off limits when it comes to changes (and this is also why I don’t raise a stink if a client’s finished product doesn’t look exactly like my Photoshop mockups).
Beyond wireframes
If you want to go beyond wireframes, there are alternatives. For example, a simple list of a page’s element can be a surprisingly effective way to guide a designer without influencing him, and keeps the focus purely on the content.
Balsamiq Mockups: am I the only one who finds this ugly?
But in my opinion, the ultimate replacement for a wireframe is simply the site itself. This might come as heresy, especially on a design blog, but I actually advocate for development before design whenever possible.
Why force a designer to work from uninspiring and ugly (there, I said it!) Balsamiq mockups when you could simply give him access to your test server and let him try out your prototype by himself? Don’t be ashamed of your site’s bare looks. After all, if you’re not ashamed of your first version, you’ve waited too long.
So here’s my takeaway on wireframes:
- They can be a useful tool for people who can’t design and can’t code.
- Getting attached to them is a surefire recipe for wasted time and energy.
- Wireframes are guidelines, not blueprints.
- Ask yourself if your time wouldn’t be put to better use actually coding or designing.
How about you, do you use wireframes? Have you ever encountered some of the problems I talked about?
Update
I just had to quote this answer by Russel Jurney to the question “Is it important to create wireframes before building your webapp? Why?” on Quora:
Absolutely not! HTML is a wireframe. Your prototype is your spec, and can be improved and iterated to become the final product. Spend that wireframe time iterating against analysis of real use of your prototype and you will build better stuff.
I couldn’t have said it better myself. The fact that this is currently the most up-voted answer gives me hope!
Elsewhere
There are a couple good threads going on about this post around the Internet:
Pingback: Tweets that mention Why wireframes can hurt your project | Attack Of Design -- Topsy.com
I have developed wireframes for several projects I worked on. An interesting observation is that most clients do not understand them, and, moreover, do not want to understand them. They know very little about your professional approach, and they just want to know what the product will do, what it will look like, and, most importantly, how much it will cost. So instead of wasting time on developing wireframes, a good designer should spend more time listening to his or her client (because they know their business very well), then refer to an ever-abundant pool of themes, templates, scripts, and other ready-to-use solutions, and then customize the selected options to fit the client’s needs the best way possible.
Great post. This has been a growing belief of mine for several months now. I increasingly find wireframes to be a hinderance rather than a help. I do understand that they can be very useful for people who aren’t designers, but from a design point of view I find the most useful guide to be a simple, prioritized list of page elements.
Again, really good post.
Good point about using a prioritized list of elements. Asking for explicit prioritization forces people to think about the goals of a page, whereas a wireframe distracts you with things like “should that button go on the left or right side of the page?” that are better left for later stages.
@Matt now you say
I agree with what you’re saying, however, the real issue and main reason for wireframes is usually streamlining the project process and negating the problem of scope creep and millions of unnecessary client changes.
So, it does depend on the client.
I agree with Matt and Gary.
When working on my own projects I normally find the best way is just to get straight on to building pages and databases. As I build the HTML/CSS side of things I tend to have a big .psd where I gradually collect any visual elements as I make them – kinda like a mood board I guess to make sure buttons and logos work together and I have a consistant feel.
However when working for a client I think agreeing on a wireframe before building the site can be helpful – it’s a spec. Otherwise the amount some clients will expect you to ‘creep’ is just rediculous. And then they tend to realise you were right all along and you go back to what you’d done originally!
Interesting points, but I disagree. I do believe it doesn’t make sense to just use a method only because it’s currently hip. So using this technique no matter what may cause problems. But…
I am working in the games industry, and usually with a very big team. There are many people from many hierarchy levels involved, and using wireframes Is a very effective way to get all “in the same boat” at a early stage. It’s an awesome orientation for both coders and artists and it already went passed a bunch of eyes – so many obvious mistakes were fixed and it went through a bunch of iterations.
To sum it up, I actually believe it depends entirely on the circumstances.
I agree it does depend on the circumstances, but for the circumstances I’m talking about (developing a minimum viable product to validate your business concept) I believe wireframes are often counter-productive.
Of course, if you’re working on a big project with many people, it’s a different matter. I also assume that when developing a game, it’s harder to “pivot” and change key details midway through development.
Sasha, I really enjoyed this post. I am a UX consultant here in Bangkok and I love challenging posts like this.
I totally agree with you and actually you have woken up something that I might try, designing first in Photoshop. I`ve used it since Version 3 and as a result I can moc something up with a client quite quickly.
I have never been an advocate for designing in a browser, it is far to detracted from design as #ff9900 does not tell me if it fits with #ff91AB or whatever.
Wireframing has it uses like you said it detracts from the noise and I have found it a very useful tool. With regards to interactivity try FlairBuilder, not only looks better but it has a level of interactivity most wireframing tools do not.
Great post and if you would be interested I would love to interview you for our website http://www.webcoursesbangkok.com/category/blog/interviews/
I’m not a fan of purely designing in the browser either. I’m advocating more for a flexible process going back and forth between the browser, Photoshop, and maybe prototyping tools if needed.
Basically, you just need to avoid the trap of seeing a site design as a linear process with well-defined steps.
In terms of raw efficiency, I prefer sketching with pencil, pen, marker and paper for wireframes (and sketches in general). It makes the process of getting things done far quicker and it kills the idea that what you’re doing in this state is precious.
I hate the idea that fresh ideas are finished or precious. It’s raw, still-bleeding, still-developing! It isn’t perfect! So don’t be afraid to cut it up, bash it to bits, reformat it and do something else!
Bring comps to a meeting, people are squeemish about drawing on them. Bring pencil comps, people draw all over them. And that’s what I want at this opening level.
I’m with you here–most wireframing apps take as long to use as actually doing most of the real design with PhotoShop, but NOTHING can compare to sketching for speed, rapid iteration, and malleability.
Great post. I like to do quick scetches and list out elements but nothing much beond that.
My boss was never a big fan of them because like you said it just wastes time when I could just be working on the design.
The only time we do wire frames is when we are working on a large project that needs to go threw a lot of people and approvals.
They have their place but for the most part just avoid them.
I think you can use wireframes to mock up interaction though, for a tool like Balsamiq you just have to use your tools a bit more creatively. I rarely ever use the built-in functions like tabs because they look so dated and can instantly turn off your audience just by appearances. Instead I use the containers, horizontal lines and other elements of Balsamiq to imitate the design I would eventually code up. That way I don’t have to spend as much time as I would with a high-def mock-up in Photoshop but can still get my UI ideas across (and get them pre-approved by directors, etc…which is perhaps the MOST important thing!)
I agree with this, planning is the key part of the project but wireframes are not.
I use wireframes when where developing a project to a specific layout that we need the design to stick closely to, due to the tech we are using.
I used to produce lists of page elements, but over the last few months I’ve discovered that sketching a rough wireframe works better. It helps me realise what’s missing from my list of elements, some concepts are easier to draw than to describe in words, and it’s easier to get feedback from stakeholders.
The intentional incompleteness of sketches is used to identify holes and relationships. Anything with higher fidelity (Photoshop, HTML) looks finished which in many cases shuts down necessary discussions which equates to room for improvements. It helps working through ideas, communicating them and iterating. Designers record and reflect what they are hearing and seeing and capture results of meetings and document them.
Important to note (as said before) is that designers need to know when to move on and creating higher fidelity mockups and prototypes. I agree.
I’m very glad you made this comment, because it raises a key point in my argument: higher fidelity outputs should not shut down discussions! That’s a problem with the design process in itself, but I find that more and more people understand the notion that a site or app is a constantly improving and living thing, not a static product.
I have a background in programming and I just want to echo something that you said only parenthetically:
“(and this is also why I don’t raise a stink if a client’s finished product doesn’t look exactly like my Photoshop mockups)”
This is often hard for designers to live with, and can cause unnecessary rework and often times can hamper innovation. Commonly more usable or innovative features are lost when designers (and involved clients) are too focused on the original *approved* designs.
Don’t get me wrong, it breaks my heart when something gets left out from a design or is not implemented like I pictured it. But unless it really breaks the experience I usually let it go.
I’ve found that it’s impossible to control every single aspect of a design once it goes live. The best you can do is make sure beforehand that your client shares your concern for pixel-perfection, or else educate them during the design process.
Although this was an interesting post, I very much disagree. Here’s why:
1. Using wireframes is a good way to make sure that you are on the same page with your client in terms of the major overall structure of the site. Without this, things can easily be confused, and changing them in a finished design (vs. a wireframe) is a total waste of your time and the client’s money.
2. I used to do photoshop and html mockups exclusively, and recently switched over to wireframes. I have found it to be a much easier way of getting everyone on the same page, and decreasing confusion about major elements like navigation and basic placement of elements. So I’ve been on both sides.
3. Research has shown that mockups (especially those produced in a hand drawn or sketched out style) promote discussion on the site’s design, whereas polished mockups discourage it. As a UX practitioner myself, I have found that discussion about the major structure of a website is extremely important, and without it, will possibly lead to issues later on.
I think all your points in this article are valid. Yes, I can make a photoshop and/or html mockup in a few hours. But at the same time, I can do a wireframe in a few minutes. If this ensures that the client and I are in agreement with regard to the most important aspects of the site, saving time later on, I would say it would be a very poorly informed decision to leave that stage out of the process.
I agree with Jenius.
The idea of a wireframe is something you can quickly sketch, rip apart, start over, cut into little pieces, and tape back together again. The whole idea is to foster flexibility and non-attachment.
Perhaps it is not what they are, but the way they are being used, that is wrong.
If you are somehow attached or committed to a wireframe you are definitely doing it the wrong way.
@Jenius: Thanks for taking the time to reply in such detail!
You say that wireframes allow you to get everybody on the same page about major elements and placement of elements. But my concern is that wireframes do not provide enough information (both from an aesthetic and functional point of view) to make those decisions. Maybe for you they do, but I know that personally I want to make the decision of where to put a button based on what it looks and feels like, not on a black rectangle that says “button here”.
I don’t feel enough confidence in a solution until I can see a photoshop mockup or html prototype. So for me wireframes might be a good tool to generate ideas, but they’re not something I’d show a client unless there’s a strong understanding between us that this is nothing more than a throw-away sketch.
@Tai: I think you (and other commenters as well) nailed it. There’s nothing wrong with using wireframes for yourself to generate ideas, but they can be counter-productive when they’re submitted to a client (or received from a client) as some kind of blueprint. This might seem obvious now, but it’s a distinction that I didn’t fully realize myself before writing all of this.
In my experience a lot of people see the design process like this:
1. Wireframe: create an outline of the site’s layout and function
2. Photoshop: make it pretty
3. HTML: make it work
Where in reality, those three steps are not linear at all.
All the comments provide great discussion. I think it’s safe to say, 1) Know your audience, 2) Know your product, and 3) Know the project’s goal as to what tools you use and how far you take them.
But in this particular thread, there are valid points that all three (@Jenius, @Tai, and @Sacha) of you make that can be taken away as long as the three points I mentioned above are known.
In our office, wireframes are quick and easy artifacts to get our ideas on the table and figure out which idea(s) to move forward with. You may or may not share them with a client, but you do share them internally.
Then you take it to the next step of prototyping just enough to gain understanding about what will take place on a page. This may involve prototyping only some functionality for simple projects or several pages for more complex flows and interactions. Some design may be involved, but don’t get into the detail yet until everyone is on the same page.
As you mention, some people can get stuck and spend too much time in the wireframing phase. But the same is true for prototyping. Both tools are meant to help your team find the best solution to a problem in a rapid fashion that will save on rework later, but the ultimate goal is to bring the project to fruition.
And no, it’s not a linear process; it’s iterative. Bringing feedback in early and often (and quickly) helps move the project along.
Thanks to everyone for sharing your personal experiences. Lots of good points.
Look at all these responses!
I still think that Sacha and I are not on the same page as to the core of the issue. Perhaps it would be more clearly articulated with a story.
Client X and I are discussing a project. As I always do, I suggest we arrange a phone or Skype call to initially discuss the macro site elements, such navigation and what content should go where. We each have an idea of what we think the site should look like, and what the other person thinks the site should look this. We attempt to share these views and make sure that both of our mental models of the design are aligned in a conversation, and when I think I have understood correctly what the client is looking for, I tell them that I think I understand what they are saying, and I’ll send back a quick mockup to them in a day or two to make sure that I did in fact understand it correctly.
After this, one of three things happen. Either they see it and suggest another idea, element, or piece of content that they did not realize that they wanted, which happens very often and is encouraged by the sketch-looking design of a wireframe (wireframes have been shown to increase discussion on design and layout), they mention that there are one or more elements that they were envisioning a different way than I had and would like to see a quick change, or they say ‘looks good’, and we move on to the next stage where I flesh out the design in photoshop.
Now, what if this stage were skipped? As I mentioned earlier, this can cause a huge waste of time for you and money for the client if you put so much work into an elaborate visual design and then they want a change. I think it would be a mistake to skip over the wire framing stage, and a disservice to your client.
I think that it is without a doubt important to establish understanding between you and your client that wireframes are throw-away sketches, as Sacha mentioned, but it is easy to make this point in an email or over conversation and eliminate this problem entirely.
I would like to dispute one of your assumptions, which is that changing a Photoshop mockup takes more time than changing a wireframe. For me it’s simply not true, maybe it’s due to the way I use Photoshop, or the projects I work on, but in my case I can iterate on a Photoshop document without problem.
But what if I get it totally wrong the first time, so wrong that my work is beyond useless and my time was completely wasted? Wouldn’t a quick wireframe have prevented that?
Maybe. But if that’s the case, then I’d argue there are deeper problems than just the lack of a wireframe. This would mean that I haven’t understood the problem properly, and didn’t know enough about the client’s needs.
And for me, this needs to be fixed earlier in the process, by communicating more with the client first.
I can’t possibly see how making a change in photoshop could go quicker than using balsamiq. I could see it possibly argued for fireworks, but photoshop simply is not built as a web design and layout program. I’m not saying I take an excruciatingly long time to make changes in photoshop, I’m just saying I can do it in literally seconds in a program like balsamiq.
Next, you said:
“But what if I get it totally wrong the first time, so wrong that my work is beyond useless and my time was completely wasted? Wouldn’t a quick wireframe have prevented that?”
This is not in response to anything I said. I’m not really sure where it came from at all, in fact. I never presented complete design and communication failure as something that happens to me, or as an option in the little story I wrote.
But in response anyway, I think that if that situation arose, apart from the fact that one would clearly have some communication issues to sort out on the side as you mentioned, a wireframe most certainly would have helped, a lot. I would rather have wasted a few minutes of my time and the client’s invoiced hours on a wireframe than a couple hours that I spent on a polished photoshop mock, if both were equally failed.
I’m not saying that I am retarded and can never understand what the client wants. I usually just get a go-ahead on the wireframe right away. But I also would never claim that I am good enough to always guess exactly what every client wants on the first try. And I think if anyone did say that, it would be not only arrogant, but totally false. This is why wireframes are a better solution, because I realize that I am not always right.
It’s just like writing a paper. Let’s say that you have 2 options: go in and talk to your professor about your idea and make sure you are going in the right direction, then write the paper, or just write it without asking, assuming that you are going in the right direction. Sure, going in to talk to your professor is going to be a half hour loss of time in your life. But for the reassurance that everyone is on the same page, I will gladly take that small loss, every time.
I think something’s confusing the discussion without being apparent, resulting in everyone understanding why they’re right but not why the others seem so certain.
Sacha is, I believe, talking about companies designing projects for themselves, where internal team discussion and shared concepts largely ensure that the project is headed in the right direction.
Jenius (and others) are using the key term “client,” where the work is being done for a 3rd party. In this case the likelihood of misunderstanding is tremendous, and it’s where a finished-looking comp can seriously blind the client to the actual functionality, mostly due to inappropriate focus. A great-looking comp commonly results in the client focusing on “this is too red,” and “our logo should be bigger,” etc., instead of what the project is supposed to functionally do. Wireframes strip all of that away and help ensure that everyone is on the same page before the visual design discussion gets underway.
As such, personally I agree that skipping wireframes for an internal project can be a great idea, and skipping them when working with a 3rd party can easily be disastrous.
Sacha i’m sorry to say this but you’re trolling a bit.
“I think they are actually detrimental in a lot of cases.” In my opinion it’s all the way around, a lot of my customers want to see someting befaure photoshop (and not only specs cause they’re not in this business from small to very big companies)
You remind me my old company when we needed to increment our UV/month with title like that…
And people here are trolling with you .. good job dude it will bring you more followers
Would there be 39 comments (and counting) if I wasn’t trolling?
Of course the title and the article are meant to be provocative. But the fact that some people agree with me (even if we’re a minority) means that there was something valid about my point…
And even if there wasn’t, well at least it generated this great discussion!
I disagree for projects that have more then standard website functionality.
IMO if a (graphic)designer allows the Graphical design being influenced by the wireframe that was created initially, he/she’s not a very good designer.
Also the fact that balsamiq wire-frames are “ugly” is intentional and a good thing.
For larger projects it makes sure you don’t get into design discussions with clients before the actual functionality is “fixed”.
In many cases changing the functionality of a web app during the process can have substantial graphical design implications, which is something I prefer to prevent if possible.
If the wireframe should not influence the design, then we agree that their role should remain generating ideas and exploring various directions (like a mood board for functionality), but not necessarily planning out the site’s design or layout.
Actually I was talking about client work, too. If the client starts obsessing about the color at an inappropriate time, I’d say the solution would be educating them about your process.
But if you really want the client to focus on functionality, then a solution could be developing a prototype of the app first.
Of course you might need some basic sketches or simple wireframes to do that, but not the kind of high-detail wireframes that are usually being used.
I think you’re all right and all wrong at the same time. I don’t think this is a black and white issue and I don’t think there is one way to communicate designs with clients.
I’m a User Experience Architect and obviously create wireframes all day long. However I use them to collaborate with my designers and developers. After initial brainstorming sessions I quickly create wireframes, using Axure, to mockup ideas.
I work closely my designers because obviously they understand layout and design far better than I do and I’ll incorporate their ideas into the wireframes. I’ll add interactivity to the wireframes so that we can discuss our solution with dev so we understand any technical constraints that we need to consider.
After this we’ll present the solution to the client and get their feedback. I’ve found this to be highly effective and used it on many website designs, web applications and mobile apps.
Finally, the only other thing I would say is… wow using photoshop to create wireframes is tedious and takes forever. I’m fairly proficient in photoshop and I would never use it to create wireframes takes too long and you can’t iterate fast enough.
i am always flipping and flopping on this issue, but the real goal of my comment here is i want to compliment the design of this blog. hands down the best i’ve seen to date.
Wow, thanks! That’s high praise indeed.
Pingback: A simpler and faster alternative to wireframes | Attack Of Design
Pingback: Sacha Grief – Freelance Designer from Paris | Interviews | Web Courses Bangkok
I use wireframes to get structures signed off, they worked perfectly for me
I love articles and posts that generate a great discussion that trumps the post itself.!! Good Stuff!
I would have to say that I too flip flop on this issue. I believe wireframes serve an important function in the concept and early design phases. Personally I know it gives me a chance to step away from color schemes and icon placement and worrying about the contrast of the background to text etc. and lets me truly think about HOW the site will function.
I used to NEVER use wireframes but since my adoption of them can say that my final photoshop designs have greatly improved and they take less time, especially if i have a rock solid wireframe. Everyone works differnelty though as you can see in the comments! Good stuff!
But how do you judge if a wireframe is “rock solid”? What do you compare it against? Is it about your own gut feeling, or just the client signing off?
Rock solid might have been a bad term, as modifications are typical in the design phase of a project, but if you don’t have confidence in the wireframe, the design phase will suffer.
for me a rock solid wireframe 1) makes extreme common sense 2) everyone on the dev team and the design team signs off 3) client signs off because you’ve done a good enough job with the wireframing phase that there are no more questions.
haveing a decent wireframe lets me relaxes the right side of my brain and lets the left side do it’s thing…. be creative.
Checkout Microsoft Sketch Flow – interactive wireframes with built in support for exporting to other design tools
The title of this post should be “WHEN wireframes can hurt your project”, because:
– No guru has the speed of a wireframe builder – totally disagree on that point
– Any person can learn to wireframe quickly.
– You can generate much more alternatives to show a client.
-You don’t have a “finished” look to show your client – because when you show a finished look, then YES, you have restricted your design.
– I could go on forever, but resuming it really depends on each person’s method of working or project situation
To be honest, if I really wanted to bring in the pageviews I would’ve just titled this article “Why wireframes are hurting your project”. So I think my title is still pretty mild.
I disagree with your post. By saying wireframes are a waste of time and that by instead focusing on making the creative design instead you spend more time focusing on the pretty picture and not the content. You are also expecting designers to be usability specialists, content specialists, architects all at once. When you do that things are easily missed when creating a site because you are doing too many things all at one time.
Sure someone can give a designer a list of items and content that goes on a page but will that designer know how to organize that content to best serve the needs of a user? Would that designer know how content on one page influences other pages on the site and how users access those pages. Does the designer know basic usability and best practices so that when they place content on the page they do it properly?
You mention that when you work on something a lot you get invested in that product and find it hard to change. Well it’s the same thing for web design isn’t it?
I always laugh when designers think they can architect an entire site just because they know some code and know how to use photoshop. Please stop underestimating the work of others and over estimating the work of design. Unless you have a good base a design no matter how creative is worthless.
Will that designer know how to organize that content to best serve the needs of a user? Yes, of course! A designer is a usability specialist, information architect, content specialist, and much more.
I think we have a completely different conception of what a designer does…
And I think you over estimate what a designer does and underestimate everybody else
You say you designed this website and as a designer you are also a usability specialist? Based on your how your comment form is designed you don’t even know the basic principles of usability best practices.
Well, it’s usable enough that even you could use it!
I use a simple tool to create wireframes called WireFrameSketcher. It’s quick and easy. I spend more time focusing on the back end in the software development projects that I work on, but when it comes to getting the ideas out of the business customers head and onto paper in the form of a deliverable, wireframes have been invaluable. I wouldn’t ever create my wireframes if it were a significant investment – that’s why the tool I refer to above is so great (in my opinion).
The problem is not the wireframes themselves, but spending too much time on them, obsessing about every detail, and also thinking of them as something sacred that must never be changed.
Wifreframes are a powerful tool for visual communication (i like them with user stories). People like to know in advance what they will get (at least a rough estimate), even if the cost of change is low (think when you hire a lawyer, for instance).
Of course it is not the perfect solution for every situation. But nothing is.
I agree that Wireframing really does take up a lot of time in a project. You need to plan out the site, plan out pages and make sure nothing is missed and that is what wireframes accomplish. If you jump straight to design you make room for error.
Sacha, I think that designers like you who feel wireframes are not necessary for a project are simply cutting corners so that they can create a project fast and then quickly move onto the next one as soon as possible. You are creating a website not a burger at a fastfood joint.
Great post! Check out Tiggr – http://gotiggr.com. With Tiggr, you can create and share real and interactive prototypes in a web browser. There is no more gap between a picture and the site. Your prototype is in the browser.
Sacha, you may be an exceptional User Interface/Usability Expert and a tremendous designer with a solid knowledge of Information Architecture and front- and backend development, but most people aren’t.
Wireframes or sketches, whether they’re in a digital form or on paper, are invaluable for the success of a project.
Wireframes are the blueprint of a project, a discussion point where information, technology and design comes together and form a raw consensus about the functionality of the project.
First, you say that you can just as quickly present a end-result page in Photoshop as you can sketch out a functional wireframe, that’s nonsense and everyone knows that.
Secondly, there’s a comment about ‘educating the client about your process’. Trust me after 15yrs experience, you’re not going to teach the client one thing and they shouldn’t. A client can’t distinct between functionality and visual appearance, they just see a pretty picture and judge it.
Thirdly, having a wireframe as a backbone reference, a starting point will enable you to hand of your project to another designer. Based on the wireframes (functionality) and one or two designs they can finish the project successfully in case you have to move on to the next project or get sick or something.
Fourthly, a successful project is one where the client is satisfied and you making money out of it. Good developers (= programmers) have no idea what constitutes a User Experience. Great designers (= UI/UX) have no idea what is the most time efficient way to solve a problem.
Making either Technology or Design the starting point for a project will inevitably lead to wasted time.
And that is why Wireframes/sketches are such a great tool. You force designers and developers to solve a problem together unrestricted of any previous code base or designed mock ups.
I disagree. Wireframes are the perfect hand holding tool for your client so that they know where everything is going to go.
I use wire-frames internally because I like to think about my user. Give them options before I show the client anything. Then I can start my Photoshop mock with a clear/clean conscious and jump into PS with the grid on.
Recently, in our shop, we’ve started doing wire-frames with the client AFTER the initial design mocks so that the client knows what content THEY are supposed to supply us.
Not a waste of time at all. In fact I know that it’s saved us from having to do more corrections later. Plus you don’t always HAVE to follow your wireframe to a T.
-Tim
Pingback: In defence of wireframes « Cookie Dough
Wireframing helps the ‘tards in Marketing understand what’s going on. Beyond that, if you can find a way to get your stakeholders to actually give you a decent requirements list, I could see how going right into development would be doable.
Pingback: The Great Wireframe Debate | Attack Of Design
There are a lot of disagreements about what exactly constitutes a wireframe. There’s a range of implementations that are all frequently referred to as a “wireframe,” probably mostly because it sounds like a cool term and makes the marketing folks feel smart.
However, if you just think of them as “sketches,” their value becomes a little more defined. Wireframes are most useful for showing the flow of a process and giving the stakeholders the understanding of what’s ON a page without worrying about what it looks like, specifically. If you’re building an app in a small team and setting your own requirements, by all means drop wireframing out and “sketch” in code (which is a more comfortable environment for developers anyway). If you’re looking to secure buy-in from non-technical folks and need to map out the processes they’re buying into without burying yourself in code, wireframes are the way to go.
Example: we’re currently starting up work on a multi phase project using Drupal as a base. We are going to do a proof of concept using standard Drupal modules, but we’re changing the workflow to fit better with the requirements of the project. Phase 1 deliverables are a Drupal install p-o-c, a detailed wireframe spec and a few sample look-n-feel screens. Perfect use for wireframes: they become the spec that we’re working towards with the Drupal setup in phase 2.
The point that I agree with you on is that the project needs to dictate the tools, not the other way around. You don’t build wireframes just because that’s what the textbook says to do, you build them where they make sense.
Not sure if that made sense: we’re making a Drupal p-o-c which isn’t going to worry about looking and behaving like the wireframes in phase 1. That’s for phase 2.
Yes, that makes sense. And I think that’s a good approach.
Comments are worth reading, just like the post. Really nice wor, Sacha!
I’ve been working in Photoshop for 3 years already and only this year I come with the necessity of wireframing. But I do admit that I can’t create wireframes, it’s absolutely useless as I can’t show design, neither interaction. As for big projects with good budgets prototyping is the best way to lay out all the interaction.
Wireframes create very poor presentation.
Pingback: Fábio Caparica » del.icio.us entre 05.02.2011 e 02.03.2011
Pingback: plain mag » Archive » UI & UX + Wireframes
Excellent post!
I have recently written an article that readers here might enjoy – it’s about the use of static mockups to simulate dynamic interfaces in advance of HTML5 “Fluid” UIs becoming more widely used:
http://fluidui.com/2011/03/18/is-static-enough/
Cheers,
Ian
Nice post.
IMHO, if I can just draw something on screen instead of scribbling on a paper, And I would export in to a common image or pdf format, than I would always love to do wireframe for my clients.
Comparing to photoshop or html, this is far easier and will consume less time. Benefits..? They are greater of course.
by the way, nice commenting system you have!
Cheers mate.
Pingback: Wireframes – Worth Their Weight In Gold | Domain Slasher (www.domainslasher.com)
Pingback: Litteraturliste | cmyk101
Pingback: What’s wireframes, precious? « Todd Soligo
Pingback: Website Wireframes: Necessary or Nuisance « webelwriter
Pingback: User Experience Link Roundup | crackedhorizon