Wireframes come in different fidelities. You have low-fidelity wireframes that don’t resemble the final product as much, but still capture the interface layout and controls. Then you have high-fidelity wireframes that look closer to the final product because they display the interface in greater detail.
Most designers are used to wireframing in low-fidelity, but a growing number of designers are starting to wireframe in high-fidelity. That raises the question of what advantages high-fidelity wireframes have over low-fidelity wireframes, and which fidelity is right for your project?
I recently had a chat with Amir Khella from Keynotopia about what makes high-fidelity wireframes compelling to designers, and when they should be used. Here are the key benefits to high-fidelity wireframing he mentioned.
1. You Can Wireframe in High-Fidelity Just as Fast as Low-Fidelity
The common belief is that high-fidelity wireframing takes too much time to create. It can, but it doesn’t have to if you’re using an interface library.
An interface library is a comprehensive library of interface controls that you can use with your favorite wireframing program (e.g. Omnigraffle, Keynote). This means all you have to do is drag-and-drop them on your design canvas. This could end up taking as little time as drawing wireframes. It’s fast, efficient and the result is a wireframe with greater detail in the same amount of time or less.
2. High-Fidelity Wireframes Require Less Client Imagination
People use products, not wireframes. When someone looks at a low-fidelity wireframe, they have to imagine what the product will look like when it’s done. This active imagination may end up taking part of their attention away from the task they’re trying to do.
With high-fidelity wireframes, clients can better see how their layout, navigation, buttons and form elements are coming together because they’re not primitive elements. High-fidelity wireframes also make clients feel like you’ve done more work on the project.
3. High-Fidelity Wireframes Communicate Form & Function Better
Most low-fidelity wireframes communicate function well, but communicate form poorly. This is especially the case for mobile applications that have standard interface components with a consistent look and feel. A high-fidelity wireframe of a mobile application will communicate the user interface form and function better because the wireframe better resembles the standard interface components that users are familiar with.
On a high-fidelity wireframe, there’s also no question to clients about what’s a button or text field because the gradient detail on the elements tell them that. Low-fidelity wireframes don’t give the gradient detail that clients need to tell what each interface element is and how they function. Both form and function are key to the user experience. Reducing the form of your user interface too much could impact how clients view your wireframes.
4. High-Fidelity Wireframes Can Persuade Stakeholders
Imagine you’re about to pitch a new client on your service, or an investor on your new product . Would you show them a high-fidelity or low-fidelity wireframe of the application? Whichever fidelity you choose could make or break your pitch.
High-fidelity wireframes are more impressive to clients because they can better see what the final product will feel like, and get a feel for the quality of your work. This gives them the impression that you put a lot of care and effort into your work. A low-fidelity wireframe doesn’t do the same.
Final Thoughts
These are the benefits to high-fidelity wireframes based on Amir’s experience. But in my experience, the best wireframe style is no style. The lower the fidelity, the easier it is for clients to analyze the site structure. Not only that, but it encourages them to view the wireframe as a work in progress. What’s your take? Do you wireframe in low or high fidelity?
Book
Affiliate
Isn’t the purpose of wireframes usually to sell the concept of the navigation and userflow to the client? I mean, I agree they are prettier to look at, but they distract from the real point: how does the user get from A to B and are all the navigation elements present?
I have oftentimes dealt with designers using their mockups as wireframes. It creates, I believe two issues:
a) the client expects the final product to look like the wireframes. Not a real issue, but mockups and wireframes can be separate
b) the designer may spend too much time on a beautiful wireframe and then leave functionality out, so the developer is left to guess some navigations schemes.
These situations do not necessarily happen, but I believe they happen more often when mockups are used as wireframes.
I agree. I think the client will be distracted by all of the fonts and colors. Most of the changes will focus on the look of the app and not the functionality. I think at least one MedFi wireframe should be presented before moving to the HiFi wireframes.
Another great post from UX Movement.
Yes, high-fidelity wireframes better represent the final product better but there are times when you do NOT want to try to represent the final product; that’s when low-fidelity wireframing is very effective.
Personally I like to start with low-fidelity and work up to high-fidelity.
One major drawback I see with high-fidelity prototypes is that they provide a lot more detail for stakeholders to process and critique. I’ve been on a few projects where high-fidelity wireframes were used too early; turning design reviews into discussions about font choices, colors and icons when we should have been discussing workflow, requirements and how the proposal solved customer needs.
To sum up this lengthy comment I agreed with you on the benefits of high-fidelity prototyping but low-fidelity certainly has its place in the process.
I completely agree with you about the tendency of high fidelity wireframes to get conversations off track. Wireframes should not invite discussion of colors, fonts, etc. In my experience, this happens a majority of the time when using high fidelity wireframes, so I’m not a fan of them.
I also completely agree. It’s bad enough that most of my clients don’t “get” wireframes; to have a high-fidelity one that starts them in on font and color choices would cause even more delay in the project. As it is, the client I’m currently working for could absolutely not understand the difference between a wireframe and mockup.
I make my mockups interactive by using a simple trick: I associate certain elements of my slides to the “Go to a different slide” action.
When you run your presentation, you can click on the buttons and navigation links to go to a different slide. By doing that, it gives life to the mockup.
(I use Powerpoint 2010)
The problem is, high fidelity wireframes will often make the client think more about the color of the buttons rather than the overall layout.
I think both high and low fidelity wireframing have their own place in projects, but in different stages. If you want to clearly define where wil go what, go low. Should you want to give your client a better idea of what the final design will be like, go high.
In my experience the entire point of wireframing in the first place is separating the information architecture from visual design. The more colors, gradients, and fancy elements are included, the less stakeholders pay attention to the big picture: usability. Questions become “can we change that to a red button?” Instead of “should there really be a button there?”
I used to “wireframe” in Illustrator using a number of standardized elements much like your Interface Libraries example. What ended up happening fairly often is that clients became accustomed to those elements. They shrieked when it came time for the visual design phase and things began changing. I have not once had that happen with low-fi frames, saving innumerable headaches.
Another benefit: using low-fi frames communicates clearly to the client: “this is preliminary. This is NOT design. This is to get the essentials down and move on.” In my experience this speeds up the flow dramatically and allows the team to actually BE faster, rather than having clients “feel like you’ve done more work on the project”.
Very much agree. Getting clients to accept the idea of information structure pre-design is enough of a challenge. Anything even design-ISH causes problems.
I completely agree and well said.
I prefer lo-fidelity wireframes (e.g. Balsamiq Mockups). The main reason: when seeing hi-def wireframes some customers get the feeling, that what they are seeing is already about 90% finished – when in reality you didn’t even start coding.
I’ve never bought into the idea that clients are fooled by higher-fidelity wireframes. How hard is it to explain to a client that they’re just pictures without code? And are there truly clients out there who wouldn’t accept that?
That said I also prefer lo-fi because it gets around discussions of what colour something is or other aesthetic aspects.
It’s not hard to explain it, if you have the chance to. For me, working in a large company, it often happened that some hi-def wireframes were sent without any additional comments to upper-management and they were getting the wrong impression.
And your second comment is even more true. I spent hours in meetings talking about blue and orange instead of the actual screenflow, etc.
I’ve never bought into that idea myself, but I hear it ALL THE TIME. Seriously, how hard is it to explain to a client that a wireframe isn’t the final product, and how hard is it for a client to understand that? It’s not hard! 🙂
I’ve had it happen, but with web copy. I myself like to add elements such as ‘Project Title’, ‘Element 01’, and so on to have a look to how the final design will actually be.
The result has been that I’ve had to explain that they’re for filling out space and that they’ll be eventually replaced with actual copy. Some clients even forget about it and then ask about it again on the next meeting, thinking that what they’re seeing is final.
That’s why I simply resort to lorem ipsum the design even if real copy was more appropriate.
While I agree with your points I’d like to add a con to your list. Early on using a high fidelity wireframe is horrible when mocking the general layout up for clients in my opinion. Things look too complete and they focus on how it looks when you are still in the how it works phase. I still prefer a high fidelity wireframe though.
There’s a case to be made for lo-fi and hi-fi, but neither should be eliminated. Lo-fi is good for hashing through ideas and possibilities, similar to sketching. Hi-fi can be good for client presentations or final deliverables to increase credibility or confidence with the client, or even to give them something to show around the office that feels better than a sketch or a blocky lo-fi wireframe.
The danger of starting with hi-fi is that the more time you put into the fidelity, the less free-form thinking you do about problem solving and logical flow. It’ll cause you to get hung up on visuals when you should be thinking about general layout and interaction. As you solve those problems, then you can move into the hi-fi version using what you learned in sketches and lo-fi to inform your hi-fi wireframes.
As for colors, etc., my approach with hi-fi wireframes is to stick to monochromatic (black and white) with the only color added in as “link blue” for interactive elements (links, buttons, etc.).
I absolutely agree to hi fidelity wireframes for any page which will remain until delivery high in functionality yet low on design, typically a form. there are only so many ways to design a drop-down! Therefore the client can’t get hung up on the design and get better the Impact of the page.
I believe in moving from hand-drawn sketches (which is by far the fastest way to capture design ideas) to high fidelity. I sketch using a 5-year old tablet PC and Windows Journal, and I usually have enough detail to skip the low-fi wireframing phase.
I agree that clients might get fixated on the colors in early hi-fi versions, but if you’re using standard platform UI components (e.g. iPhone, Android, Facebook, …), why take away the colors?
I think Anthony did a good job in identifying cases where high fidelity wireframes can be advantageous. User testing and client proposals are definitely two areas where hi-fi is a win.
Using Axure you can develop either high or low fidelity. But the coolest thing is their feature which allows you to turn your high fidelity wireframe into a sketchy styled mockup in one click! So you can ship the lo-fi version to the client while continually refining the fidelity for yourself. Try it >> http://www.Axure.com
I agree that you need to have that option of going lo from hi. As a rule of thumb, first views for the client are lo fi. However, as designers and UX teams you do want to weigh the option of a red versus some nondescript element, especially as you get closer to design. It’s part of being agile and ready to move to the next level or not.
Of course, you need a project that’s got enough budget, time and requirements for doing all this. In many cases, a simple lo fi is the best fit for the job.
And there is the element of client education. Clients who are aware of the steps and process, understand the difference between a hi fi wireframe versus a quick sketch. When you’re working with a client that does a website once every 5 years, well there’s not really any point to talking about the finer points and going through A/B versioning etc, they just don’t have the need for it.
But then again, three years ago I showed a balsamiq mockup to a less web savvy client and had him almost walking out of the room in horror – he thought we were amateurs.
Lo-fi internally, because form follows function.
I can see a case for hi-fi when presenting to clients, if and only if we want to push our case forward, rather than pull opinion back — but was the latter not the point of showing wireframes in the first place?
A valid question is then: should we show wireframes at all, or use them in internal research, only to produce a hi-fi mockup?
I’ve not had a great experience with H.F. wireframes. The client usually has a hard time keeping creative and IA apart in their mind when you do this. I’ve even had clients that couldn’t understand the difference and kept referring to the HFWF’s as “the creative” for an entire 3 month project. Never again >.<
As IAs, UX planner and UEs we have to develop several deliverables and also wireframes sometimes with low-fidelity and sometimes with high-fidelity.
If you ask me whether wireframes are good tools, I would answer, YES wireframes are in general powerful, effective and adaptable. But if you ask me “Are wireframes good for you and your project?” – My answer would be as so often – “It depends on!”
And that’s the same question regarding whether low or high is suitable for you, your client and especially for your project.
If you really believe that you need and or you can start with a high-fidelity and detailed deliverable you can and you should call it a click-dummy or mock-up or what ever you like but not a wireframe.
Maybe this article “Why and why not … Wireframing” might be interesting for one or two:
http://ux4dotcom.blogspot.com/2010/01/why-and-why-not-wireframing.html
The higher the fidelity the more likely the client will begin to form expectations about the final product. Only use them if you are prepared to build exactly what is being illustrated. In my experience stakeholders will ask why the final product is different from the wires if you use high fidelity wireframes too early in the design process.
I think it’s all about context and audience. I use both low-fi, hi-fi and parts in between according to the project and the stakeholders. For brand new designs like a new site or new landing page I use low-fi. I want to keep them on task and first worry about the interface and navigation itself rather than the look and feel. For new or change in current functionality I use higher-fi…not quite hi-fi…because I think it’s a waste of time. If the navigation is not changing and the color and shape of buttons aren’t changing I can just show those and create a better representation of the design overall. That said, for certain groups I will leave certain hi-fi elements out completely because I know they get off course and talk about why we should change the color scheme of the site.
Hi-fidelity wireframes? You mean to say comps -___-
The last time I checked, Wireframes mean exactly that. Wire. Frames. Low. Fidelity.
I’m of the opinion that if you can’t communicate well with basic wireframes to begin with, your wireframes reflect a lack of critical thinking that can’t be compensated with so-called “high-fidelity” wireframes. Everything else is distraction and lack of critical thinking to solve the problem will rear it’s ugly head in production.
If you really, really want to slap a “high-fidelity” label on your wireframes, i suggest you start with paper and pen first, then clean it up in your application of choice then pat yourself on the back!
I don’t think lo-fi wireframes truly keep the focus on usability, because they are missing critical usability data in the form of design ie form, proportion, color, contrast.
As a designer, I’m perfectly capable of screwing up the usability of well-crafted UI through all the pixels at my disposal. On the other hand, I’m also able to enhance the perception of usability through elements of design. Lo-fi UIs by their nature do not address those possibilities.
And I’ve heard many times that clients don’t understand wireframes. I think that’s a canard. In my experience, most clients understand wireframes just fine, but they reserve judgement on many UI issues because we haven’t given them enough information to make informed decisions (such as the elements of design). That’s where hi-fi wireframes _can_ help a great deal.
I have never, ever, ever worked on a project where we did not re-evaluate UIs once we’ve started design. How I’d love it if we were able to get a client to focus on architecture during wireframing and design during the design phase. But it does not happen that way. And it’s the simple fact that clients do not possess enough information to make informed decisions. Not until the site is completely functional.
Agreed, Karl.
And thank you for posting this article, Anthony– I’ve been thinking, saying, and doing everything here for years, and it’s great to hear these points so elegantly put.
I think it’s about the context– what stage in the design process you’re in, and how well you can set the appropriate context for the client on what they’re looking at.
I find that you can discover things while doing higher-fidelity wires that you wouldn’t have been able to imagine while doing lower fidelity wires.
It’s useful to operate between higher and lower-fidelity wires… each has its purpose. To say one or the other shouldn’t be done is total crap.
Of course we all want candy all the time, but wireframing in low-fi seems to place the emphasis where it belongs at the appropriate stage of site development.
The danger of wireframing in hi-fidelity: client “loves” high-fi elements because of their shapes, colors and textures, forgets to look at where they are and what they do.
“Create a low-fi prototype at the first responsible moment, create the hi-fi product at the last responsible moment” -Aslam Khan
One alarming problem with hi-fidelity designs of any type, whether that be prototypes, wireframes, or UML – is that people become attached to them too quickly. Another is that you can get the ‘design’ perfect before you implement anything. Paraphrasing Neal Ford on low-fidelity and iterative design:
I prefer a low-tech approach (e.g. whiteboard drawings) to the more formalized version using tools because of the proportional relationship between a person’s irrational attachment to some artifact to how long it took to produce. If you create a beautiful hi-fidelity wireframe using some tool like Interface Library that takes 2 hours, you have an irrational attachment to that artifact that’s roughly proportional to the amount of time invested. That means that you’ll be more attached to a 4 hour design than a 2 hour one. By “irrational attachment”, I mean that it’s harder to listen to reason as to why it’s wrong because you know how much time it took to create it (and therefore the required effort to update it).
The second failure reason is the implicit assumption that you need (nay, must) design all the elements and interactions before you start writing code. Big Design Up Front is a failed technique in almost all software development. Business processes change like the weather, and you need software that can change just as readily. It didn’t take long for us to realize that the upfront design didn’t serve our clients because it hampered the kinds of changes required by their business.
“There is no such thing as low-fidelity or high-fidelity, only appropriate fidelity” – Bill Buxton
What a great discussion, I posted a comment about the appropriate time to use wireframes and when to use graphic mock ups on another article about a similar product. I got destroyed by the community there.
In hindsight they were web developers creating customer websites based on a set of standard web site interaction paradigms. There wasn’t a huge amount to consider in terms of workflow and usability as they were really just re-skinning the same model each time.
It really does depend on what you are doing but what concerns me most about this article are these two comments:
“High-fidelity wireframes also make clients feel like you’ve done more work on the project.” – so your clients don’t trust you? That’s a great start to that relationship.
And,
“[A high fidelity wireframe]… gives them the impression that you put a lot of care and effort into your work.” – your clients ‘really’ don’t trust you!
A quote from one of our clients when we shared wireframes (the lo-fidelity type) with them “Wow, this shows that you are taking time to really think this problem through and provide the best design for us.”
If you’re a designer you’ll want to check out InVision (http://www.InVisionApp.com).
It allows you to create interactive wireframes (http://bit.ly/textifylow) and high-fidelity prototypes (http://bit.ly/textifyhigh) of your apps in minutes.
Then you can share your experiences with your design team, developers, and clients instantly and gather feedback right on-screen.
http://www.InVisionApp.com
@InVisionApp
Good discussion here (except for the guy spamming for Invision above me).
I’ve seen this article go around on Twitter, and I just wanted to raise a point about #1 that wasn’t mentioned:
The example given for #1 is iPhone. The iPhone has a limited number of interface controls. So, it’ s a lot easier to do a high-fidelity wireframe. The same isn’t true for nearly anything else.
#2 and #4 are true, or at least it’s hard to argue against them.
#3 is pretty much what’s being discussed here. I also believe a low-medium fidelity solution is better for communicating workflow, due to the separation of design. Design can enhance the user experience, but it is just noise if you don’t have a proper workflow.
If you aren’t using interface elements that won’t be actually used on the app or website in your wireframe, then you’re doing it wrong.
I’m firmly of the view that the wireframes or mockups presented should be the lowest fidelity you can get away with with that audience.
I generally use very low fi for discussions around functionality in the early stages then focus in more on the details as the bigger decisions have been made.
Too often in the past I made the mistake of getting into the “that blue colour is too dark” discussion in the first stages. Better to remove all those distractions and focus first on function. Once that’s been dealt with move onto the detail design side.
I agree with the numerous points already made, that so-called “wireframing in high fidelity” is not really wireframing at all, and a dreadful mistake to foist upon clients — bordering on a kind of fraud, since they can only divert away from the discussions that need to happen first.
The fact this odd notion is being pushed by purveyors of commercial libraries of slick UI widgets only makes it all the more suspect.
Do yourself and your clients a favor: do not use these libraries in your wireframes. They may well have other legitimate uses, e.g. for design mockups.
When it comes to hi-fi, Clients tend to get caught up with the look and feel and overlook how functionalities work. This causes a problem when they view the final product.
The advantages of a low-fi prototype/wireframes are
1) It allows the shortest time to market or sell your solutions/ideas under a tight deadline.
2) Make numerous iterations based upon clients’ feedback and enable them to review under a short time frame.
3) Get them to focus on functionalities.
A low-fi prototype can be a combo of
1) Static wireframes
2) A series of click throughs of wireframes
3) Interactive with the ability to show different states upon user interaction.
4) A static screen flow which is useful when the client needs to see the big picture.
I find it useful & effective when I combine any of the above-mentioned for a project to stakeholders who come from various discipline e.g.marketing, engineering, editors…Some stakeholders have no notion of what are the purpose of wireframes.
At times, I will conduct a brief presentation of the benefits/purpose of wireframes in the UX design/development life cycle. It helps to set their expectations and not get confused between a mock-up and a wireframe.
I believe there is no one prototype that fits all and at times, I have to customize based upon the nature of the project.
If the client is getting confused, distracted, or disappointed by the fidelity of your work, maybe you just did a poor job of communicating how the process works up front.
I’m not saying there are those who will struggle despite your attempts to help them understand (and some are just difficult regardless), but a reasonable person will appreciate an overview of what to expect.
Many people don’t want to seem stupid (especially around “creatives”, and ESPECIALLY mid-level people) so they won’t admit that they have little understanding of what’s going on. And worse, their coping mechanism will to become defensive, which is entirely counterproductive.
How you communicate expectations is entirely your choice, and situational besides, so how about you apply your *amazing* understanding of psychology to “client UX”!
Give that butter a chance to warm and watch things just glliiiiiiddde! 😉
Maybe it’s just me, but I find it hard to take this site’s articles about wireframing as unbiased and objective when they’re clearly trying to push sales of their interface libraries.
With that said, I think the time/cost investment of a wireframe or UI mockup’s fidelity is largely a product of time, budget, and audience. There’s a appropriate place for lots of variations.
Context here is the key.
Ciient (upon delivery of final build): “No, this isn’t right, we want the version you showed us in that meeting”.
Non-tech people cannot be blamed for thinking that the finished version is ‘wrong’ or ‘different’ if they have been looking at something that seems like a finished interface, or at least very similar to one.
1 – you are tying the designers hands by creating preconceptions based on a 3rd party’s GUI library
2 – you are diverting the stakeholders attention away from the issues in hand (“yeah that looks good” not ‘Hey, why is it called XXX? We call it YYY”)
3 – You are promising interaction flows that may not be deliverable in the final build.
I love hi-fi wireframes and prototyping, but I am also very careful about who sees them and how they are presented.
I think something that gets ignored quite often when UX’ers start taking about process and tools is that *we are designing software* – not wireframes. SOFTWARE. Many UX designers do not have the mental skills to create the software interactions with their brains before turning to the tools of our trade. First, work out your solutions with a sharpie and a tissue. THINK first. Be the user, thoroughly flesh out all inevitabilities of the interactions you’re proposing. Get to be best friends with your developers, collaborate on what’s possible with the front/back end they’re using. I am often brought in to fix half-assed UX created by new and experienced UX designers alike, because they cannot fully flesh out a thorough user experience. Please remember, this is software design, people… “Human-Computer Interaction.” This is not wireframe design. If you can’t do it with your brain, a sharpie and tissue, you’re not going to be able to do it with any other tool.
Last thoughts:
1. Wireframes with robust annotations are incredibly useful for giving form to vision, but they do have dynamic-interaction blind spots. If you don’t know how to create prototypes, learn. Your mind needs to get exercised so it can think around the blind corners. You are responsible for solving problems your other team members haven’t thought of yet. You have to be five steps ahead. A wireframe is just a representation of an instance of a UI (and content) at any given moment.
2. Lo-fi, Hi-fi – the choice of one over the other is dependent on several criteria: budget, time, audience, purpose/needs. (Don’t look know but you’re strategizing – how you’re going to do xyz and why). Again, you’re solving for the problem of creating documentation that communicate to your team, based on the current situation. Know when to choose which tool, at which level.
3. Its not about you. While you are the owner of UX on a given project, you are the facilitator, the conduit of the UX – you have MULTIPLE audiences, not just your end user. Your client is your audience, so are each of your team members/discipline leads, even your PM, AM. These are all your stakeholders. Your dev is your closest tactical ally, so make sure he/she is involved closely because you need them as a resource.
4. If you don’t understand dev, you need to. This doesn’t mean you need to be a coder, but you should get to a point where you know the lingo, the terms, the interactions and dependencies of various current technologies, both front and back end. You need to know what is driving the underpinnings of the elements you’re wireframing – databases, CMS’s, widgets, modules, etc.
5. Process. Own it, know it, love it, evangelize it. Again and again. One of the comments above mentions prefacing wireframe presentation with how they are to be viewed. That is a must. UXers should be very comfortable with doing that, often. Describe to your clients what they are, and what they are not. Same for sitemaps. Give your clients the mental preparation up front about what articles you’ll be creating and presenting, and how they fit into the ecosystem of software design. I have a process diagram that maps out each step of the process. At any point in time, they will be able to see where we are (or should be). It notes who’s involved on the agency side, docs produced, dependencies, and milestones. You should know your process well-enough to recite it from heart. It should be your religion.
It’s still okay if you are the only person involved in the whole design process. Problems I have faced when working with visual designers (I am an interaction designer) :
1) Once you present a client with Hi-Fi wireframes, they start expecting the end product along the same lines.
2) The visual designers face problem either in re-creating the content or working with stilted creativity (little scope of improvement).
I find that it is all about … what you’re trying to get them to sign-off on.
I feel that introducing Implementations before we get the functions and flow figured out is dangerous at best. Form follows function. You might find yourself being asked to do stupid combinations of things in a meeting. I use simple but expansive wire frames and then after we are agreed that I am on the right track I show “Style Tiles” that are pulled from the companies style guide and or my own designs. Style tiles work great for letting you express your artistic design without all the work of a mockup or hi-fi wireframe.
Isn’t ‘hi-fidelity wireframe’ an oxymoron? 😉
I disagree with most of this post.
I believe in lo fi, separating form from function. Lo-fi can still effectively communicate information hierarchy and I get the point that making a button ‘look’ like a button helps read a wireframe easier but there are ways of doing this that does not involve beveled edges, gradients or other generic tired design tropes.
If you are using ‘hi-fidelity’ wireframes to win work in a pitch (so using them as a sales tool) or to show how much work you have done then you don’t get what wireframing is.
If you need ‘hi-fidelity’ wireframes so that the client ‘understands’ them more, then you are not doing a good enough job in contextualising and presenting your wireframes.
I understand the temptation to make wireframes ‘look pretty’. Resist it. If you can’t resist it, then you are probably a frustrated interface designer rather than a UX designer.
(also agree with CF above, specially about prototyping)
I only recently started using wireframes and, not sure if it’s just because the clients are so absolutely unfamiliar with websites or what, but the wireframe ended up causing trouble. When the design part came – they actually said – this doesn’t look like your mockup 😀 The “mockup” was the wireframe – not a mockup! They actually WANTED their site to look like a wireframe I guess… totally weird! So ever since then I’ve had trouble with the design and pleasing them. Bizarre but true. I love this tool, though, thanks so much, will probably use it in the future.
Wouldn’t it be great if for any given interface library there was a rotary dial to adjust the level of fidelity according to maturity of the design?