When Figma starts designing us

https://designsystems.international/ideas/when-figma-starts-designing-us/

by bravomartin • 1 year ago

302 142 1 year ago

As someone who has to actually build the crazy parallax-3d-not-a-grid layout the designer may have spend an hour on, I'm glad.

Maybe free flowing designs shouldn't take place in figma, it should only be for the final output. Even then the majority of apps being built everyday are simple crud apps and shouldn't be overdesigned. They are built for people to do their jobs.

mananaysiempre2• 1 year ago

So, I’m not familliar with whatever Figma’s Auto Layout is, but the complaint still feels somewhat wrongheaded.

Design ≠ print design; if you’re designing for a reflowable medium, you’ll have to design to its constraints. A good prototyping tool should allow you to go outside the constraints for the moment, but for a web or mobile designer to dismiss those constraints as the engineer’s concern is about as appropriate as for a typographer to dismiss the constraints of type casting as the moldmaker’s: it won’t work.

nicoburns• 1 year ago

This is absolutely correct in this case. Figma Auto Layout is just a simplified version of Flexbox, and it's purpose is:

1. To adjust to size changes

2. To avoid having to manually position things in a row or column

d3vmax• 1 year ago

An innovative custom designer can use other tools or do manual animations / layout if they require.

_bent2• 1 year ago

It doesn't play to the strengths of designers to have them think in terms of Flex layouts and it doesn't play to the strengths of developers to have them translate a design 100% specified to the layout-algorithm and hierarchy of components into code. Yet this is the workflow Figma encourages.

What the author encourages is that the designers work more free-flowing with sketches and wireframes and that the developers take over earlier to bring that into a workable structure. And that the collaboration between designer and developer doesn't stop at an async hand-off, but that they finalize the design together -- in code.

Some of the commenters here seem to be annoyed at designers that make "hard to implement designs" and therefore think they want designers to constrain everything with auto layout. But this doesn't address the cause of the issue, which is designs being made by designers in isolation, which are then being treated as gospel for developers to 100% match. This is the real problem.

In my opinion the gravest issue with Figma encouraging this workflow is actually the feature gap. Figmas feature set is extremely underpowered in comparison to CSS. Figma doesn't even have grids. If designers are now building stuff only with the tools that Figma allows, all the cool and creative ideas that developers could bring in, because they are actually pretty easy to implement on their platform (the designer just doesn't know about it) will go away.

I can only recommend you this talk by Matthias Ott: https://www.youtube.com/watch?v=1Pq7VqNrtk4

wx1962• 1 year ago

Figma actually now has grids: https://help.figma.com/hc/en-us/articles/31289469907863-Use-...

Oarch• 1 year ago

It's absolutely trivial to make any element ignore the auto-layout grid.

yreg• 1 year ago

It sounds to me like what the effect that the author dislikes is actually more often than not a good thing.

Of course non-conventional designs have their time and place as well, but I'm not worried about designers being unable to pursue those just because Figma nudges them in the other direction.

esafak• 1 year ago

Isn't that just a guardrail or sensible default?

sumeruchat• 1 year ago

Engineers here will disagree of course but the job of the designer is to dream and your job is to build it

robertlagrant• 1 year ago

Just as the best architects were often engineers, the same is true of design.

tsunamifury• 1 year ago

No this is almost universally untrue. But they do have a solid grasp of it

asoneth3• 1 year ago

the designer is to dream and your job is to build it

You may be thinking of an artist. A designer's job is to understand and solve user problems.

(FYI this is coming from a designer, not an engineer.)

travisgriggs2• 1 year ago

Can someone help me understand when this bifurcation happened. As a Mechanical Enginneer who worked their way through college doing software, and then... just kept going for the next 30 years, I find this increasingly role based demarcation difficult to understand/accept. I came out of an era where we called ourselves engineers, but we were designers too. And a whole lot of other things. And the mantra regardless of label, was to solve the right problem for the right people.

I feel like software creation in this decade is increasingly about the creation of beauracracies. Different roles. Different processes. More people than ever before. Everyone vying that their contribution is essential, and that others need to stay in their lanes. I miss the old days honestly. I told myself I would not be like this as I aged. I'm struggling to execute on that hope. :|

I often call them the D's of organizations. Doers, Deciders, Discussers. We seem to have less and less respect for the plight of the Doer, and more and more desire to legitimize the others in disproportionate amounts. Pournelle's Law I guess.

n3storm2• 1 year ago

It should be as you say, but is not happening. I've found many artists using Divi and Elementor producing shit with premade crap blocks.

jacekm• 1 year ago

That's true in the world without budget constraints. Sometimes minimal changes in the design result in drastic changes to the implementation effort. Sure, I can build anything, but the client may not be happy if I spend a couple of months rewriting entire front-end just to accommodate designer's dream.

BoorishBears• 1 year ago

The first thing I did was search for the definition of art you're working with

What I found looked like a page that 4.1 nano (not even mini) would come up with, so I'm not sure where this energy is coming from

burnt-resistor5• 1 year ago

Designers must also make useful things rather than just pretty things or they are just artists rather than architects.

asoneth3• 1 year ago

Similar to software developers, there's a difference between meeting a user need with with established patterns and exploring novel ones.

The vast majority of consumer and enterprise products ought to be done with established design patterns. Figma is fine for this.

