This is basically a surefire way of turning a great client into a terrible micromanager.
"I liked it better the way you had it Tuesday morning. Could you put it back that way?"
"I don't think I like the direction the contact form is going. Could you take a look at X site and make it more like that?"
"My cousin took a look and thinks you should be designing from the top-down."
"I thought you said this was a mobile-first design. Why are you working on desktop?"
Yeah. Nah. Design happens in a black box because clients don't understand the design process, and understanding the design process is more than just information.
I've dealt with a micromanager before. As my employer.
One that, during the building of his home, also had contractors walk away because of his micro-managing the build on-site :')
It's some level of control-freakishness (that's a word) to think you need that level of involvement in every aspect of your life...
I'm sorry, but this is a surefire way of building shitty products. While I agree allowing a client to micro-manage everything you do would not be productive, so is designing in a black box.
I don't think I'd ever say the words "design happens in a black box". That's just... wrong.
You seem to be arguing one extreme over another. There is a balance to this that results in good work and ultimately great products for your clients and their customers.
Literally every one of those hypothetical quotes you listed is something you can easily push-back on or give an answer that I think any reasonable person would understand.
"I thought you said this was a mobile-first design?"
"Well, we're starting with desktop and working our way down through the breakpoints. This is how we typically do things and it's worked well on our other engagements."
If they are still not convinced, show them a previous successful project where you did exactly this.
If they are still not convinced, you should fire the client and stop working with unreasonable people. Maybe I am extremely lucky and have only dealt with very few truly unreasonable people in my 13+ years doing this, but that doesn't seem to be the norm.
I'd argue further than you should educate your clients, especially if the project is substantial in scope. If I'm going to be working with someone for a month or more, I most definitely want them to understand and be fully bought into the design process. They hired me for this reason, not just because the pixels are pretty (usually). Even on small projects I talk about and go into the importance of various aspects of the design process and why we do certain things the way we do. We often use previous projects, which they have often hired us because they really liked, as examples of why sticking to this process (though exceptions can always be made for good reasons) is good.
The best clients feel like partners and this is often because they are bought into and appreciate your process, even if they don't fully understand it or have the experience to trust it.
It's your job as a designer to build this trust and understand that clients are paying you a lot of money to help them solve problems. This doesn't mean you have to do what they say, but it does mean you need to try and make them understand. It is client services after-all.
My last point, and I'm sorry this is a wall of text, is that design absolutely cannot happen in a black box. Sure, you might end up with something pretty and the client might think it's great. But does it actually solve the problems they need it to? How do you know? What assumptions did you base it on? Did you validate any of them? Did you dig into the problem? Did you iterate, get feedback, and iterate some more? Did you speak to any of their customers?
Often clients are building something that they actually do know a lot about. They can be their own customer in that regard and will be a great source of knowledge. Even if this isn't the case, they will usually have spoken to many of their customers, which you should do as well. Ignoring this and going off to do your thing with zero input is only going to create more work for you later and cost the client more money.
This isn't even addressing the fact that you might simply have designed the wrong thing, their expectations were for something totally different, and you just wasted weeks of work and now you have a frustrated client on your hands.
So yeah, no. I really dislike hearing this attitude, especially when younger designers might be reading it and thinking it's a normal way to approach design and client work. I can't count how many I've had to essentially un-brainwash to get out of this mindset.
Design can certainly happen in a black box, but it's not going to be good.
I think if you say you're designing "mobile first" then you should do that—not tell the client you are and then not do it.
"mobile first" does not necessarily mean it is the first complete design that takes shape. As far as I know, it is SUPPOSED to mean that mobile takes the first priority in design and content decisions.
Mobile first is just another way of saying responsive web design. It may have actually meant mobile takes priority before app design took over, but responsive is the name of the game now in web. Clients may say one thing and mean another.
As long as we're throwing numbers around, over my 18 years of doing this, it has been my experience that small-to-mid-size clients are used to doing everything themselves in an environment where they can do that. Design is not an environment where they can or should be doing that, but most people do not understand that.
I get that you want to educate clients as much as you can, but you can't go around firing everybody who thinks the only difference between you and them is that you know how to use programs and code (which is, honestly, what most of them think. narcissism and ego are essential to being successful in business) and they don't. Unless you want to be a designer with no work.
The best way to deal with those people is to keep them in the dark as long as possible, and introduce them to the design at specific, predetermined points and on as limited a basis as possible; then, to do a couple rounds of changes.
If you've been doing this 13+ years, then I am 100% certain you've designed with a client standing over your shoulder arguing about how many pixels they want you to "move the logo down". Giving clients constant, remote access to everything you're working on is like that on steroids.
The best way to deal with those people is to keep them in the dark as long as possible.
I'm sorry, but this is nonsense. I would like "those people" whom you are suggesting to "keep in the dark" to hear that out. I doubt that this approach by itself is a sustainable way to do business.
“Those people” know perfectly well that they are micromanagers and don’t fight this approach one bit. I deliver, and what I deliver works. Those who insisted on leaning over my shoulder and tapping my screen with a ballpoint pen got fired and those who trust me to do what I do are enjoying the benefits of being forced to keep quiet.
Every second you waste justifying design decisions and managing expectations as part of this "transparent design process" is what I like to call "a colossal waste of time" that could have been easily avoided and better spent on actual design work.
It's better to be iterative and keep the lines of communication open rather than showing them how the "sausage is made" so to speak. It's just unnecessary stress and wasted time being willingly brought upon yourself for no reason.
I specifically stated that I was not arguing for allowing the client to give feedback on every little detail. I am arguing for a balance between that and "designing in a black box" as the OP stated. Being iterative and keeping the lines of communication open is what I'm suggesting and is absolutely not designing in a black box.
Black box = getting requirements from client and delivering everything by the deadline, with little to no communication in between.
Yes, my process may be a bit more transparent than some, but it's certainly not as extreme as you're suggesting. Also... it works extremely well for our studio. We've been doing this for a while and have very happy clients, who pay us well. That doesn't mean your version doesn't work as well.
Designing in a black box however? Sorry, but I can't imagine that's working very well for anyone unless their clients are just really easily impressed and don't care about solving real problems.
This is basically a surefire way of turning a great client into a terrible micromanager.
One of the responsibilities of a consulting designer is to educate his clients on the design process. If you do a great job on that — the chances that client is going to micromanage you are low. In the case when your client is well-educated in the design field, but still micromanages you — it is a trust issue. You might try to solve that in various ways, and full transparency might become your good ally.
I’d be curious to see how many duplicated projects there are in Figma. I can envision designers creating show pieces from their “real” files just to protect themselves a bit from clients.
Of course, that’s many designers’ worst nightmare — that a client, or manager, could check on a project in various states of disarray.
This part of Figma scared me a lot initially. Designers are used to getting their requirements and then going into a hole somewhere to dig around and finding the perfect solution. While I think there's space for quite reflection and production I don't think the entire process needs to be punctuated with it. Simply allowing stakeholders and collaborators to have access to in progress documents brings a sense that everyone is working on a project together instead of being puzzle pieces scattered around.
It's been subtly transformative in the way I work, and it doesn't hurt that the Figma teams is relentless and thoughtful in their development of new features.
I prevent team members or clients from peeking into my designs by keeping preliminary sketches in a separate file outside of the main Project space. And then only promote them to the Project (or Team Library) when ready for review.
Darren, this is how I work too. (Might also share when stuck on something / looking for early feedback / want to check in with team)