Hacker News new | ask | show | jobs
by cm11 18 days ago
This I believe is lowkey one of the core ways design broke at tech companies. There are other big ones, design (really product) is broke deeply, but once mockups became easy we stopped having discussions about information architecture and UX. We're talking about whether we think this looks nicer in blue or green. Happened before Figma, but Figma really grew it. The designers that tried to hold onto wireframes (or went to mockups, but tried to still have architecture discussions with them) fought an uphill battle—what were these guys even talking about? Even the other designers thought this.

Once mockups became easy, that little bit of vocational gate (as in gate-keeping) that was holding the wall for UX work went away. Execs and PMs could make decent looking rectangles, so designers became the people who could make especially nice looking rectangles. So you got a lot of product/UX designers that were much more visual designers. That matters, but the prior part was bigger in that the product processes and sprints often started to have little design in them at all. What was a two or three phase process was one, designer got requirements and made design—often they didn't even really get requirements before design. The design was the impetus for the requirements not the other way around.

This is what became standard: Leader would give something vague because they didn't have much idea or vision yet. They probably had something blue-sky-ish, meaning they had a bunch of ideas, which in amorphous abstract blue skies come together. Once those things appear side by side on paper/screen, they're off putting and contradicting. There are problems not just with how to fit the pieces, but with the pieces. The visual the designer provides triggers this. Designers being visual people can see a lot of that in their head beforehand, but won't be heard until they show "bad work." It's pretty common though to see the PM or the leader look at it and say it wasn't the vague requirements, it's that the designer didn't get it. Anyways, it's that design that then kicks off some assessment against reality. Then you have a little bit of a shot at real requirements starting to leak out.

4 comments

I've noticed and felt this trend, but I haven't ever seen it put so well or really connected the dots with figma & pretty rectangles.

I remember discussions over relative easy of use of gray box wireframes... and that led to better products.

Now I've got designers vibing monstrosities that would have fit right in in the Flash era, I guess in order to draw even nicer rectangles now that execs than wave at AI and get a design.

It’s a bit like having a 1:1 scale architectural model made of cardboard. You walk people through it and everything looks good on the surface so they start asking “when can we move in?” skipping all of the hidden engineering that still needs to be done and in some cases pressuring you to just waterproof the exterior so they can live in the model instead of building the real thing.
I'll offer a different perspective on this: for years we (product/c-suite people) constantly got push back that giving a goal was no longer enough, we had to articulate the path to the goal in excruciating detail.

If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back.

There's still a way out of this mess though. All it takes is for folks to take shared ownership for hitting the goal and bring their expertise to the table to help draw the path to the goal.

I'd ground what I say in sharing your assessment of the observations or insight, but with a different takeaway.

  If I need to think about the solution that hard, I may just as well take it all the way, remove the middleman and get some efficiency back.
Totally. And the takeaway is that we by and large should be doing this much more. That's what's needed from leaders. More vision, less delegation of vision. The stronger the vision, the less need for delegation anyway. There's something to be said about the difference between big picture and small picture, but at this point it's relatively intuitive that the big picture divorced from the small makes for worse big pictures. I'm not talking about how handing the big picture to the middle person tends to create interpretation/translation errors as well as execution errors to the extent the subordinate is less capable. Those factors are prominent and _in addition_ to the issue that the big picture is a worse big picture when these duties get stretched across two (or more) people. And thus, we should own these duties "vertically" and if needed reduce duties "horizontally".

Leaders (and companies) should be doing less horizontally. It runs the normal risk of stretching to thin, but their tenth and eleventh ideas are also filtered towards worse. Perhaps more fundamentally, the bar for adding a product/project should be higher. When the leader can "just" add another leader to take on the work—particularly one by nature with less power, ability, autonomy, and perhaps accountability—it's getting set up for a lower chance of success. In order: (1) the project probably shouldn't start at all; (2) if "started" at all, it shouldn't really look like starting, it should be a person validating for the leader who will then start it (many product teams pretend this is what they're doing); (3) if started, it makes quite a bit more sense for the higher (and likely more capable, but especially more empowered) leader to take on that project and hand the existing, stable, better trodded project where the team has institutional knowledge and support to the other leader.

In practice, sharing ownership is superficial, whether between leaders at different levels or between project team members. Why share? Own it or have someone else own it. Or if there isn't trust in the other person, cut it. If the leader doesn't have the time/interest and doesn't think they have someone capable of doing it, it should be as much a sign as a low quality idea.

It's not hard to find problems with middle managers—many are with the sorting that picks them, many are with the conditions of the middle. Structures and strategies to remove them, as you suggest, are a great idea. The main way is for the leaders, when faced with the scenario of "if I need to think hard", to not come away with "let's do it, but not me." We should be default no. Green lighting some work to validate it to a Yes works, but these are tasks such that the leader knows what kind of validation is needed—and is assigned to a person with those skills. An engineer, marketer, business analyst, user researcher, data scientist is going to validate things that a PM or a director have less or no training in. Leaders tend to appoint the latter though, sometimes for empire-building reasons, but I think more basically out of fear of control and legibility. Those are counter productive reasons if understandable.

which is why I advocate for fat marker mockups [0].

very low fidelity - but describe ux flows.

[0]: https://basecamp.com/shapeup/1.3-chapter-04