Whereas exploratory design is about coming up with novel patterns. Most of this work ends up being interesting but not particularly practical, and even when someone comes up with something great it's often not yet clear how and where it should be applied. In my experience only a few companies actually pull this off and the rest would be better off following existing conventions. Also in my experience, people who do exploratory design have a wider skillset and use a much broader and more flexible set of tools like pen and paper, physical prototypes, 3d modeling, computer graphics, video production, software development, etc.

The challenge has been that many designers are hired for the former but would prefer to do the latter.

meteyor• 1 year ago

I think what the author is saying is that we’re losing the human touch when doing our initial design work. I’ve felt the same way the past years working in Figma and seeing new features being introduced. It’s a pitty the industry is slowly merging roles together to the point we’re losing the personality in design.

miiiiiike4• 1 year ago

No, here’s the problem: Figma doesn’t go far enough.

If you need a free form design tool to sketch, use one. There are hundreds of them.

I need to implement my design system inside of a design tool so I can prototype designs with multiple breakpoints, container queries, modes, and variants. Figma isn’t up to the job. Ever tried opening the variables tab on the Material 3 Figma file? Stutter, stutter, stutter, “this tab is unresponsive”. You can barely view a long variable list, forget editing one with multiple modes. And, I hope your variable names aren’t too long, because you’re not going to be able to see them in most parts of the UI.

The problem with Figma isn’t that it’s too engineer-y for designers, the problem is that it’s too designer-y for engineers. I spent a month implementing my design system in Figma before giving up and just doing it in code. With Figma you run into all of the downsides of building the design system in code (deeply nested items breaking when you move/change something) but you get none of the advantages.

Figma is a mound of half-baked (vaguely web-like) ideas, poorly implemented. So many times I’ve had things just stop working with no way to figure out why. 99% of the time it’s just a bug and you have to reload the app.

If there’s something better than Figma out there, please, let me know. For now I’m sketching in Figma and building my design system with extensions to Style Dictionary.

PaulHoule3• 1 year ago

Yep.

Back in the 1990s there was a huge influx of people into web design who knew how to design for print at a "retail" level (design an ad or a poster) as opposed to a "wholesale" level (create a design system for a magazine) and as a dev I would frequently receive a PSD from a designer and figure out how to abuse the primitive HTML was had then to make something that looked like that.

Today Figma has replaced PSD but the same pathologies remain. A new version of iOS comes out and the armchair quarterbacks want to go over the appearance pixel by pixel but they're not really interested in UX design in the sense of designing a sequence of interactions to attain a goal.

As a dev, what I want from designers is design systems, guidance on what everything is supposed to look like that I can implement whatever I need to implement and have it look like a designer was involved. I blame the tools though less than I blame the designers who are just not inclined to think systematically. CSS was definitely designed to create design systems (css classes used in a disciplined way reflective of semantics) but tools like bootstrap, tailwind, Emotion, and the MUI theming system all represent regressions away from that ideal but I don't think those tools make bad designers, it's the other way around.

bornfreddy• 1 year ago

This! It is bad enough that most designers think they are UX experts too (few of them are), but trying to micromanage devs so that every screen would be "pixel perfect" really takes the cake. Especially when the provided designs (that should be followed religiously) are missing core functionality and the whole flows. Just give me the guidelines please, and please please be consistent with them!

Well, I'm sure they have their own set of gripes about the developers too. ;-)

sfifs• 1 year ago

So one of my teams was struggling with Figma to work with users. Then someone had the bright idea to just prompt an LLM to generate code for the mock UI and made it happen in 2 days. Far better user experience.

spookie• 1 year ago

Yeah...

Just do pictures on the design phase and then code.

miiiiiike4• 1 year ago

There’s a lot that goes into creating the pictures. Consistent spacing, colors that change depending on platform, breakpoints, containers, and on and on and on.

There’s no reason that a tool can’t model a design system and make producing consistent designs that use it trivial.

I think the problem with Figma is that it tries to appeal to visual designers, UX designers, and programmers. Good for business, bad for users.

danielvaughn2• 1 year ago

I’m actively working on an alternative right now. It’s a tool for designing in the browser, using HTML and CSS. Everything is parametric by design, including tokens.

Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.

desireco42• 1 year ago

Yeah we need that... and more HTML it is, the better.

ThePatientTiger3• 1 year ago

That would be awesome, Looking forward to it.

screye2• 1 year ago

Isn't this the problem with all no-code / low-code platforms ?

Code is merely the leanest human-readable representation for loss-less specification of requirements.

We're seeing this same pattern with 'K8s YAMLs' and 'prompt engineering'. There is an entire industry that's re-inventing new DSLs which inevitably converge to a scripting language as requirements get more complex.

Instead of reinventing the abstraction, I'd like to see no-code UX patterns that losslessly map onto the underlying abstraction. That way you can use the UX pattern until it gets too tedious, and occasionally dip in-and-out of the code-view in a non-jarring manner.

Graph UI for manipulating git trees (gitgraph) is a great example. Orchestration UI views (Airflow / Langraph) are another example that's getting there. At a higher level of abstraction, Notion (CRDT UIs) do a good job of representing collaboration-locks using blocks. At the highest view, I'm a big fan of how Gather-town represents remote collaboration.

I'd like to see more of this.

PaulHoule3• 1 year ago

From my viewpoint the benefit of low-code is that the average business application is a matter of people filling out forms. If you want to radically lower development time you have to solve all the problems

https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...

