Hacker News Reader

Yeah, many of these are bullshit or only valid in very specific circumstances.

On deadlines: sometimes there is none. Of course it still needs to be done, but it needs to be done correctly, so you set your own timeline based on sustainability. Things can be high priority and still not have an actual deadline. But sometimes it really needs to be done in a week or a month because it's tied to a big promotional campaign or it needs to be presented to important stakeholders or whatever, and you need to drop everything to whip something up that does the job and tech debt be damned. But if the actual deadline is "yesterday", then it's already too late and doesn't have to be done anymore; that's not a deadline, that's fake urgency.

(I realise the article is about design, not programming, so maybe tech debt is not a concern there, but I'd expect there are other quality aspects that matter.)

These are completely different situations and need to be treated completely differently. Only an idiot would assume there's only one answer to the deadline question.

With any work ask about external factors, not deadlines. No company operates in vacuum and there’s almost always an external factor. It may be well-defined and clearly dated (a scheduled event or launch in which your work plays part). There could be an external factor not explicitly connected to your work, even though it should be (you could help make that connection). No external factor whatsoever concerning your work is also informative: it could mean there’s not enough mutual trust, or your customer is investing into pure R&D, or it’s very low-priority, there’s a disagreement within the company, etc. It’s not the same as asking about deadlines, but the question should definitely be asked (and situation monitored for changes)—proposing a schedule/“deadlines” without awareness about external factors sounds like a bad idea.

Some customers may be inclined to manage more and set specific deadlines rather than get into the external factors discussion. This spares you from some higher-level planning but doesn’t fundamentally change the ultimate responsibility of managing expectations (aiming to under-promise) regarding work scope and timeframe: fixed scope means variable timeframe, fixed timeframe only means you adjust the scope part of the equation. If expectations are unrealistic and there’s no flexibility in either direction, run.

> maybe tech debt is not a concern there

Design can definitely generate technical debt. If the designer specifies that some widget has to look and behave just so, then some developer has to code a widget that meets that requirement.

IME a lot of design work is purely aesthetic, and a matter of taste. That is, it's not functional; you could have used a native browser widget instead, but designer says no. And in the last shop I worked in, the designer had the whip hand, partly because the boss couldn't code, and partly because designers cost more than grunt front-end developers.

So you end up with a pile of unnecessary front-end code that becomes a breeding ground for bugs and regressions. Not quite the definition of tech debt; but unnecessary code quickly turns into tech debt.

For me it also sounds passive aggressive in the sense "junior designer doesn't know anything, lacks things like common sense and even personality, this is why I pay them 5X less than myself". While me - a senior designer - explores beyond ideas ASAP while investing in researching clients industry to write own copies while choosing directions and overseeing execution while at the same time just doing the job required.

Some of these even contradict one another:

> The other knows the answer is "ASAP,” so they propose their own timeline.

> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.

Sounds for me like some senior punishing juniors with "do it ASAP! you only did one draft? do more! ASAP!"

Maybe I am imagining things or maybe I met colleagues/clients like that.

> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.

Yeah, not really. Given timeline and workload, I will probably polish a bit more and maybe let something sit for a few days before going back for another iteration if the schedule allows. But sometimes things really are done--or at least done enough for the purpose. I'm not going to just let the work expand to fill the time allotted if there's no real benefit to doing so.

> I always ask about deadlines. I believe not doing so is highly unprofessional.

To be fair though, the article didn't say no deadlines; it said propose your timeline, meaning (if I understand it correctly) let the client know your availability as well as how long it normally takes you to do tasks like this. The client then will either accept your terms or look for another designer.

Perhaps I'm reading the post the wrong way, but particularly in the case of junior v. senior, I see the deadline point to be more about what a designer can do, given their experience and seniority. A junior designer is going to be handed an assignment and told "we need this next Friday." A senior designer will likely be handed an assignment (or work with a client directly) and be asked "when can we expect some initial ideas?" It's less about what a designer of a certain experience should do, but rather what they can do.

I suspect this could apply to UI design (ok UX...) but I read it with product design / industrial design in mind. I worked on a project with a really good design team (2 or 3 people) and a bunch of engineers. We used a large conference room to go over the product objectives, and then we all paired up with designers to generate concept art. We all did this for like an hour or two. At the end they pinned up about 50 concept drawings at the front of the room and we talked about a lot of the ideas that had been generated. The thing turned out pretty spectacular. The lead designer moved on, last I knew he had gone to Rivian to work on their first truck under the direction of some famous design guy whose name escapes me just now.

I'm an software engineer, not a designer, but I also was left with a bitter taste.

Re >> The other does as many drafts and explorations as possible within the time allotted, then shares their favorite options.

It's good to ideate, but I've found that it's common for junior designers to ideate too much. For example, I had a designer come back with some designs that they felt really excited about, but they all were tied into a new company logo concept and I was like "No, we're not changing our logo. Your logo looks great, and if you/this logo had been included when we first picked something we might have gone with it, but we're asking you to design these XYZ pages, not re-do our startup branding".

If the brief is vague enough to omit things like "don't rebrand everything" that falls mostly on the person leading that project, in my book, although a more seasoned designer might have challenged the scope definition more.

Yes, "senior designers are jaded" should be added to the list — probably a differentiator between "senior" and "principal" to get over that sort of passive-aggression.

This article feels like LinkedIn bait

Agreed. It seems like 10x developer meme type stuff.