zlacker

Has anyone else worked with teams where their entire idea of "product" was to create 100s of designs in Figma, and then just hand them to developers?

What started this mentality?

>>roflye+(OP)
Unimaginative leadership that didn't trust their teams. Prototyping the 'experience' (mostly happy path) in a design tool, gave them 'visibility' into what the product could become.

>>roflye+(OP)
Yup. This is far from new. Used to be getting a zip file full of low quality photoshop exports and you would have better luck pulling teeth out of a cranky tiger(1) than getting proper assets (or the raw files) out of the art team.

My favorite was the PowerPoint presentation. Didn’t happen to me but I’ve heard about it.

1: Somewhat redundant. Any tiger you try to get teeth out is likely to be cranky before you finish the retrieval.

>>roflye+(OP)
What's worse is treating engineers like "just implement the mockup eyeroll" but then the logic of the mockup makes no sense with real data or product.

I'd rather have a napkin sketch that we can work on together vs throwing pictures over the wall.

As impressive as it is, I feel like Figma makes this situation worse. It's like "see we've figured it all out devs, look how nice this looks. No discussion needed"

>>kayode+z7
I like the PPT - it is more like a wireframe!

Yes, similar to the photoshop days. I forgot all about those. Has been almost 10yr since I had that happen!

PPT doesn't bother me because it's very "what we need" not "how we need it" so I don't have to worry about the specifics and instead can focus on (and ask questions about) the intent of the feature.

>>obeid+f2
I don't think it's a trust thing, but yes - I think leadership not knowing what they want is a big part of it.

>>gedy+h9
I feel like that might be an organizational problem. At my company the designers will present their figma designs to engineering and we'll have a meeting to go through them and bring up concerns with exactly those sorts of issues e.g. "This list may actually have hundreds of entries in practice, are bullet points still right?". Then we iterate.

>>gedy+h9
I agree with these points. Someone mentioned the PPT method - and I like it for your reasons! It's like a wireframe.

>>birthd+sc
Wait, your product people talk to devs?

/s (at my previous company they did not ... lol!)

>>gedy+h9
they always use text that is ideally sized in mock-ups but completely falls over when real data is used in a responsive web app.

My favorite is when design adds data to a mock-up that we don't actually have. My company is, admittedly, a bit of a joke.

Also up there: design giving us mock-ups that are a composite of shit that needs done today and future shit they still haven't decided on. And then demand review approvals. No. You can't have it both ways you fucking morons. Either give me exactly what needs to be done, or you get no review rights. I'm not going to sit here for three weeks of back-and-forth while you play hunt-the-pixel and giving me hell for not matching the fog in your own head.

>>deckar+af
> responsive web app

That's my favorite - if you mention responsive or how things should wrap or cascade you get the blank stares or "we aren't solving for mobile right now"

>>gedy+h9
My favorite is when the designer doesn’t have a good idea of what’s feasible to implement on the target platform and just designs whatever, leading to a boatload wasted time.

Don’t get me wrong, I have a ton of respect for good designers, but the best designers are those with a slight technical lean who are willing to design around e.g. built in customization on UIKit widgets instead of full wheel reinvention everywhere.

>>roflye+(OP)
> Has anyone else

Yes, absolutely, and it's among the worst ways to develop software. Designers kept coming up with controls that required coding custom behavior not already provided by the toolkit, either by modifying and extending components or creating new ones from scratch. Designers blamed developers for causing "rework" when it was found that the design included things that didn't exist, and developers took the blame when it took longer to implement the mocks than designers had led project leadership to believe. The lead designer's solution was to more-or-less abandon the team's pretense of being agile and get everything completely frozen well in advance of any coding.

Also, the backend was horrific, as might be expected when leadership treated it as an afterthought. I got the impression that because the system was built to replace an existing front end, leadership believed that it was just matter of wiring the UI up to the services that already existed. Some very legacy services, think mainframe-era fronted by a thin SOAP-to-json layer. Yeah and some of the backend services that turned out to be required didn't even exist.

I'm glad I'm done with that consulting gig. It was not fun, it wasn't challenging, it was just a grind, and if it is complete and they are able to turn off the existing front end on schedule I'll be shocked, and I'd want to know what kind of dumpster fire they end up with.

>>birthd+sc
Took me years to finally push this culture. The designers no longer try to get away with designs that are too difficult (read: pricey) to achieve, and developers have to keep their skills sharp resulting in less blame and a more competent skillset. Then the designers and developers who thought it was part of the culture to never work together nicely were immediately noticed and shown the door.

>>kitsun+Hk
One of my favorites was when a designer decided to use a grid system completely independent of what was going to be used in development. No time left to redesign, so the designers had to live with whatever the devs could make happen in the time allotted.

>>roflye+bc
I think you misunderstood. It was a powerpoint with images in it, not a wireframe. It show how site navigation worked, which was a huge improvement... minus having to dig the images out one at a time. :D

At least they didn't use document links with absolute paths. Macs don't have have a C:\Documents and Settings\Clueless\ folder. Encountered that a few times in my career.

>>roflye+(OP)
Yes, I had a freelance client for a website like this somewhat recently. The best part was whenever we had to spend extra time to make something look right, I was told that "it should be fast and easy, just follow the figma exactly" - which of course, did not work, because css does not render in browsers the way the figma designer looks.

>>roflye+(OP)
Yes, and this made me hate Figma. Literally my only interactions with it have been getting dropped into some file with dozens of screens and maybe if I'm lucky they've zoomed it to the thing I'm implementing. I have no idea how its supposed to work but that was awful.

>>jmuguy+3G
Yes, I find frequently it's hard to know exactly what people are linking me to. Usually it's to some arbitrary view in a file. Our designers have had to make their own bespoke, inconsistent labeling systems (literally dropping text elements around the designs to describe them). There needs to be a better way.

>>roflye+(OP)
I'm curious what you'd prefer, a requirements document? Powerpoint slides? Photoshop files with a grid layer?

The best designer I ever worked with did full HTML/CSS mockups but even those had to be rewritten into the development framework of choice.

To me Figma is a step up from the other ways I used to get designs.

>>kayode+Pz
i would consider even powerpoint lucky compared to an excel file with a bunch of images or even the design being made out of cells, rows and columns... yes, you read that correctly lol.

for all that trouble it still beats getting `design.jpg`

>>gedy+yj
That's one of the few things done right at my previous consulting gig. They were mobile first, and didn't even start putting up a desktop web version until they had the core functions of mobile working they way they wanted.

>>roflye+vd
In my experience, it is a serious problem when product people do not understand how their product actually works, even when treated as a black box with observable external behaviors and interfaces.

>>CSMast+801
If you want a figma, I'd prefer if you worked with a dev before making it, then also worked with them after making it, to get on the same page.

Creating a design out of whole cloth and handing it over to a dev, with minimal interaction, seems lazy.

The problem isn't figma - it is how it is being used. I do think that figma is super super overkill, as if you pick a good design kit what's the point? Lots of wasted time.

I don't see the point of doing all the extra work, when in reality a wireframe works better in most cases (doesn't set you up for the "why doesn't it look like the figma" responses)

>>butler+8c1
They knew how the product worked (they used the product) they just did not interact with devs - so they didn't really get the implementation. Their only opinions there were formed from leadership who was very biased with what they wanted to express.