You need to set the expectations for what you are trying to achieve with the wireframes. Whenever I am showing wireframes to a new stakeholder, I tell them what type of feedback I am looking for. Most of the time for wireframes I am trying to have a discussing on the user flow, organization and basic content of a project. Does this flow achieve what we are trying to accomplish? Is it technically feasible? Does this new feature help our customer? Are we providing the right content?

During this phase I am not trying to discuss color, typography, graphics or animations. It is a waste of time for everyone when you need to discuss foundational information and teammates are distracted by look and feel.

If you work at an agency or very bureaucratic corporate environment and need "sign off" on specific details of a design, wireframes are probably necessary. If you're just trying to get things done and iterate- just do some sketching and then make it high fidelity in Sketch. Wireframes are a communication tool, not a mandatory design step. If you feel that a wireframe can help fill a communication gap, then use them.

I wire almost every project that does not already exist. The main reason is to focus myself and the product owner on content and architecture. If I'm working in hi-fidelity then I find myself getting in the weeds about visual design decisions. The visual part of design is a separate conversation from content and UX and can be overwhelming for everyone when trying to address both simultaneously.

The wireframe step in my workflow also gives me some wiggle room to make bigger design or UX changes (which happens often). There's nothing worse than being locked in early on a poor decision that could have been avoided had I spent more time thinking things through. Hope this makes sense.

Take all the above from the perspective of an agency designer where budgets are always a constraint. I just recently left a software development consultancy after 4 years as a UX team of one. I'm now seeking an opportunity to join a product company.

I personally think there's a big difference between sketching (even counting Balsamiq) and wireframing.

Sketching is useful to establish what content exists where in the flow as well as the basic IA.

Wireframes add space and specific layout to the equation. Roughly how big each thing is and where exactly it's going to go on the page/in the flow.

I personally thinking sketching still has value and is worth showing to clients. Wireframing, however, is not worth the effort considering how fast and easy it is to do high fidelity design nowadays using Sketch or Figma. Just my $.02 though.

I've been almost exclusively working with lo-fi wireframes for the past two years. Lo-fidelity wireframes, in a program such as Balsamiq, are ideal for, say, legacy applications. It allows you to get started quickly and create layouts/flows in an abstract manner that developers understand. I only do hi-fidelity designs for new products without a lot of baggage and for marketing.

If you're a sole contributor (or on a small design team) that doesn't do much user testing wireframes are probably a waste of time.

You're supposed to be testing out your hypothesis and assumptions at the wireframe stage. Low investment or attachmen (though Sketch Libraries made even high fidelity pretty low investment too). I can't think of a reason why someone would try to convey colour hierarchy at the wireframe stage unless they were just choosing a design solely based on their ideas/personas and no user interaction—and fair enough. But. I like to co-design wireframes with customers directly (Lean UX) and the results seem to make v1 of a feature much more useful.

Thanks for sharing your thoughts guys. What makes my situation a bit different (I think) is that the most projects that we do are redesigns of existing webshops. Most of these are either pretty standard B2B platforms or retailers. I find that these shops tend to have pretty straightforward flows and similar pages; home > category list > product > checkout. This flow is pretty much the same for every project.

Another thing is that we don't do that much usertesting (I know, I know), because we don't really have a way to facilitate it and most clients don't want to pay for it. Last; it happens more than often that the client doesn't actually have a clue about who their target-audience is and what their wants/needs/goals are. Any tips on how to get this going are very welcome!

Freelance UI/UX Designer here currently working a 1 year contract at a Telco.

Freelance-wise : Personally, I used to think the same way a long time ago but have since then, disciplined myself to take on the approach of always including that into whatever client project I am working on. As long as your wireframes are "rough" enough to give them an idea of how things flow and the general idea of content, it shouldn't get them too attached to it. The idea of wireframes is to help with quick iteration and brainstorming without putting in too much time and effort into the visual side.

For my personal projects that I actually sketch on paper and whiteboard, I can always refer to it to do the design and iterate from there, unless I plan to display the behind the scenes progress shots of wireframing on my website portfolio. One example of project that I didn't actually do wireframing but hi-res concepting is for my project here:

www.huesnap.com

In this project, I mapped out user journey and flow with the developer and accounted for features but because the design was straightforward enough, I could just jump right into designing, while making iterations quickly.