For instance, a 2025 no code platform is likely to have "one click" deployment of a cloud application. That's great if you can accept that but if you require "on prem" this is either disqualifying or requires you to build an environment on prem that can host whatever it is they generate, which could be more trouble than building an application the old fashioned way in an environment you already know how to run.

A conventional analysis is that you should be able to generate a CRUD application out of a schema: you need a little bit more than something that looks at a SQL schema and creates a form to INSERT, UPDATE or DELETE, but that's a start.

One problem is that people write schemas that suck despite there being a body of "commonsense knowledge" about how to the world works. I had a year when I fixed a tremendous number of broken applications and one insight I got out of that was that whether it was a student who went from being an applicant to being enrolled to being an alumni or a pallet that would live in a logistics network and then enter a "reverse logistics" network and be inspected and possibly repaired to be returned to the logistics network the same data model of an object going through a number of states with state transitions was general and much better than the 15+ date columns that were added haphazardly to those columns.

Another example that kept turning up was that the ticket "1 phone number for a customer is not enough, support 2 phone numbers" is inevitably followed by "2 phone numbers is not enough, support 3 phone numbers" -- it saves time to work the proof by induction up front and just support N phone numbers up front. But talk that way and people think you're a lunatic like Doug Lenat.

Deployment, code generation from schemas, and schema generation from meta-schemas are part of the solution but if you can't solve 100% now getting that last bit is ultra-hard mode because all the essential complexity hidden by the framework is suddenly in your face.

marcosdumay2• 1 year ago

Code is merely the leanest human-readable representation for loss-less specification of requirements.

Hum... That's assuming you have a perfect development stack that hides all non-essential complexity.

And well, I have news for you, that's a low-code platform. A generic stack that hides every problem but solves every requirement just can't exist.

screaminghawk• 1 year ago

I'd like to see no-code UX patterns that losslessly map onto the underlying abstraction. That way you can use the UX pattern until it gets too tedious, and occasionally dip in-and-out of the code-view in a non-jarring manner.

What are you describing sounds a lot like Saleforce and other CRM systems. Often the code implementation get hidden away when it's not something native in the no-code solution. Then "magic" happens and you don't quite know why until you dig into the code again.

sillyfluke2• 1 year ago

Code is merely the leanest human-readable representation for loss-less specification of requirements.

I think you might have meant "loss-less specification of the current design." requirements are aspirational, and signifies the intent, code is the loss-less version of how the system will actually behave.

NewsaHackO• 1 year ago

Are you saying thread product is laggy or your development process? If it's the latter, you sure youdont just need to update your computer?

miiiiiike4• 1 year ago

No. It's just not implemented in a way that would let it support a large design system, even on a 16-core machine with 128GB of RAM.

raincole• 1 year ago

If you need a free form design tool to sketch, use one. There are hundreds of them.

Before Figma, the norm of design tool was Photoshop, not the other "hundreds of them."

So go back in time, if you had been Figma founder developing a tool that appeals to most designers, it should've looked more like Photoshop than like CSS/HTML.

whywhywhywhy• 1 year ago

Fireworks also existed the whole time which had a lot of Figma's features but bizarrely was completely ignored by 95% of designers.

silvershell• 1 year ago

There is the sketch app , which is older and more of a direct competitor to Figma. Figma won because of being web based/ multi platform among other advantages.

cosmic_cheese2• 1 year ago

As a dev that does a lot of his own design, I’ve never really understood the need to build a full fidelity reproduction of the layout systems a design is targeting. The limitations and considerations involved are deeply internalized and for the most part, I know exactly where designs tend to break and how to account for them. The layout system is effectively running in my head the entire time I’m mocking things up.

So while it’s nice to have tools to help with menial bits like correct spacing, getting every little behavior right in the mockup feels a lot like unnecessary busywork.

Naturally things are a bit different in a team setting, because it can’t be assumed that everybody involved has this level of knowledge/experience, but well… maybe it’s not crazy to expect designers to carry this set of skills, and it’s perhaps not a good thing for parties outside of design and engineering to be able to easily poke and prod at designs directly. Having the design team as a required intermediary helps sanity check changes.

miiiiiike4• 1 year ago

I had my UX designer girlfriend read “CSS: The Definitive Guide” and it changed the way she looked at her job. She taught me Figma and it changed the way I look at my job, and hers.

Learn as much as you can. Specialization is for insects.

gyomu• 1 year ago

I’ve never really understood the need to build a full fidelity reproduction of the layout systems a design is targeting.

Well, you wrote why right before:

As a dev that does a lot of his own design

You understand the whole, so you don't need lossy abstractions to connect the ends. When roles are specialized and people only understand part of the context in which they're working, they need ways to communicate about the whole thing.

Tools like Figma fill those sort of gaps, that tend to occur in organizations with dozens/hundreds of employees, with the need to quickly onboard frequent new hires, etc.

cryptozeus• 1 year ago

I have totally opposite experience working on large ds at uber

brulard2• 1 year ago

Would you elaborate?

The5thElephant2• 1 year ago

Exactly this. Thank you.

We need a Blender-like design tool specifically for product design. Using HTML/CSS for rendering so it covers most web needs and that usually more than encompasses native app-layout emulation. Open source, technical, and not expected to be picked up in a day or fully understood top-to-bottom by everyone.

The reason Figma is putting us into a design box is because it doesn't have all the CSS features that actually let you create incredible experiences.

no_wizard5• 1 year ago

as much as folks hate electron, I think if Figma was electron, it would at least have the entire chromium web engine to work with

