I don't agree at all.

You are not smarter than your customers, and you don't know the problem as much as they do. When a client sketches he can show you critical problems that you didn't see in the first place. That's what workshops, design sprint, and similar techniques are for.

I see what you're getting at, but I don't 100% agree. More often than not (in my experience, at least), clients have a lot of difficulty articulating their needs and problems. Getting a wireframe at the outset usually cuts out a lot of unproductive back-and-forth and gets everyone to the solution more quickly.

That said, this only works if everyone is operating under the understanding that the wireframes are only suggestions and that you, the designer, will be interpreting them and modifying them appropriately based on the business needs. To your point, though, a lot of clients don't operate that way and just want you take what they've made and make it "nice".

I get exactly where you're coming from. Wireframes can be great if the client understands that the final product might/will be completely different. But unfortunately it doesn't always happen that way.

My worst client experience happened a couple years ago and it was exactly this. Some guy wanted us to build an app replicating his incredibly broken wireframes. We spent hours trying to understand what each element was supposed to do.

We decided to be pro-active and modified his wireframes and brought them into InVision to give him an interactive prototype. The meeting started so badly... the guy was acting like he was Zuckerberg giving us orders. Incredibly disrespectful and kept treating the PM that was with me (a woman) like she was worthless. Just a huge asshole. He wouldn't tell us anything about his business, literally nothing. We were just there to execute orders and make his broken wireframes reality.

When I handed him the phone, oh my god... It's the only time a client cursed at me. He was so mad. It took me everything not to scream at him to get the fuck out. We ended the meeting shortly after and the week later I learned that our VP canceled the project. I was so happy.

So yeah, end of the story. Wireframes provided by clients can sometimes be awesome at communicating problems and some possible ways to fix them. But there's always this one...

Collaborative sketching works best. All sides benefit as the client can articulate what they want and the supplier gets a better insight into the problem and what they want to achieve.

Completed wireframes are a good starting point but it would be foolish to follow them blindly. Bigger picture stuff might be missed and being enveloped in a business may result in the obvious being missed.

Explaining what water is to a fish… the fishes response would be "what water?"

I think I'm going to buck the trend and agree with Ariel.

RE: Design Sprints handle this! comments... well actually they don't. Not in this particular way. Wireframing/sketching is a specific step on day 2. So the client has cut out entire days/hours of process by jumping straight to wireframing. I'm certain this just requires some education (it's not malicious). But the timeline in a design sprint is deliberately paced so the people doodling out ideas don't have a lot of time to bond with them. Coming to the table with wireframes means the customer has had plenty of time to bond with their idea. They might be right, but that's beside the point at this junction of the process.

You're on a journey together so you've got to start at the beginning together.

There's a few different reasons as to why a client would give you a wireframe or mockup but in my work there were 2 major scenarios:

1.) She has a vision in her head that she can't seem to articulate so she would create a mockup to give you a visual idea - as a designer, you can experiment with the wireframe, make it better or provide an alternative solution because the wireframe simply doesn't satisfy the purpose of it's creation. Either way, providing a wireframe is a supplement for her to help communicate an idea. It doesn't necessarily mean she thinks she can do your job better.

2.) The purpose of designing is just to "enhance" and work with whatever is provided. Oftentimes these types of work has a set deadline already and the "design" part of the work is typically "just" to make sure that it's presentable. It's like going to an audition with a sh*tty script to work with. You do your best in delivering the lines, maybe modify it a little bit to exert the right presentation. Compromising doesn't have to be horrible. Work with the problem and use the wireframes as reference.

Maybe it's just me, but as long as the person provides me with what the problem/purpose of the design creation, I just look at the wireframe as a reference, not the ultimate "be all and end all". At the end of the day, they're asking me for my expertise and counsel and it is our job as a designer to evaluate the impact of the work and eliminate the negative impact if there's any.

I don't agree in the slightest.

I also think you haven't drawn up a house before... " it's like coming to an architect, handing her plans for a house you drew on a napkin and asking her to redo it with colors and make sure the construction engineers will understand it as well."

That's kind of how it happens...

Aaanyway. That Aside. I build large-scale HMI interfaces, as well as fintech applications. These are projects with massive amounts of business logic behind them, from specialty industries such as the petrochemical industry, lending industries, insurance industry, etc. If you didn't receive wireframes to help guide you through the logic, you wouldn't get very far using your own opinions on how things should look.

I mean, If I came to you saying 'I have a problem with displaying auditing data for the last quarters settlements and remittances per merchant, and require an interface designed where I can break down lending packages and view both inclusions for each and the most recent settlement'.... and gave no flowcharts, wireframes or such, you're going to go "aaahhhh what" and I'm going to go "well, you're dumb as fuck, in your own words".

You can't assume you're going to have the best ideas without seeing where the client is coming from. It gives you much more context on a problem if you can see the other party's problem solving before you try to tackle it too.

Sorry if that came across sounding mean (It's just about 5 here, and I haven't had a break all day haha!).. But there's a "holier than thou" attitude I see in a lot of medium posts, and I don't think it's a good way to promote yourself.