When Figma starts designing us
designsystems.international
designsystems.international
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.
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.
Well, I'm sure they have their own set of gripes about the developers too. ;-)
Just do pictures on the design phase and then code.
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.
Draw each screen at least once. If you have dark mode, you don't have to fully redraw each screen in dark mode, just enough to show how dark mode should look. If it has to work on desktop, you probably do have a completely different desktop version of each screen (from the default mobile) so draw that - but don't redraw every detail of a widget that's identical to mobile.
Testing every combination should be for the testing stage. It's good if you can foresee clashes (like the desktop version of this widget looks bad on this page in dark mode) in the design stage but it's not really an excuse to prolong the design so long that it lasts until you would have been finished with testing anyway.
Having a computer generate all the combinations for you in the design stage isn't that great unless you can pay individual attention to them - there's no point producing artefacts that nobody looks at.
Eventually I’ll have a working end-to-end prototype together, but not yet unfortunately.
I’m incredibly pumped for it, though. It’s almost entirely keyboard driven, kinda like Vim. I’m building this rich set of mnemonic commands to build/design UI components. It’s like Vim + Storybook + WebFlow.
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.
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.
It amazes me that anyone would write a schema with a dozen date columns, but I've seen such things. Once you're dealing with a large database of something like that, it's tempting to just add one more column rather than pitch why you should refactor the whole thing.
I try to keep my schemas relational as possible. Actions and immutable records should obviously be stored in separate tables from the objects they reference. However, this does make the UX form design / CRUD process less amenable to simple solutions where forms are just generated right out of a schema.
Your phone number example highlights this. In general of course you want to store contacts in a separate table from customers. But that means you're probably going to need a separate contacts sub-form within your customer form, rather than just inline phone fields. Then form will need to be required or inlined for any new customer before the main customer form can be saved. Stuff like that.
Over the last 15 years or so I've built and refined my own form generator, really a DSL for designing forms that fit this type of thing. In its more basic use cases, each form lives as a row in a database, with each form_item linked to it in a separate table. The form runs a pre-fab query that expects N inputs that it binds to :variables (usually in WHERE or HAVING clauses) and then renders a pre-populated visual form with various input types like dropdowns, checkboxes, calendars, etc (based on those form_items, which can all be styled, required/not required, required based on other answers, etc). Each form_item has its own standard validation or custom validation function on both the client and server side. The form knows which table it wants to write to and which bound variable is the id field it's going to target for update. Sending it a blank id field renders the form with nothing populated and then does an insert instead of an update when it's submitted. It's very slim, about 500 LOC of Typescript and 700 LOC of PHP, including most standard kinds of validations on both ends. I've always toyed with the idea of releasing it it for people to use, but here's the rub: If you want to do anything involving writing to more than one table, you need to write a custom final function for those additional insert/updates.
So, it's a lovely system, but someone coming to it naively would run the risk of designing schemas that were not expressive enough, to try to keep the CRUD system happy. And I think this is just an inevitable problem with all low-code solutions: They don't handle multi-dimensional data the way you want a clean schema to handle it. (And neither do users).
They all saved to relational databases with multiple tables. One form editor (which wasn't mine), allowed you to add new columns (this was in the on-prem days and back then they avoided future collisions by prefixing the custom columns with ex_).
The problems you listed above are solveable. You don't need custom functions, you need clever property naming. Most ORMs have to solve them too.
So nested data is not actually a problem for lo-code solutions, it's a solvable/solved problem.
And I STILL regularly leave that sort of data denormalized. I write multiple date columns (e.g. created, lastUpdated, etc.). I still write mobile + work numbers as columns for plenty of apps.
Why? It's simple YAGNI. For many apps it's quicker and easier to denormalize the data and keeps the code much, much simpler.
Plenty of apps that I've seen that have been going 15+ years haven't normalized that data and it's fine.
The problem comes when no-one refactors and keeps adding them.
But it's extra work and it's "dangerous" work, potentially data destroying if you get it wrong.
You get no thanks, as other devs will moan it's more complicated to use, and if you slip up you might get fired.
So most devs take the easier and safer option and just add a new column.
One of the ironic things, to bring it back to Figma, is that giving designers and stakeholders Figma in all its glory becomes a justification for having engineers on the project, because you can't realize those exciting design visions with just Airtable and the like. Those engineers aren't useful because they can write code; they're useful because they'll (hopefully!) think through those change management and schema design considerations, building something that will be maintainable in the future. It's a good thing to have a design tool that incentivizes a level of foresight before launching a product that's meant to be best-in-class.
Zero. One. Infinity.
https://en.m.wikipedia.org/wiki/Zero_one_infinity_rule
YAGNI, handle a singular case, and once you have multiple treat it like a list.
Adding multiple non-list fields is seductive because going to the list is a "structural instability" that requires using different coding techniques.
Right now I really like https://www.react-hook-form.com/ for forms that have list values. Back in the day there were a set of techniques that seem forgotten (like how the Egyptians built the pyramids) that some developers knew and others didn't.
It isn't hard at all to make a no-JS form where you had an "add" button next to a list of values. When you click on that button the POST data contains everything in the form as well as the key/value pair for that particular button (and not other buttons) so the back end can tell which button was pressed and redraw the form with another field. Delete can be handled the same way. If your form is not junked up with 50MB of trackers and ads and metadata for every social platform it is really fast, it was really fast even on dialup.
With a handful of helper functions and a "router" that can display different forms depending on what you enter you can make powerful no-JS forms but that knowledge didn't quite reach 100% penetration before Angular came along, but developers who came on after that never learned it.
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.
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.
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.
Stated otherwise: "Sufficiently advanced requirements are indistinguishable from code".
Abstracted requirements define outcomes. Fine-grained requirements define code.
The customer has given a requirement that states the variable <y> has to be calculated as y= x +1.
However, the code that exists has been implemented such that <y> is calculated as y= x - 1.
y=x-1 is how the current system behaves. However it conflicts with the actual requirement, which is y=x+1.
If the customer would like to describe the ideal behavior of the system, the only way is to translate it into code.
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.
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.
Learn as much as you can. Specialization is for insects.
There are still a number of “old school” UI designers out there who’ve resisted trends and have staunchly stuck to a more traditional workflow, where they start out with a rough mockup made in e.g. Photoshop and then iterate the design alongside an engineer. It would be interesting to be in the room amidst a discussion between one of these traditionalists and a “new age” Figma-type UI designer.
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.
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.
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.
And it's free and open source.
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
HTML+CSS works very nice for these mock-ups. Tried Figma and Sketch for a small project, never again.
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.
1. To adjust to size changes
2. To avoid having to manually position things in a row or column
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
Figma has a bunch of good tooling, but getting designers to use it, and use it consistently, is the real problem.
Designers exist in a realm seemingly, where outside pressure can't really be put on it from an organizational level to get them to uniformly adopt a set of standards they will always adhere to. Every company I have worked at, big, medium, small, seems to have this problem
Browsers are by and large black boxes—less because of their architecture and more because of the sheer size of the code, although Firefox, for example, seems to have been moving towards a less open architecture for most of its history as well (deCOMtamination, death of XULRunner, Quantum, etc.).
What you really want in a parametric web design tool is to crack open the layout engine and the CSS cascade and inheritance, at the very least. That’s a lot of work to target a demographic of designers and programmers who by now have largely decided to ignore CSS in favour of reinventing inline styles badly (Tailwind) and insert markup as necessary for the desired visual effect. (Is there a tool to do CSS in terms of React/etc. components, with proper cascading, custom pseudoclasses and pseudoelements and so on? I haven’t seen one.)
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.
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.
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.
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.
It is, to some degree, but the tools don't help any related party enforce consistency that will translate to the broader output of that work, that doesn't help matters very much.
In addition, designers themselves by and large don't seem to care enough about consistency like this. Engineers have design systems (ideally) that they pull from, but I'm still shocked in 2025 there is no good 1-1 communication of imposing the constraints of a design system in the designer <> engineer workflow.
Not to mention, for every designer I know that does adopt features of the tool that make this easier, like auto layout, there's a much greater number of designers that refuse to use them.
Seemingly, engineers hold themselves to a higher standard of consistency than designers do. I've seen this pattern too many times and its the only reasonable conclusion I've been able to draw. I was even hired to help streamline engineering and design work together and share as much as possible to get a corporate design system adopted, and I always had a hell of alot more resistance and argument with the design side of that equation on this.
edit: after seeing someone from Figma comment, I feel its unlikely it will ever have any of these types of features, which is a shame
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.
When you do, you end up with prototypes that are disconnected from what exists, and don't look good when you actually start using the existing visual design system. That's where all the one-off tweaks start coming in.
Unless the business is willing to pay for research into a holistic change to the semantics of the existing design system, Figma is perfectly suitable for the majority of design work once a cohesive design language has been put together.
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.
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.
Design software nowadays... oh boy
> 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.
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.
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.
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.
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.
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.
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.
I have seen nontechnical product managers share this confusion to the strong detriment of projects.
"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.
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.
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.
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
hm ... why not actually? What would go into a gen_redux ... gen_event and gen_statem and some coordinated message passing!
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.
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.
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
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.
Process is fine, but enforcing process is what is desired. Being able to express constraints globally (IE, organizationally) may limit creativity in an absolute sense, but within constraints you can have your own kind of creativity.
That means not designing features that don't fit within the bounds of a layout for example. Not the easiest to 'process lint', but the tool would know instantly. Thats what I'm talking about. Hand waving that away as a 'process human problem' is disingenuous and I'm rather frustrated thats the response Figma has to this.
So called "dogmatic restrictions" exist for a reason. Though, to say being able to enforce consistency by being able to say, only allow auto layout and associated features, isn't really 'dogmatic'. Just like linters catch features of a language nobody really should use anymore (like JavaScript's `with` for example) is the correct way to solve this problem. Thats not really dogmatic, its just good hygiene.
If Figma doesn't care about any of these real problems, than fine, then make yourself plain and say so explicitly, otherwise the tool has a huge gap in functionality that makes it irritating to actually evolve with.
I imagine this is why Figma has no concept of a staging area either, or a proper VCS, nor a review pipeline, which are also gaps in functionality that would relieve so many issues
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.
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.
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.
Right now I'm generally working with smaller teams/contractors for design stuff (I think this is very common btw that you have one designer and at most a couple of FE engineers actually working on this) - even in larger organisations I've collaborated with doing dev implementation for them I'm not sure many have upgraded to enterprise, but I get a somewhat limited view of Figma from the outside.
It would be awesome if you could enable this with a limited number of branches or something (even 2 would be a start - master/staging vibes) for pro plans. But I do understand that you need to push people to a higher tier - but I imagine it would really help adoption if I could push back to everyone saying please use branches. It's good to know though for future this exists!
>> 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.
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!)
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.
Which is why quality teams will have designers who have actually made websites before, outside a design or UX tool.
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.
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.
I'd say basically only useful for those sorts of applications! If you're going by user stories, there should only really be 1 way of solving any 1 issue, and users should get rail-roaded into it. There's always a solution to problems you've closed user stories for, but that's it. Anything outside those is unconsidered and might not even have a "hackable" solution since you're building everything up organically rather than as a designed system.
Great for start ups (saved time and money building the impactful flows, your product only needs to do a few things) but awful for enterprises (users have no freedom to warp your product to their needs, your product needs some predictable structure/rules they can build on... those composable operations you're mentioning.)
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.
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.
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.
https://news.ycombinator.com/from?site=designsystems.interna...
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.
FWIW, minimalism was a super-convenient solution that helped developers avoid responsive skeuomorphism. The issue at hand is simply due to designers who poorly execute minimalism, either through ignorance or fanaticism. It's kinda like people who still, enthusiastically, stand in line for new iPhones.
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?
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.
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.)
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.
The distinction is as old as art and design. If I had to pick modern moments that articulated it well I'd go with Arts and Crafts followed by Bauhaus.
> solve the right problem for the right people
Solving problems is the core of design and a design can be evaluated on the basis of how well it solves a problem. Whereas art is free to simply exist. Many works have elements of both, but if you hire someone to solve a problem and they believe their job is to make art then you'll both be disappointed.
I'm unsure what motivated the rest of your post though I can feel your frustration. I will say that bureaucracies and processes have been around for centuries, they just shift language every decade or so. There has also always been a tension between the people who Do and the people who Decide but both are necessary for a functional organization.
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
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.