ThePatientTiger3• 1 year ago

"the problem is that it’s too designer-y for engineers"

Exactly! Numerous times I have wanted to start a new personal project however got stuck in figma designing process. Had no other chance except writing in pure html/css - the only things that still "work" for me unlike those stupid frameworks.

Vinnl• 1 year ago

I haven't used it myself yet, from what I've heard, Penpot is closer to filling that gap? https://penpot.app

And it's free and open source.

sghiassy• 1 year ago

I think the authors point, is that, designers are incorrectly choosing the wrong tool.

In my experience in FAANG, designers use Figma for everything. Like literally everything.

So when you say, they should use a sketch tool when they need free form, they don’t

carlosjobim• 1 year ago

If there’s something better than Figma out there, please, let me know.

HTML+CSS works very nice for these mock-ups. Tried Figma and Sketch for a small project, never again.

jason_plasmic• 1 year ago

I'm late to reply, but check out Plasmic. We often get the complaint that we're too engineer-y instead of designer-y, so it might work for you.

samsolomon• 1 year ago

I agree with the general sentiment—over-optimizing for design can both be a poor use of time and lead to less than ideal solutions.

I don't really agree that Figma is forcing designers into a box. The author feels like there's an ideal workflow—a quick sketch that gets translated into code. There's no ideal workflow. It completely depends on the delivery team.

That sketch to code flow probably works well with a small team that is used to working closely together. I've been working with most of the engineers on one of my delivery teams for five years. Frequently, I don't need designs at all! I can just write a JIRA card and because we are so used to working together many times they can pick up on the desired result.

Unfortunately, when the product org gets larger you get a lot of designers and engineers and delivery teams that don't spend a lot of time together. You need the clearest representation of those components—often documented down to the exact props that should be implemented. That is exactly how many enterprise software organizations are using Figma. Design and code components have props (for visual changes) that mirror one another.

Overall, Figma is geared pretty well to how many product orgs are delivering software.

quacked2• 1 year ago

I deeply, deeply despise the Figma-style design language that everything uses now, where there's barely any indication of what's clickable vs. what isn't and every screen is an endlessly-scrolling set of tiles and pills.

No borders, no button depth, no hyperlinks, huge swaths of blank monochrome space, menus distributed randomly, and my least favorite software design element of all time--scroll bars that aren't visible unless you're actively scrolling, but there actually are additional options on the list hidden in the borderless flat color below or above the list, so it looks like there's a static menu when in fact it's a scroll list.

I realize that I do not represent the most common user and that most people prefer as few clicked interactions with their software as possible (and also as little reading or learning as is possible), but I have vivid memories of when I could control computers and applications like I was at the command deck of a vehicle, and I greatly miss those days.

radley2• 1 year ago

That has nothing to do with Figma. That's all due to Jony-Ive-Deiter-Rams cargo-cult design thinking. I think liquid glass will remedy that specific issue (while introducing all new ones...)

quacked2• 1 year ago

Really? Every Figma mockup I've ever seen appears to be imitating that exact style. I don't think I've ever seen something different from any Figma product, even in their own advertisements. I thought it was a classic case of the tool/process constraining the design outputs, like those 5-over-1 designs that every new apartment building looks like.

burnt-resistor5• 1 year ago

Lack of affordances, to use UXspeak. This is terrible, user-hostile design.

renerick• 1 year ago

It's not like Figma forces to use those features, right? And also, hot take, "limits the possible expressions" is a good thing for application design. Application is not art, first and foremost it must solve user's use case, be accessible, discoverable, ergonomic and practical to implement. Aesthetics must serve and complement those purposes, not be the focus of the design

Towaway692• 1 year ago

Generalising the point the author is making: how do tools and programming languages shape/influence our thinking. I think this something we all should be asking ourselves.

It’s important to remember that certain concepts simply don’t occur to us as programmers because the language(s) we use.

For example how many JavaScript programmers know what an Erlang supervisor pattern is. How can they if JavaScript doesn’t support it. Perhaps the problem I’m facing in JS would be best solved using a supervisor but since it isn’t available, I don’t use it.

Even the language we speak influences our thinking, so do the tools we use and perhaps we should be aware of that.

cultofmetatron• 1 year ago

For example how many JavaScript programmers know what an Erlang supervisor pattern is. How can they if JavaScript doesn’t support it.

I've been running into the opposite issue. we built a project in liveview and the state management is not quite how I'd like it. pretty much everything is a callback to handle_info on a single object where you set the value to socket.assigns but no canonical way of organizing it. The pieces are all there to do some kind of stream based pipeline with an async reducer but no one has done it yet.

JS devs of course already know redux so this is a solved pattern in the js world

Towaway692• 1 year ago

sounds like a gen_redux is needed.

hm ... why not actually? What would go into a gen_redux ... gen_event and gen_statem and some coordinated message passing!

karohalik• 1 year ago

Yes, we should be cautious about tools shaping the way we think. But I’d argue that blaming Figma for narrowing the design process is like blaming Photoshop for bad photo editing. It's not the tool, it's how we use it.

zelphirkalt2• 1 year ago

It is a shame, that so few designers actually know the medium they are working with well, let alone the primitives, that they are operating on top of (CSS layouts). If they did, I think we would have many less shitty website designs. Personally, I would expect someone who calls themselves a "web designer" to know HTML and CSS of course, and in a more or less up to date fashion. Well, not really would expect, but would hope. Building flying air castles in Figma is not really a work that requires high qualification, and reality catches up with those fantasies, when the web dev is told to implement them.

