Have you ever heard a client, product owner, or stakeholder praise wireframes?

Yes.

Do you, as a designer, love spending hours creating or updating your own wireframes?

Yes.

There are a lot of assumptions baked into this argument, a lot of which probably shouldn't be generalized to this extent.

The article assumes that working on wireframes means the process is a one way communication "waterfall" model, and that they provide too much information too early.

If organizations are, in 2014, still using wireframes in this manner, with pages after pages of annotations and documentation explaining how transitions happen, yes, its a problem. However speaking to colleagues in various startups, tech companies and design agencies, this really doesn't seem to be the case, and regardless is not a reason to shun the practice of wireframing altogether.

The author doesn't speak about the reasons people started to use wireframes in the 1st place (which was to quickly get broad conceptual ideas into visual form so that its easier to talk about them and share with others).

The "4 primary tenants" of rapid prototyping listed out in the article are not limited to just rapid prototyping. They apply equally to all parts of the design process (including wireframes).

Personal subjective opinion: the way I wireframe, the argument is analogous to saying I should give up sketching first when it comes to visual design.

A designer is a problem solver and should be able to take on the "information architecture" and the aesthetic appeal. Siloing the steps that go into a fully thought out design is, in my opinion, a tragedy.

Removing wireframes is the equivalent of deciding to build structures without blueprints. Wireframes allow for a designer to see their thoughts on paper quickly and to work through any issues that arise after seeing the layout, allowing the designer to make intentional decisions based on structure and future aesthetic considerations.

That may be a harsh reality for some, but the truth is that truly great designers can take a product's form and function requirements from beginning to end.

I don't know if I'm entirely on board with this argument, but I do question the weight put on wireframes. Admittedly, the sites I tend to work on aren't incredibly complex, but we've be very successful at sketching 'wireframes' on big pieces of brown butcher paper. We've found that working at a coarser level than digitally-produced wireframes can give us a lot more flexibility in development and design. It's also lead to us being a lot faster.

I have to disagree with this as well. At my company, we never pass on wireframes to the developers, the wireframes are only a template for designers, to make sure we have the correct content in the right places. This is crucial because we're often designing for really complex content & data, and we can focus on content design during one phase without being distracted by visual design.

If we attempted to rapidly prototype something as complex as a trading history page, or portfolio goals page, we would get stuck in hours-long meetings where the client provides feedback about visuals when we really need feedback on the content.

This article is only looking at one specific segment of web/UX design, which is why I find it lacking.

I don't agree with him. UX has a holistic view on design and the wireframes are a good way to start to understand what works and what doesn't. A good wireframe could be a useful tool for having a chat with stakeholders / creatives / It / designers.

I really enjoy this phase of the design process and it helps me to explain what I'm doing and why I'm doing in that way.