So much can be clarified and so many problems avoided if we “just look at it”
I saw this in relation to devs changing code. Its true, we make a change in code, feel it is trivial or safe, don’t actually go look at the result, the rendered thing on the screen. It’s a problem.
Its a epistemological / “what is the truth” problem.
Software engineers have a propensity to consider their code as the definition truth, this is what leads to us to not bother with looking at it, we take a mental short cut, we consider the source code as truth. At some level we know that isn’t the full story, there are compilers and run-times, and so on, just so so many layers in a modern stack. In spite of that janky jenga tower of complexity we sometimes still assume we know how those are going to work, because in practice they are actually fairly predictable, but of course we can forget something, we can reason about it wrong, or make any number of small mistakes. So we know we should have automated tests, and a lot of times, even with all that we should “just look at it”.
But I want to write about this problem from another angle.
The Figma problem in a nutshell
Some designers and product managers, yes ones that I have worked with, though apparently this is a fairly widespread phenomenon, spend a lot of their day in Figma, which isn’t a problem per se except when it keeps them from actually looking at and using the product to check assumptions - ie when they keep implicitly treating what is in Figma AS the product.
Whoa, shots fired?! are we just diving head first into critical asshole territory? Well, I hope not, but you’ll have to stick with me, maybe I can mansplain my way out of this hole I have backed myself into.
I am not saying designers or product folk are entirely wrong or bad at their jobs because they use Figma - for instance, it is absolutely true that at some stages of a product lifecycle what is in Figma represents a better “source of truth” as to the what the product will be, and even later in the lifecycle you can’t very easily take notes directly on the ‘real’ product that lives in a plain web page or in an app on a device or whatever. Some sort of tool to outline what is, and what ought to be next, and so on, is needed! So, no doubt, there are lots of valid and good reasons something like Figma exists, but in my opinion it gets overused, and this is a real problem, and I have developed a strong distaste for Figma, in part because Figma as a company encourages and creates this problem!
The overdependence on Figma, I believe, is similar to the error that engineers do with source code when they treat it as the most real source of truth of the product. But different in a potentially insidious way. Engineering teams are not compilers. We are not thoughtless code monkeys who deterministically transform Figma designs into applications. Of course we aren’t! Designers and product people are often (at least stereotypically) more empathetic than engineers - caring about how fonts and colors make people feel and all that, so they would likely object to the characterization that they treat their engineering team like thoughtless drones, and yet, in practice, this is, to a degree, how Figma guides them to think.
Maybe that seems overdramatic. I’ve written some about how Figma aims to be an IDE, and even how that is a very worthwhile goal in certain contexts, like brochure style websites or short lived proof-of-concept low-stakes web-apps even. Still, my point is that cutting out the finicky and fraught human-engineers-need-to-actually-build-it step, or at least minimizing that step with AI assists or ‘dev mode’ or whatever, is definitely a direction Figma is overtly taking.
This video is about AI, and programming and compilers, but was part of the impetus for this essay. . My position isn’t just me being upset that Figma or AI or whatever is trying to take my job. I am not worried about that, not anytime soon at least, as I just don’t think AI is going to get there, but I worry plenty of people will believe it can, and I worry how them trying to make it try to do it is going to affect me and the teams I work on, but my concern of drowning in slop are a different discussion, I am talking about how it is playing out now.
Figma is a product, not just a tool. It is built by a company aiming to make as much money as it can, it wants to grow, to expand past its otherwise prescribed boundaries. This corrupts or pollutes - early stage enshitification possibly. So before I hear “it’s just a tool” as a retort, yes, obviously, but it doesn’t see itself as such, and ignoring that fact is a good way to fail to use it merely as such! this is precisely what I am ranting about I suppose. In a lot of teams it has already grown beyond one tool in the chain to “the tool” in the minds of at least some on the team. It no longer has a clearly circumscribed use case, and thus also fails to have any clear implication on when NOT to use it. When do we put it down or put it away? Is there such a thing as using it wrong?
This Figma advocate put his finger on the problem in a sense, but IMO fails to see that Figma itself is the thing that creates and perpetuates the whole situation where confusion is nearly inevitable! Of course, Obligatory reference to that Upton Sinclair quote here
Sometimes the design sketches and mockups and design documents need to be deleted, or else their existence becomes an anchor and a liability. And for certain kinds of software product development maybe hi-fidelity designs are inherently a bad idea - given they have the tendency to trick our visually oriented brains that they are more real than they are - like how AI so easily tricks people into thinking it is self aware by just parroting first person speech.
Aside: Descartes said “I think therefor I am” and LLMs say “I think” therefor we think they are.
IMO design system work can start in something like Figma, but it needs to move to some place like Storybook in pretty short order. Once the real components exist and need iteration the designs that help bring those components into existence need to disappear. That is unless we can really get to something like that two way IDE/Compiler idea talked about in the end of that AI video essay linked above - I don’t see it happening though, even if they try I suspect it will have a timeline like FSD or nuclear fusion - that is, perpetually “close”, but never really getting there.
quick disclaimer: I recognize I am expressing a hostile opinion. I certainly wouldn’t take to kindly to designers telling me what code editor or plugins I need to use, But designers are asking engineers to use figma a lot, more importantly the figma workflow fundamentally affects how a team functions, which obviously affects the end product, and so I assert the validity of deliberating on this topic in spite of that fact that in some sense I am way out of my lane.
Loose Conclusion
So here is my loose conclusion: SaaS Product development in something like Figma should take a form more like storyboarding. I have been searching for analogies, and this is the best I have come up with so far.
Imagine a workflow at a place like Disney/Pixar; They have story boards and those are great, but what if the writers had their own fully rendered 3D models that they used instead of sketches in the storyboards, but those models were not at all usable by the actual animators. Can you imagine for a moment all the headaches this would create?! Now, an obvious way to avoid all that to me, ( admittedly someone with very limited knowledge of animated movie production) is to only permit sketches in storyboards, as in there has to be a hard rule where they can’t be allowed to be a high fidelity facsimile of the real character models, because allowing that will cause guaranteed headaches.
UI frameworks like MUI or Skeleton or whatever should NOT provide Figma design files, or at the very least any team that wants to avoid Figma purgatory should avoid using them because of the minefield they help lay down.
Wait, so architects should use crayons to communicate with builders instead of blueprints or CAD? Of course not! Because real world construction has a tangible product, and because we’re far far away from something like StarTrek holodeck technology, there is no real risk of high fidelity rendering of CAD drawings creating the epistemological situation that Figma can - A building in meat space is as far away from the best 3D VR rendering of the building as a crayon drawing of a web app is from the actual web-app. But Figma, being a web app itself, has the unfortunate power to diminish the psychological distance between the design and the product too much. I suspect a convention of using only Lo-Fi hand-sketched looking design kits in Figma would avoid a lot of this potential confusion I am griping about.
For sure no analogy is perfect, but the reason I am reaching for these is because it is a tricky problem and I am trying to leverage these things to think about what practical solutions they might suggest. Like how in the movie Inception they use a totem to mark for themselves if they are in a dream or not, — would a stamp on hi-fi designs in figma that flag them as TBD, design prototypes, out of date screen shots, etc., serve the purpose of avoiding certain kinds of confusion? Yeah, maybe, but I tend to think the lo-fi kits would have better ergonomics on the whole.
Sidenote:
When all you have is a hammer… Figma’s dominance actively discourages designers from learning about the platform they are designing for. Designers for Sass products probably do not need to be CSS experts, but if they are barely even aware of the primary content layout tools of the modern web, ie. CSS grid and CSS flexbox, that is a big red flag in my mind! Figma should not be the only tool in a designers belt or else every problem will have a Figma shaped solution, and Figma just isn’t a great tool for developing a lot of interactive functionality, responsive layouts being a great example.
Sidenote 2:
One consequence of design and product living in Figma so much and failing to use the actual product is that in work tasks the engineers are then left with the burden of explaining to product and design often in text format ( be it in Jira or in Figma/FigJam or Coda notes or Google docs or a Slack message, sorry, that proliferation of com channels is a different rant) how it actually is currently implemented and behaves, especially how it behaves, because that is something that doesn’t just get out of date, or out of sync, with the implementation, but it was usually never reflected at all in the Figma designs because Figma isn’t built well for that sort of thing.
This is wasteful! Same as it is wasteful for engineering teams to rely on manual QA processes carried out by others to catch a bug, write a ticket with reproduction steps and the whole works, all because the engineer simply could not be bothered to “just look at it” which often would avoid introducing the bug in the first place - A thing I have been guilty of many times BTW, I am sorry to say.
A second consequence is that engineers gets work tasks that amount to “make it match the Figma design” and it becomes a strange game of “spot the difference” where engineers are highly likely to mis-estimate the work, and who even is sure if the design in Figma changes between when the estimate is done, when the work starts, and where the product acceptance takes place or was out of date in the first place?! These tasks have a huge tendency to drag on and on and on and on … and on.
Sidenote 3:
Some companies should have a design led culture, fashion companies, or vacation experience companies, or whatever. Other orgs/companies are justified in being engineering led cultures, CERN, Boeing, NASA, etc. It is my half baked observation that companies go sour when they become led by an ethos that doesn’t align with their products top priorities. Boeing or GE should not be led by finance / MBA types IMO, because optimizing delivery and profitability undermine the aspects that should take priority within their product - safety, performance, quality, repairability, etc. Maybe universities should in large part be run by academics, and not a professional administrator class, that is if they want to be about education and research instead of about sports and being expensive luxury resorts to lure in students as customers.
If your product is for data scientists or accountants maybe the surface aesthetic that so much Figma usage today elevates isn’t great. In some products it is more important than others that form must follow function.
Assuming I am correct about how some companies should not be design led, it doesn’t mean design or UX doesn’t still matter a LOT! Just that the cart shouldn’t be in front of the horse, or the tail shouldn’t wag the dog, or whatever. But that said, here is where I am going to go ahead and get even more salty than I have been; in some companies, form ends up being the only function that matters because the goal isn’t to produce a quality product. It is to get fools and their money to part ways! Whats more, your company doesn’t have to be a scam for it to be influenced by the broader culture where this is rather common. It’s my perception that many legitimate companies uncritically mimic the trend of form over function approach. It might be because those companies have the appearance of success - if not actual financial success (short term as it may be). It might be because, like it or not, everything is to some degree influenced by culture, and, sad as it may be, scam companies in our marketing heavy economies have an outsized role in defining culture.
Now admittedly some of this spice spitting stems from me not feeling great about whatever stage of society we are currently all having to live through, whether it gets labeled late-stage-capitalism, techno-feudalism, or the Rot Economy) a lot of web software products that should be about function more than form actually flip those priorities because the problems they are ostensibly trying to solve, are not the actual problem the product is meant to solve. The actual problem the product is meant to solve is to be marketable - to attract enough interest from clients that investors will also jump in. It usually does also need to work, of course, but only just well enough for the the veneer to make it seem that it will outperform whatever shit (or just shit looking) solution existed before, which often enough is just complicated spreadsheet files shared around or somesuch - and because the veneer is doing the work of selling, not the actual functionality, well of course it better fucking look polished and “modern”.
Before this take gets dismissed as a bit over-the-top, I would like to submit this as a minor example this actual issue from actual designers I have worked with, but is also reflective of a common sentiment I and other web developers have encountered, and you tell me how to make sense of it :
Remove browser dropdowns - implement design kit custom drowdowns and styling
…It is extremely important to fix this issue for us to portray a legitimate and trustworthy platform that is modern, mindfully designed, and can be relied upon.
Solution: Anywhere there are dropdowns in the platform, we should be displaying the design from the design system. In no situation should we be using the default browser one.
[emphasis added by me]
So maybe am I not the only one being hyperbolic? In my perception, this is brand aesthetics gone rouge and trumping other considerations.
BTW I am not picking on the designer who wrote this. It literally could have been any designer I have ever worked with, so it is more about the field than the person.
Does it matter if the product slogs along and does half of what the sales team claims it does so far? Not so much, but god forbid it use standard browser select elements like some plain-ass accessible website, it has to use whatever cursed div-soup component customized to high hell autocomplete nightmare is fashionable of late. Often, it seems the point isn’t to quickly and efficiently and accessibly let a user select an option in a form, like everyone and their grandma already know how to do without thinking about it, it is to LoOK like a new cool “better” way to do that sort of boring shit! And this contributes to Figma is being used to design stuff like web form select components over and over and over again, even though it absolutely objectively sucks at doing that task, and even though that task often doesn’t need to be done at all because for a large majority of UX a plain select is element is more than fine actually.
So maybe my feelings on Figma are really more about the fast fashionization of web design. Most websites and apps don’t need their own fully custom branded take on nav menus or basic form elements, and they certainly don’t need to re-invent that take every couple years! To accept that requirement as precondition for a “legitimate” product goes beyond wasteful towards actively harmful in terms of UX. To be fair I think this overly branded fast fashionization of UX is just a small part of a bigger trend of Rot (<- seriously, if you can muster up the attention, this is well worth your time) and while I am picking on the design field here, many engineering teams are no less guilty of something similar — just as often (every few years?) demand that in order to be “modern” and “legitimate” we need a full rewrite in whatever new tool or framework is trending. All of this too is an imposition on the users in that such endevors all-to-often hider us from providing real value with all of our work.
Or, I don’t know, maybe I am just an old man yelling at a cloud - or, maybe it’s both. Or, maybe it is neither and quibbling about Figma, or React, or Microservices, or GraphQL, or whatever over-hyped tool has earned my ire lately is just a coping mechanism to put my mind on something closer to hand. Onto an issue I can somewhat understand, rather than trying to grapple with whatever fresh political chaos is being thrust upon us all that has the potential to either steamroll me and my family or mostly harmlessly pass us by with utter disregard of what I happen to think about it.
In the end, go and make sure to tell all your co-workers you appreciate them as humans, and that includes, with compasion and empathy, finding the courage to tell them when necessary that some of what they are doing is a big waste of time, and to put that stuff aside so you can to build shit that matters! More so now than the last decade we need to avoid wasting time either not building stuff, building the wrong stuff, rebuilding stuff for vanity sake, or getting stuck in quagmires of confusion about what you have already built and what is left to build. I suspect the world is going to need a lot people with that mindset in the next years, Whatever label it would have.