H1Supreme• 1 year ago

How many web designer (ie. strictly HTML + CSS) roles are out there anymore? Anytime a position is posted with "HTML and CSS" in the requirements, you can almost guarantee a Javascript framework of some sort is in there as well.

ricardobeat• 1 year ago

That’s not the point - it’s been at least a decade since “web designer” means doing graphic/interaction design, and not coding in HTML and CSS.

What they are saying is that, in the same way a car designer cannot do a great job without having decent knowledge of aerodynamics and the physics involved, good design for the web requires some understanding of the underlying technologies.

dmix• 1 year ago

Translating Figmas from designers who don't understand web design is always the root problem, not the tools. They should be concepts of a design, but are often treated as what the final website should look and function like, even though they always overly value static aesthetic design over the chaotic nature of browser sizes, accessibility, variable font sizes, etc.

Which is why quality teams will have designers who have actually made websites before, outside a design or UX tool.

bbx• 1 year ago

Having designed websites with Dreamweaver, Photoshop, Illustrator and Sketch, I absolutely love Figma and especially Auto Layout. I don't think people realise how annoying it was to design a list of repeatable items. There already was a concept of "smart object" or "component" that could be duplicated in instances with variations. But laying them out was really cumbersome: if one of the instance had a different height, it would mess up the design because all subsequent items would need to be repositioned. The gap between them was also not a value: it was just space that wasn't used, so you couldn't interact with this gap.

Auto Layout fixes all those issues: you have a list of items of variable height with a fixed gap. You can very easily add/remove/reorder items, without breaking your design. You can even make it wrap, with different column and row gaps, and thus replicate a flexbox layout with "flex-wrap: wrap".

Each item can either hug its contents, have a fixed width, or grow. That's essentially flex-shrink and flex-grow in Figma. So useful.

You'll also notice that prototypes have a "responsive" mode, and it's amazing how Auto Layout will easily adapt to _any_ screen dimension. If you create a data table with one column that "fills" the space, you have a responsive prototype right out of the box.

Also, you can now drag an Auto Layout and it will fill it with component instances and replace its text content, essentially allowing you to fill your design in seconds. Incredible.

If the author still wants to manually place frames around, they still can. Just use fixed dimensions frames, with fixed positioning. That's similar to using "position: absolute" in your CSS. It's just a different type of design. Nothing forces you to use Auto Layout.

GenerWork• 1 year ago

I'm glad to see that someone else took issue with the Auto Layout part of this article. The shape, text, and grouping tools are all there and nothing is stopping anybody from using them to create new interfaces that have approximately zero auto snapping.

sevenseacat• 1 year ago

I loved Illustrator way way back in the day when I was a poor student with a cracked version. I found it so easy to use!

Design software nowadays... oh boy

pyrale• 1 year ago

Completely agree with the author.

This is contrary to my belief that any digital design process should start with rough sketches, but move quickly into code and iterate from there.

As a dev, this is the point I resonate with the most.

To me, the ideal dev <> designer interaction is collaborative and iterative. But the current state of affairs is one where all the design is done upfront, and little is done in terms of explaining why some choices were made. Mockups are not a good medium to spark discussions in the team, because developers are left in the dark about intent.

andrewingram• 1 year ago

Ditto.

To me, one of the dirtiest words in dev <> designer interaction is "handoff". There's always a point in the lifecycle of any design tool where they start talking about it -- even if they quietly disagree with it in principle. My impression is that it normally happens when they're trying to acquire customers who (unfortunately) practice such dysfunctional team dynamics.

As a developer who designs, I've always found myself jumping between code and visual design tools; but rarely based on the current stage of the project and more often based on what kind of thinking I want to do. If I want to engage with the constraints I more often do it in code, if I want to explore tangents, I open up the design tool.

graypegg3• 1 year ago

Ive really warmed up to the lowercase-a "agile" way of working in this way. Earlier in my career I just wanted design to have everything fleshed out and ready to go, that was their "job". I’ve now seen that fail multiple times.

It can be hard to communicate it to coworkers sometimes, but a lot of this would be much smoother if we all understood our jobs as making the product we ship. The design isn’t a product and nor is the repo. The designer might hold the pencil, and I might hold the brush but we’re both working on the same canvas.

Lalabadie2• 1 year ago

I'm seeing lots of opinions from people in different roles who wish Figma would serve them, but I agree with the author.

Assuming Figma is meant to serve the design process, it tries to stretch far into implementation territory, but does it at the expense of the exploratory phase. Everything Figma adds either screams MAKE IT READY FOR DEV or GET ALL YOUR MANAGERS A FIGMA SEAT™. Those are not concerns for the early exploration and research stage. If Figma is one of the first tools I boot up in my design process, I'm immediately running into a conflict of priorities.

I put it in contrast with old-school Photoshop UI work (younger devs: yeah, it was pretty much the one option, plus the only thing taught at design schools). Photoshop was great at the exploratory phase. I would sketch ideas with my Wacom tablet and eventually translate hand-drawn wireframes to actual mockups. I still miss that workflow, it was great. The tradeoff then was that "final" documents were static, fixed dimensions documents that usually left technical issues to be discovered later during the dev stage.

Photoshop shaped the design process just as much as Figma does now. That's what the readily available tool does to someone using it regularly.

zdragnar2• 1 year ago

