[shermantanktop]

This is the type of twaddle that I have come to expect from “designer” types. Constant boosterism and exhortations to respect their craft. And when left to practice said craft, the majority of the actual work product is visionary PPTs for execs and a pile of figma screens that barely cover the happiest of happy cases.

Sad thing is that I very much agree with the importance of design. But practitioners seem often insecure, inward looking and unconcerned about whether their dreams are actually workable. But they will talk your ear off about the “texture” of a font.

[foldr]

My pet peeve with the Figma drivers is that they tend to think of design as a 'phase' that happens before engineering. So as an engineer you are asked to implement a bunch of painstakingly laid out user interfaces that have never actually been used to do any work. IMO it's essentially impossible to design a good interface without feedback obtained from using it. Designers would be way more useful if they'd partner with engineers throughout the development process. But there seems to be huge cultural resistance to this mode of working. In fairness, a lot of business processes make more sense if you assume that having to talk to an engineer is one of the worst possible outcomes.

[collingreen]

Nice, sequential flow charts are easy to understand and pitch and they also make it nice for the folks at the front to say they did their part and any issues are now someone else's fault.

When people try to diagram the actual process (closer to what you're talking about) it's just a giant circle (or "double diamond" for folks charging money for powerpoints) which isn't a tool that makes management feel easier or "on track".

[shermantanktop]

Worrying about how managers are feeling, what vibe they are into now, how they might misinterpret something they heard-it’s exhausting.

[tikhonj]

A problem I've seen in programming too: understanding and articulating the value of quality is necessary but nowhere near sufficient for actually doing good work! So you end up with folks who've gotten past the initial hurdle—developing taste and confidence—but, either individually or in an organizational context, are only able to do okay quality work. Not awful but not especially elegant or insightful either.

And so we get people making totally reasonable arguments about the value of design and then producing polished but tasteless and shallow corporate products. Or we get people who start understanding the value of maintainable, understandable code, but get stuck on design patterns, "clean code" rules and "best practices" rather than conceptually clear, coherent and effective code design.

I have some sympathy. Getting past that initial hurdle rests on skills and tacit knowledge that take time, practice and mentorship to build after you've developed an appreciation for good taste. And, especially in a corporate setting, you have to get most of that practice and mentorship in public.