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.
Hi giulio. Thanks for taking the time to comment.
I agree with what you said. If as a client you run a design sprint with your designer, without skipping any part - that's great. I'm talking about cases where the 'sprint' is held only in a client/PM's head, takes a few minutes basically, and the designer is being shared with the results of it.
Yes, it's an unprofessional design process, but from my experience this happens way more than it should, which is why I felt the urge to express this problem and hopefully make some PMs think 'maybe I should improve the way I deliver tasks', and designers think 'maybe I should be more involved in the thinking part'.
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 agree. Using their scenario of the napkin. The architect gets the sense of the size and priority of each room, which starts the conversation from point B rather then A.
My take of the article is about communication. If you tossed the client's idea on a designer desk and say give me 3 ideas at the end of the day with no context... thats were you get the pretty but pointless solutions. Sadly, you are right I have many clients that just want to make it "nice" and quick.
My process, right or wrong, is to take whatever is given (sometimes loose guidelines, sometimes wires) and make one version very quickly that hits the high level and then take that to the PM. This is in the context of being a designer internal to a large product company. The other designers on my team don't do as well here because of the difference between my approach and theirs. They want to take a long time to put together a few highly polishes ideas to pitch — but they're really just wasting time. In my experience, it's best to get my idea of what the PM wants out to them as quickly as possible so we can look at it and I can tell them "Here's the problem with what you want to do. What I think would be better is if we did this."
Like you said, a lot of times they don't fully know what they want or even totally understand what they're asking for — once you get something as concrete as a high fidelity mock or prototype in front of them it's far easier to clarify their thoughts in greater detail or disabuse them of ideas that aren't going to work so that you can explore better solutions.
That said, we're dealing (and not just me) with a big problem of endless iteration cycles and pivoting on goals and directions late into the lifecycle of these projects and we desperately need to find a solution to it because at this point we're designing in circles for far too long, then shipping a terrible "compromise" — discover in tests that it isn't working and typically circle back to something closer to my initial intuitions or proposals. Not to be arrogant, I don't think I've always got the answers, it just is very frustrating to be consistently treated as lower the decision hierarchy while the people who have supremacy in it are proven wrong time and time again. PMs are not designers, and you can't just "discover" good UX somewhere between a PM and a product designer who is treated as a visual designer — particularly when the relationship is hierarchical.
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.