Unless you're building content-marketing or similar- you don't need a lot of the exploratory phase to be done freeform.

Trying to implement designs in a product where every single new design stretches or modifies the design system is mind bogglingly annoying as a developer, especially if you've got a small team trying to crank out new features. We don't need a tenth variation of a call to action, we don't need to use a new, tenth shade of blue or green for just this one place, we don't need a twentieth exception to the existing padding rules. If it is one size on desktop and another in mobile everywhere else, then those are how the sizes should change in this new feature too.

Once you've got a design language in place, leave it alone unless the change to the semantics is meaningful and consistent.

Having done the slice and dice of Photoshop files in years gone past, I'm very glad we have better tools for collaboration now.

et-al• 1 year ago

Agreed 100%. This op-ed on a site called design systems is ironic.

The purpose of design systems is for visual consistency. If someone needs to freehand some ideas, bust out a blank sheet of paper or Illustrator, but when designing a new page for a app, we want all that baggage of existing components and layouts.

Lalabadie2• 1 year ago

These are complaints about the designer you are working with and the deliverables they're choosing to give you, are they not?

Figma isn't/shouldn't be the arbiter of what's possible in the project, that's a major point of the article.

My role as a designer is to explore options and _then_ narrow down to a sensible solution (diamond-shaped process, etc etc). My developer colleague is concerned by the second part of that process, and I should make sure to provide her with consistency and sensible use of exceptions. That doesn't change my responsibilities to the exploratory part, and I can't exclude it from my consideration when choosing and critiquing tools.

Hammershaft2• 1 year ago

Exploratory design isn't for crafting padding overwrites and call to action tweaks...

It's for thinking from first principles about the problems users face, and how to shape the products we create to best help those users overcome their problems. This means reconsidering faulty assumptions about the nature of the problem users face & the shape of the product that best solves that problem.

I hate this shift of the role of design in software towards trivial aesthetic fixations.

Design should be a shared discipline that orients product development towards greater value for users, but as of late it's mostly a trendy & low value extension of marketing.

pcurve• 1 year ago

Figma has neglected its core audience - the designers.

Instead, it is trying to be all things to everyone, except it's serving no on well at this point.

And it all started with FigJam. Still a half-baked product trying to take piece of pie from Miro.

Then they released Dev Mode to extract more revenue. Now Figma Sites to compete against web build/hosting sites.

So many half baked products, it's frustrating. They're abusing their monopolistic position in the market.

there will be a time where they'll have to pull a Google and retire products that never worked out.

jjcm3• 1 year ago

PM on Design Systems here at Figma.

There's an element of truth to this post, but I think the author's conclusions are incorrect.

First is the truth - we are working on things that allow designs to be closer to code (allow here is the key word, not enforce). We've always seen Figma as being at the center between Freeform and Structured design - I talked about it in depth during our keynote at Schema 3 years ago: https://youtu.be/Yo7rL0pvHTk?t=147

Our goal is to enable both, not push designers towards one or the other. The author notes:

You can’t drag things around freely or try odd combinations of layouts. You can’t simply paste something into a frame without it snapping to the bottom of the stack.

What the author is seeing isn't Figma restricting your ability to design, it's other designers adopting it as part of their process. I'd encourage the author to dive into the why of that. What we've found is that often times these structured design approaches can accelerate even freeform design - rarely do you want a menu that doesn't have equal gaps between similar items, so quickly adding that logic can let you move faster. More importantly though, quickly moving past those repetitive parts of the design can let you more quickly focus on the more creative parts.

All that said, these structured approaches can be overbaked, which is what the author might be seeing. Knowing when not to use features such as autolayout can be just as important as knowing how to use them. The most important thing though is you can always detach from them. One of the top requests we've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.

Happy to answer any questions about any of this though - this is my bread and butter.

no_wizard5• 1 year ago

allow here is the key word, not enforce

Is there any way you can get a global toggle to change that? Because enforce is what is often desired but its not possible to put sufficient guard rails in place to do so. Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one

