graphic designers sometimes ship their draft deliverables with 1 or 2 obvious bugs, and allow the customer to recommend these 'changes' on their own for final delivery. and if they don't, they're just fixed for final delivery anyway.

i read about it before i had this done to me for the first time, and i played along with it. it's a neat trick because it's plausibly deniable for everyone involved and the outcome is good while minimizing the bullshit work in favor of a sacrificial final word.

There is a concept of a sacrificial feature to prevent customers from becoming fixated on other aspects of the design that would actually create problems if changed. I prefer to avoid that sort of dark pattern though because it erodes trust.

"The Queen's duck"

https://bwiggs.com/notebook/queens-duck/

I’ve also done this, with both visual design and software.

It’s a deliberate canary - if the client didn’t comment on the obvious mistake/bug, I know they didn’t actually look at it.

Yes, but more importantly, it solves the problem of ritualistic feedback, which is very common. People think it’s their job to produce suggestions no matter if they have any or not. This gives people license to provide harmless feedback while adhering to the religious framework.

Code reviews is a great example of this, of course. You’re supposed to comment something, otherwise how will people know that you are smart and did your job? Famously, the most straightforward code changes always gets some comment to change something stylistic or menial.

I've done this in hardware design, presented a design for review with a problem that had already been discovered and had a fix in progress. It was a red herring that gave the customer something to latch onto and feel like they were contributing to the success of the project. Somewhat dishonest, yes, but very effective in getting customers to work with you rather than be adversarial.

This is a weird thing to tie to graphic designers. Just because you noticed a graphic designer doing that doesn't mean it's a thing that's more commonly practiced among graphic designers than any other trade.

It is.

The reason is most people can tell red from green and big from small, and most people use graphic designs daily, so will have an opinion on whether a design element should be bigger or redder.

Other professionals with a similar plight could be copywriters, and devs when selling a PR.

Compare to plumbers or lawyers.

I am a professional graphic designer. Presenting with obvious defects to fix before shipping is not common practice. In any serious design engagement, the client would probably just be confused about why something changed after approval and it would lead to an unnecessary meeting. On top of that, I'd probably end up having to revert to the shittier version they agreed on and waste time re-packaging the deliverable. Purposefully using up contractually allocated revisions with deliberate flaws, while very difficult to prove, is essentially fraud. If the graphic designers you patronize do that, get new ones.

We've all read the duck story, but it was probably bullshit, and nobody does that

I do that, and it (usually) works.

What do you do when it doesn't work? This seems like a really bad outcome - they approved the design with the glaring flaw, which makes it hard for you to remove it, and they potentially also requested some other 'improvement' which makes the design worse.

This was known as adding a 'duck'. It is unfortunately very helpful when your client stakeholder doesn't value your expertise as much as they should. It works for web design too, but you must be careful that your duck doesn't become a feature!

How can you distinguish between "project is not important/forgotten and due to that, no issues are discovered" and "there are no issues, so it is forgotten"?

I encountered this in a previous job. I told them during design phase the implementation was failing basic computer science knowledge and would cost the company a lot of excess computing costs (due to redundant work).

a quarter after launch it was a crisis because $5k a month customers were costing $50k a month in compute. The original designer put in some patches that got it down to $25k, and then $3k and was a "hero". By my estimates the limit of the actual work being done should have been < $500. But we didn't have time to implement that due to a quarterly insistence and folks all nodding their heads at eachother to get promoted.

> told them it was failing basic computer science knowledge

> i got a negative review for not being a "team player"

Effective communication is good for your career. People don't want to work with someone who slings distracting insults.

You can say "This will cost $50K, but we can't afford more than $5K, and I think we can do it $500", or "a 10x customer will cost 100x to serve, but a different design can bring that down to 10x".

SaaS without the sass.

you're not wrong in general, but wrong about my demeanor in this case.

Team player meant a lot of head nodding, and making each other look great in a previous company.

I know the scenario. I've been there. Sometimes people just want to move on. I've been in meetings where people got annoyed at me asking the "tough" questions and pressing them on their design for an hour. At the end you have to realize technical merit is not the final arbiter, it's mindshare, and that's usually driven by the "chosen" group or favorites.

The fact of the matter is unless your company is very mature, getting 3 big features to prod in a month even if that means bringing down some system for awhile is generally much more valuable than getting a single feature out with zero downtime.

As the company and number of devs grow, the probability of a dev doing something stupid increases substantially, so those early mistakes can actually be quite valuable in showing where your infrastructure has gaps.

Let the imperfect code happen, it often leads to free chaos-testing and more stable infrastructure.

Agreed. In the same vein I have seen this approach work well too: "make the issue a big deal, then be the hero that fixes it"

If you just fix it business as usual.. or prevent the issue then noone will care about you.

Unpopular opinion: I find with long projects that development speed later on depends a lot on whether we made good decisions early on. Stopping to figure out an architectural thing can make things easily changeable later. Keeps your speed up, even a couple of years into a project.

"Do it fast" feels really, really good. It's motivating, and you feel like you're pushing forward. But it can really slow you down in the long run. Eventually, everything's so coupled that it takes weeks or months to add new features or fix bugs because you can't touch anything without breaking five other things.

As a mentor-of-sorts once told me, you end up feeling like the street sweeper after the parade

Of course, this is only rational if you know what you're building ahead of time, and that you'll need the things you're preparing to build