The most important thing though is you can always detach from them. One of the top requests we've had from Design Systems authors for a while now is to prevent detaches, but it something we've never implemented, mainly because we always want a way to allow the designer to fully go back to that freeform design mentality. You can always remove an autolayout, you can always detach an instance, you can always break a variable. They're optional features, not handcuffs that bind you. If you want to go a step further, there are plenty of plugins out there that fully detach all restrictive elements on a selection, making all colors a hex code, all autolayouts removed, and everything absolutely positioned so you can just drag things around. We don't provide a native feature to do this (since it's a fairly extreme measure that removes a lot of helpful metadata), but we also don't prevent actions like this if people really want to go to the creative extremes.

Its not always useful to be able to let people do this though, if you're implementing a feature in applications design side, and it needs to best represent the constraints of the team who will need to implement it on the engineering side, shared constraints would be amazing so they don't diverge too much, and you can get actual consistency.

What you're basically saying is: fuck consistency, this tool doesn't care about an organizations need to enforce that on a tool level

jjcm3• 1 year ago

Is there any way you can get a global toggle to change that? Because enforce is what is often desired

I agree with your premise, but not with your conclusion. A way to block detaches would not bring this closer to code - there's no real concept of "detach" in code, but you can always simply create a new component. In the same way, we want designers to have the capability as well. You do land on the correct way to address this however:

Engineers have tests and linters, there's no allegory to that in the design world, and it desperately needs one

Linting on handoff, aka process, is the way to solve this, not dogmatic restrictions. You should always provide freeform design, otherwise your design language never evolves to changing requirements, but doing so should be an explicit choice and part of a process. Completely locking that down will also lock down creativity. This is what I was talking about in the talk I linked above about balance - going too far on either end will harm the overall process.

drewbeck3• 1 year ago

I've never worked in an org where this would be necessary but I can see the use case. If you only want to give your designers building blocks and expect them to use them only, then preventing detach makes a lot of sense.

If there's any flexibility in your designers' work, though, preventing detach would be very frustrating: to create a new thing we'll (designers) often pull from an existing component and detach it in order to harvest it for parts. Not being able to do that would drive me batty.

martinald2• 1 year ago

FWIW I think you're mostly on the right track. I have noticed the "implementation ability" of designs that have came over from designers since figma had autolayout massively improve.

Maybe there is an argument that it is stifling creativity (though I'm not entirely convinced of this), but it is saving SO MUCH eng time on implementing (or going back and forth) on 'non standard' elements that are often not very intentional nor have the designers realised the impact of them, especially when it comes to responsive design.

FWIW I think the next big improvement (from eng side) would be some sort of (simplified?) git style version control for figma. For big projects with many people collaborating this would be hugely helpful, but would actually be hugely useful even with small teams.

We often spend so much time as engs implementing designs to find out they were one revision behind or hadn't actually been signed off, especially working remotely.

jjcm3• 1 year ago

I think the next big improvement (from eng side) would be some sort of (simplified?) git style version control for figma

FWIW, we do have a simplified version of version control already - there's both version history as well as branching & merging in Figma. There are some restrictions with it however that make it less compatible with the way engineers think about versioning - namely you can't tie it to a version number, and you can't have multiple versions in use at once (ie you can't publish both a 2.0 and a 3.0 version of a library). We are looking at improving this, but as I think you caught on, there's a balance between making it equivalent to eng flows while also simple enough for more casual designers.

valencamacho80• 1 year ago

You've perfectly captured my frustration with Figma, thank you.

ranie93• 1 year ago

Tangential: I have similar thoughts about Jira. The ticket-fication of organizational goals. At least it would be useful to pen any negative repercussions of this

graypegg3• 1 year ago

I know it’s trite to just say “you aren’t holding it right!” when it comes to JIRA, but I do think there’s a sensible tool underneath layers of self-inflicted pain. (Self = Atlassian and its users)

User stories, when they’re actually a real problem a real user would need solved, are fine. If you start there, and figuring out how to solve that problem is open to anyone on the team, and you keep the complexity to a minimum (aka, just todo/inprogress/done statuses, and you only try to solve the problem in the story) it’s totally cromulent…

…for start ups who need to ship yesterday and have money to burn.

So IMO not like, the best way to do work, but to do something as fast as possible with people motivated by the problems you’re solving, I like it.

marcosdumay2• 1 year ago

User stories, when they’re actually a real problem a real user would need solved, are fine.

Some times. Other times they are detrimental, you need an algebra of composable operations up-front and any abstraction you put on the process of designing those will make people design a broken UX.

User stories are useful mostly for "flux-based" applications where the user has little freedom.

user9999999999• 1 year ago

this is why using atlassians old tired products will also leak into your apps ux

drewbeck3• 1 year ago

The author wishes for a specific workflow that is neither determined nor prevented by Figma. Our tools shape us, yes, but it’s the organization and leadership that actually has the power to create the workflow the author wants, not the tool.

There’s no tool that designers can use that will force organizations to adopt this preferred workflow.

The tools shape us, undeniably, but the agency lies with us. Blaming the tool misses the true story of who has the power to make the world you want.

And as a designer who has to contend with a design system and building consistent UI … this vision of sketch→code→ iterate is beautiful but does not work at scale. Is every feature meant to be a greenfield new idea maximizing my creativity? No. That’s not the job. The job is to create consistent elegant interfaces, and reusing components and tokens and utilizing auto layout is absolutely critical to ensure this. (Okay, I did it before Figma but it took 5x as long and was very difficult to mantain!)

dmackerman• 1 year ago

Nothing forces you into using Auto Layout. If you want to drag frames around during ideation, the tool supports that. This is a non-issue.

travisgriggs2• 1 year ago

Wow. Trying to work with a design for hire house lately, who insists that Figma is THE TOOL we must be ALL IN on. This paragraph

> Another feature is Dev Mode, which, in theory, is the missing bridge between the design specification and the technical implementation. However, it enforces a mindset where designers polish designs far away from the technology they are designing for, and where enormous amounts of time are spent on building complex prototypes, only for them to be discarded and rebuilt in code...

really strikes home.

ThePatientTiger3• 1 year ago

The "problem" is not figma. It is design in general. Everybody are coping each other which makes sense: You cannot copyright a design and also copying is much easier - and looks better - than designing from scratch.

However while designers will definitely think this as a "problem" which would kill creativity, I as an engineer think that it is the path that would happen later if not now. You can't really blame companies if they want to copy other successful designs - it works.

burnt-resistor5• 1 year ago

Coping or copying?

rorylaitila• 1 year ago

I never really got the almost code, but still not code appeal of figma. Like the author, I get the design into real code asap. I'll even use a sketch CSS library just so the client can interact and give real feedback. Clicking through an interactive but fake UX is just not real enough for me. Too much bike shedding.

As far as web application design, there are only so many useful idioms. Iterating over actual working interfaces I find the most rapid and satisfying way to design. I built my last app this way. Albeit I'm in ultimate control of the design and build. Experience may differ if these are separate responsibilities.

iamcalledrob• 1 year ago

As someone who's worked in this field and seen it evolve for 20 years, this article really captures how I feel too about how tools shape your mindset and what you create.

The tool you have at hand has a huge impact on how you think. "When all you have is a hammer, everything looks like a nail" and all that.

Nothing shuts down a feeling of exploration and creativity more than loading up a Figma file made up of components assembled with auto-layout. Sometimes you just want to play, rules be damned. That's when the magic happens.

This is not a dig at Figma. It just happens to be that Figma has become huge, and so the opinion its UI has about what you should be designing has a huge impact on the industry.

n3storm2• 1 year ago

Thanks to this threads I feel less alone about how uncomfortable using figma is.

JoeSugma• 1 year ago

Figma balls

deepsun• 1 year ago

Curious why previous discussions are [dead]?

https://news.ycombinator.com/from?site=designsystems.interna...

karaterobot2• 1 year ago

A concrete example is Auto Layout... In practice, this locks the design in place and severely limits the possible expressions. You can’t drag things around freely or try odd combinations of layouts.

I'm a designer, I've used Figma since 2018, and this is incorrect. And not even incorrect in an "I feel differently, but I see what you mean" way. It's the opposite of correct. It's categorically wrong. Autolayout makes it easier to slap layouts together quickly, and change them quickly. The alternative is selecting the object and moving it with the arrows keys, which accomplishes the same thing but is slower, harder, less precise, and worse. It's not creatively empowering to manually align and space objects.

“Ready for dev” implies that the creation is done and that the developer is merely there to execute the designer’s vision

Don't worry, no engineer I've ever worked with has shared your confusion.

"Ready for dev" is a work management trigger, like closing a ticket—or, more accurately, marking it ready for review. It doesn't mean anything except "this is ready for dev to look at and leave feedback". There is nothing about flagging a section as `ready for dev` that forces engineers to work on it as though it were canon law.

markbao• 1 year ago

I don’t see how it could be categorically wrong. To me it’s categorically right: Auto Layout specifically is intended to restrict the possible layout options.

You trade off adding limitations for how much you can do in a design and move things around freely, and in return you gain more convenience and less work needed to organize designs. You can change designs around quickly… as long as they’re within the rather confined limitations of Auto Layout.

I think the fundamental disagreement is that one person sees creative empowerment as freedom from doing busywork, whereas another (including the author) sees it as freedom to experiment with a design without limits. Neither is inherently wrong, but the two are inherently in conflict.

karaterobot2• 1 year ago

To me it’s categorically right: Auto Layout specifically is intended to restrict the possible layout options.

Except that you do not need to use Auto Layout if you don't want to mimic the flow of objects inside a flexbox container. You can just use a regular frame, and position things freely within it. Or, you can use an Auto Layout, but then absolutely position arbitrary elements inside that Auto Layout frame if you want. Auto Layout does not restrict a designer's layout options, it only adds to them.

Hammershaft2• 1 year ago

Don't worry, no engineer I've ever worked with has shared your confusion.

I have seen nontechnical product managers share this confusion to the strong detriment of projects.

zelphirkalt2• 1 year ago

I am not using Figma at all. Not a designer, and I know CSS, at least the part I am using and am not afraid of looking into it more when I need more. For example recently I wanted a grid layout, that has at maximum 2 columns and wraps to 1 column when not sufficient space for both columns is available, so I looked up how to do that.

"Ready for dev" -- If we expand that abbreviation, then it would be "ready for development" or "ready for developer", so the actual literal meaning to me seems to be: "Now you can show this to a developer so that they can _properly_ develop it." and not "Now put this onto your production website, you are done!"

Might be that many people get confused though.

dandano• 1 year ago

I disagree with this take. I work very closely with my UX lead and we always do lo-fi in Miro/Figjam before hi-fi designs in Figma. This gives us flexibility of expression to quickly mock things up loosely before going into the final design. Auto-layout, components is a huge win for designers. We were on another design product called UXPin which didn't have this sophistication and it was an absolute drag.

rukuu001• 1 year ago

Meh. Figma is for UI designs, not "Design", in the sense of what Creative Review mag etc

ripped_britches• 1 year ago

I would agree but this is an organizational issue, not a Figma issue.

This is endemic to corporate engineering culture.

You can tell because they/us layer even more nonsense atop these Figma features like multiple composed layers of design tokens.

I literally had a design manager ask if we need a token for full opacity. Let that sink in for a second… A variable to represent something with 0% transparency. Under what circumstance would that possibly be useful?

HellDunkel• 1 year ago

I don’t agree with the overarching theme of „structure over spontaneity“. Some of the most impactfull print designs of the past started with „structure“ or some orher sort of „form follows function“.

Separo• 1 year ago

As a once full-time designer turned full-time engineer, I totally agree with the author.

There are plenty of other more creative design tools - but Figma's success and ubiquity have locked many organisations into more limited, sometimes formulaic and un-creative design expressions.

Also, I unfortunately don't feel that this is the ideal forum for this idea to get much support.

burnt-resistor5• 1 year ago

It's kind of like observations from psycholinguistics: language shapes culture and ideas, and vice-versa. Perhaps the tool makers should listen even more closely to designers to maintain the essential expression of creativity, and this might mean physible assistive devices in the real world.

When Figma starts designing us

Related Stories