I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause.
Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general design work. There's way too much to do with media break points and tokenization there. There's a misguided group of designers that are learning a lot of esoteric Figma features that don't translate into something users will ever touch.
10 and 15 years ago designers needed to learn the code part too. Somewhere along the way we put them in a corner and made learn these prototype tools.
I agree with this sentiment. I built and led a "Product Design Team" of about 50, and there were no mockup designers on my team. Either the designers can write some code,, or they can design directly in HTML/CSS. The mockup designers work with the team, and I encourage them to understand the limitations and power of the engineering team. I found that many designers end up short at the "mockups to impress the client" stage and are more artistic than being designers.
Any styles/CSS generated by a visual tool will always be limited to the vicinity of that particular design. But in the real world, the design of an entire website/app/platform should be a cohesive network of patterns and consistencies in the whole ecosystem - this is why understanding and designing in HTML/CSS finally makes more sense.
Yes, the standalone designers will be there, but they will always be disabled and limited unless they, at least, learn how the whole thing fits in, and their designs are just the pieces that fit elsewhere in entirely different ways.
I'm lucky to have been able to play the role of a designer, a developer, and business-sy sales pitching to customers and closing the loop by answering questions from all personas. This also did left me being more of a generalist and not a specialist.
Figma and other tools, however good they become, will always be that prototyping tool for playground before the actual work starts.
> There's way too much to do with media break points
As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier.
It easily snowballs into you having 3 different CSS (phone/tablet/desktop).
I wish there was something akin to 'light-dark' (where you can specific a different value conditional on the environment) but would be trigger based on window size.
e.g.
font-size: window-size(1.2em, 1em, 0.8em)
Which would translate to, if the browser window is small (phone), use 1.2em ... if browser window is large (desktop), use 0.8em
If you want responsive page elements that change styling as you reflow the page, we have that now - container queries - https://developer.chrome.com/blog/css-ui-ecommerce-cq but it's still somewhat new, and nobody's existing design systems support them yet. People (myself included sometimes) still prefer using JavaScript for this stuff. It'll change over time, though. (Also I've been wishing for this for almost two decades now, so I'm glad to see it arrive!)
I've just found that approach very clunky in practice, hence my comment about it snowballs into effectively having 3 different CSS (phone/tablet/desktop) and wrapped in media width queries.
Well, I'm not sure of other syntaxes to make it simpler, but you could use a CSS variable to make it a little easier: https://developer.mozilla.org/en-US/docs/Web/CSS/var Especially if you re-use the same padding values for multiple parts of the page/site. Then you won't have to update values in 3 different places for each padding/font-size/whatever rule. Instead just set the variable for each @media width and then in your later rules, use the single variable to refer to the correct value for all breakpoints.
Also, some units cascade. So if you set the top-level or parent to a particular size, then child elements inside can inherit (or ignore) the unit. This means at a top level you can set your font-size for each @media width, and then use relative units and it will inherit down. But that only works for very small websites, because it introduces subtle bugs as you incorporate more controls from people not aware of your particular practice.
I am not sure if you are joking but there is whole set of techniques called fluid typography that does this (using css math functions mainly clamp) https://fluidtypography.com/
It's not a silver bullet and many people simply don't prefer it to having a few breakpoints (that includes me too).
I use react native and react native web a lot and use dripsy for building design systems — it allows you to do exactly this. Define your breakpoints, and then pass an array of styles to a single style property. It’s really great
> As someone who has been handwriting HTML/CSS for literally 25-years, I'm still shocked dealing with media break points isn't easier.
I suspect its that every new project, you deviate, whether someone implements it differently, or someone else entirely implements it, and now you have to hack your way around the chosen path.
The one insane sounding approach I've seen is to just have a UI for one screen, and another ui for another. You hide one on mobile, the other on desktop.
There's so much nuance too, if you dont specify some meta tag your media breakpoints wont even work, which you'll forget when you start a new project after spending 6 years on an already built project.
I'm way behind in the loop these days, but isn't it just a tiny screen (phones) and then large (Tablets and Desktops) these days? Tablets (medium) sizes are now well-sized, so you should ideally be just building for that segment of 1024-1200px width!
That should reduce the media query worry to one single breakpoint, no?
> Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general design work.
I'm a former designer turned programmer, and I couldn't agree more. I was recently tasked with doing some mockup images (no official designer on the team), and at the end, I realized that I could do it so much faster with code.
Ironically, while I was putting the images together (I used Affinity Photo), I remember thinking to myself "Does this thing have some sort of scripting language?".
I still think a sketchpad and a pen is the best way to generate ideas. But, when it comes to mockups, good old HTML and CSS really can't be beat.
> I still think a sketchpad and a pen is the best way to generate ideas.
Couldn’t agree more. When I’m not working on a design that’s been passed to me by a designer I usually “design” on paper [0] and I still think it’s the fastest way to work through my ideas. I then jump from there straight to the browser.
But this is obviously an unsustainable workflow if you work in a team.
That's how I've always worked. I create everything in HTML and CSS and enhance the design iteratively, then I hook up the data fetched from the backend. It's way faster for me this way.
True and valuable design is timeless and smooth. It requires a lot of work and collaboration, which cannot be done using Figma.
To this day, the hidden elephant in the room for professional SaaS apps is breakpoints and the experience between them, including when and why to transition.
Figma supports the hyperactive single designer, not the ambitious industry designer who works on something that has stood the test of time for many years.
Apple has changed its UI twice since 2007, while Figma designers do it almost every day. I think there is a connection.
Great product leads understand that great design doesn't mean firing up Figma every day, but paradoxically doing the opposite. Consistency over time is a human condition.
I think the issue is that people started adding “pixel perfect” fidelity to mocks.
also anecdotal but having worked with UX people at a tech unicorn I think most of them are not that useful, and also don’t know that much. It got to a point where we (we built most of the foundational pieces of the business) just elected not to rely on our UX teams’ input too much.
I feel like it’s an essential job that most do really badly and in turn makes me think of the whole profession as a meme.
The best UX designer I worked with was a hybrid of a PM and SWE. He was amazing to work with. The dozen or so others I’ve worked with knew more about “dressing and looking like a designer” than actually designing.
I’ve not checked recently, but can you export an entire project retaining all interactions and run it offline like you would with a HTML based prototype?
At the time I was selling UX services, and the 'prototyping tools' of that generation were what drove me learn PHP, Ruby, and Javascript - for all the reasons you state. I was baffled by all the time and energy people spent becoming an expert in the prototyping tool rather than an expert in building for real. I declared these prototyping tools an expensive distraction and never looked back.
Agreed that in most cases all this extra work and attention to detail is essentially wasted effort that never sees the light of day.
But it’s possible to extract value from it if you have a culture where designers build prototypes, and you can use those prototypes for user testing, feedback, demos and pitches, while the code is being built. But it’s rare that companies have this culture.
Really good (and underdiscussed) point that Figma designs are not just for consumption by developers.
I know this is a cliche phrase, but when you're trying to align stakeholders (PM, manager, VP, dev lead) on a product, it is genuinely very useful to have really nice, hi-fi mockups to make sure everyone is talking about exactly the same stuff.
It's also definitely a scale thing. If you have 500 developers, it's probably worth putting in some extra sweat just to make sure they're all using the exact same button, etc
If you have 10 devs... yeah, hard to justify a super-perfectly-polished design system for every single bit of your frontend, IMO.
It would actually probably be pretty helpful if the designers knew their way around the production code, since they'd have a lot more context about what is going to be easy/hard to do. They won't be in some design vacuum.
Silo-ing off code because someone isn't a "software engineer" also feels kind of funny to me.
it would be useful if anyone in the company - CEO, salesman, designers, "X department" knew their way around the production code so your statement feels funny to me. look at sports - it would be awesome if everyone on the team is a great linebacker but ...
I think teammates would have enough context of each others’ positions that they could play the part if necessary, even if theyre not as good. They might even appreciate the skills gaps. So I think sports holds.
I know you're joking but I've worked in very engineering-heavy startups where this was the case and almost everyone had to write some code, production or not.
Hard counterdisagree here. To just have a blanket rule preventing "non-software engineers" from making production changes is completely arbitrary and suggests you may be lacking a rigorous process for determining which changes are actually important and ensuring they get proper review (no matter who made them). If you had a good process there's no reason anyone at all shouldn't be able to propose changes to production code.
What makes someone a software engineer in your scenario? I myself have worked as a software engineer for about 30 years at this point and have a degree and postgrad in Jazz, contemporary and popular music[1]. My work in software has encompassed writing software where making a mistake would have very significant real-world impacts[2].
I have worked with designers who are much more capable at making certain changes to production code than some titular software engineers.
Lots of changes to production code are not hard at all. I would go so far as to say the vast majority in fact.
[1] I can't play any more due to RSI which means I am now professionally qualified to explain to you why Steely Dan is the best pop band ever and harmonize things in 5 parts in the style of Duke Ellington and not much else.
[2] eg pricing, risk and decision-making with very large amounts of money on the line and even doing data analysis in regulatory and criminal investigations.
One day I will be part of my dream team where the UI designers and the FE developers are the same people. The amount of time my current team wastes on iterating on UI design, only to then do a second round of iteration on the actual developed product is insane. And then there are always massive inconsistencies in the designs, padding, margins, corner radii and so on are rarely consistent, and the developers ALWAYS point out these consistencies.
Just Do I Right the first time, and to that final round of UI refinement directly in the UI, as part of your development SDLC. It'll save so much time money.
Been a front-end designer since I started learning/my career (2007 lol) and sorta hate having to use Figma yet it's a lot like using Photoshop so it's not too bad. Yet I almost always just design/code in the browser using the "Inspect Element," tool (take my last design project, deconstruct it as needed and then copy and paste the code into an IDE; click refresh fairly often).
2. I work on AI at Figma, as well as on the design systems part of the product
3. Prior to Figma, I spent 7 years as a prototyper teaching designers how to go from idea->code without a design step in between
I love designing in code, and I HIGHLY recommend you do so for smaller projects, but I disagree with some of the assumptions the author is making. The author states, "The reason Figma has over 4 million users is because it takes most people too long to code their designs", which I feel is inaccurate. For less-experienced creators, it's mainly because the UX is more approachable in a design tool. That's less relevant here since the author is talking about designers who can code. For the most experienced designers, it's more about alignment.
As an example, most of my side project[1] was designed entirely in code... until it got to a certain scale. Designing in code was amazing early on when every page could be a new pattern. After a while, managing variations of components and ensuring that I wasn't diverging from existing patterns became non-trivial. Things became even harder when I hired another person to work on things. At that point, alignment became crucial. We needed to ensure that designs we were both working on were aligned with each other. Patterns one created needed to be reused, not reinvented by the other. This is something that's very hard to do in code. I ended up creating a mirror of the existing implementation of the site in Figma from scratch. For the iOS app, I ended up starting it in Figma[2] so we could easily compare implementations and land on an agreed pattern. Alignment with patterns and with the team was the #1 reason why we operated in a design tool during this time.
When you say that reusing patterns and components is very hard to do in code, do you mean this applies even when building a reference page in code, with your design system and all of your components?
> with your design system and all of your components
While this is straightforward to do, it doesn't encapsulate all of your patterns. No design system should. Design systems should capture the top 90% most-reused patterns, but there will always be patterns that live outside of that. Being able to visually see those, copy them, and tweak them in a context multiple team members can give feedback on is immensely valuable.
As someone who develops email templates, you will never understand my pain. Figma creates a complete fantasy world for designers who do not understand that a pixel and color perfect design is going to be smashed to bits by the client.
Also, I feel the rise of React is partially to blame. CSS frameworks were clunky and constraining - but they forced you into a lot of design constraints developed on years of best practices. I can't tell you the number of React-based enterprise tools I have to use on a daily basis that have picture-perfect designs ... that turn clunky and confusing the minute you resize the window or activate an animation.
Oh man, we have a certain email template at work, and the marketing team wanted to redesign that email; for some reason (broken communication, things out of the blue by company who bought ours, blabla), the designer thinks it's appropriate to just give us a Figma link that has no connection with the existing template or even any HTML. As a backend dev, I have no idea what to do with it. For an email, I'd expect something that someone actually made the HTML and sent the email to test it, like with hardcoded values that I could replace with variables, logic, etc, but I can't even understand how they think the Figma design was appropriate. They might as well have sent me a watercolor painting. I got them to export HTML, but it was completely useless since it's placing everything at specific pixel positions. I have no idea how to replicate the design in the email template. Anyway, I don't blame Figma or anything, just ugh, venting...
This is a situation where you can save a lot of pain by bringing in outside help. It's not too hard if you have experience and know the limitations. But there are a LOT of gotchas. Even a simple poor choice of words can get the email caught in a spam filter.
If you have to white-knuckle it, I strongly recommend a service like Litmus or Email on Acid. They will also provide good templates to start from and good instructional content.
It is algorithmic and it will try to match your Figma exactly using email specific HTML code as opposed to generative AI. Also it does not have any preconditions like Auto Layout. Just put your email in a Frame. Hopefully, it will at the least get you started. Would love to get your feedback.
> Figma creates a complete fantasy world for designers who do not understand that a pixel and color perfect design is going to be smashed to bits by the client.
Figma employee here. I'm curious if you see this as a mistake of the design tool itself, or if this is endemic to the constraints of html emails? Maybe phrased a better way, what would you like to see to help convey these constraints to designers?
Each client chooses how it represents html and css differently. And especially for things like dark mode, they can throw out your design entirely. So you generally stick with 20 year old design practices - lots of nesting tables - safe webfonts - flat designs etc. It's really hard to do any design work without an inbox preview tool like Litmus.
One specific feature that Figma really needs is an easier way to measure distances between elements. In email, you have to build whitespace using a lot of incongruous methods (line-height, breaks, cellpadding, etc). So the Figma padding information often doesn't work, and just having a simple way to draw a line between two elements and getting a measurement would be a real help.
There is a way to do this in Figma. While an element is selected, hold Alt and hover your cursor over any other element, and it will show the gap distance.
In my experience as a 13 years freelancer dev with a design background, the main issue I’ve experienced is that most designers don’t have a lick of dev knowledge and they don’t understand how easy or how complex is gonna be to code what they design. Or if it’s doable at all. Or how hard is gonna be to maintain a site designed the way they designed it. So it’s a matter of not having appropriate knowledge on the subject.
Having a dedicated "Email designer" mode where it takes into account all the limitations of email rendering would be amazing. For example, you can't use a flexbox which designers take for granted, so they end up creating things that result in monstrously complicated <table>s for emails.
How this would look/work in practice I truly have no idea, since you'd have to constrain them by removing some of those features, but then they don't really translate to regular markup/CSS 1:1 either.
My favorite factoid is that Windows desktop Outlook uses the MS Word engine to render emails. If regular emails are caveman html (which they are), then I don't know what that makes Outlook html.
Fun fact: A factoid is something that seems like it could be a fact but is in fact false. I know it's commonly misused as a synonym of "fact" and I don't really care, it's evolving as a word and that's fine. But I really enjoy the sentence "Fun fact: A factoid is something that seems like it could be a fact but is in fact false." so I can't help but share :D
This will come off as a humble brag, but I will say it anyway.
Right now, I am tasked with building a PoC for a new product my team wants to build by the end of the quarter. We have one big problem - we have no designer on staff. But we do have a design system with a library with re-usable react components and tailwind css, and those are things I am pretty good with. So I have full autonomy when it comes to turning product requirements into a live demo. I was able to accomplish quite a lot in a short period of time with no designer and just my own taste in design + ux. And product stakeholders were pretty satisfied, which means the outcome was productive.
So from my perspective, Figma is not only an awkward middle ground, but not even necessary for me.
My experience is that you should never code and design at the same time for non-trivial products.
When I'm doing design work, there is a product spec already defined but it almost always changes once initial designs are completed and people have a better understanding of how it would work in practice.
If you were to code and design at the same time you would inevitably writing some logic as well and this often turns into wasted effort.
Worrying about wasted effort spent breathing some life into a mockup/prototype
vs Worrying about creating some figmentary Figma imaginarium that wont translate well into the actual app
I do think there is a risk, it's just not of throwaway code (the effort of that throwaway is vastly smaller than what this path replaces). The risk is more how & where the future could be constrained. If the prototype starts becoming the app, there's some risk the prototype imposes poor app architecture. If the prototype starts becoming the app the effort to mock/prototype new ideas risks becomes higher.
I strongly agree with the parent about getting in there & trying things semi live, not being afraid to wade in. The component offerings are excellent today, don't wire most of them up, just throw them on the screen as best you can & put in minimal stitching or hardcode a forward/back through states.
The fear of this going bad is way outsized. The design industry needs to get where the puck is going & stop playing around with fancy abstract design tools.
I don't code and design at the same time because I've noticed from experience that it's slower and gives worse results than designing first and then coding.
The wasted effort is one factor to it but another factor may be that I'm able to just focus on design and ux more and not think about implementation.
> When I'm doing design work, there is a product spec already defined but it almost always changes once initial designs are completed and people have a better understanding of how it would work in practice.
In my case, I am just iterating on the fly with our end-user(s) (we also do not really have a product owner).
It may not have been obvious, but I am working on an app for internal stakeholders, not for external customers (the customers that my company serves).
So when it comes to designing for external end user + customers, design is serious and necessary consideration, which is where Figma would come in.
I used to teach at a UX grad program where students were required to learn both design and development. But doing both on the same project was almost always a mistake -- the designer has to deeply understand and advocate for the end-user's mental model while the developer has to deeply understand the technical model and constraints. Attempting to do both often end up conflating them or compromising on at least one of them.
Sort of like how many lawyers are skilled enough to handle either prosecution or defense but few do both on the same case.
I think there's a Nielsen/Norman article on this but can't find it at the moment.
I think it takes really senior designer/developer that can do both solo. Those people exists but still it's better to be responsible only for just one because it's tiring and demanding.
The best people added the other skill over time after they have been already excellent in main one (in my experience mostly designers learned to code rarely it goes other way). But teaching it from start side by side as equal seems like it would slow down the process. That doesn't mean i wouldn't want designers to learn to code from the start but just keep it simple at first.
Of the hundreds of my students and coworkers who had both design and development skills, only a few could fill both roles on the same project without compromising on either.
But when hiring I rarely bother reaching out to them. It's not just that being responsible for both is tiring or demanding, but a project team that dedicates one person to each role delivers faster than a team with one person wearing both hats. And given that people who can do both well at the same time on the same project are exceedingly rare, they typically earn high six figures (or comparable equity) so there's not much in the way of cost savings either.
Having said that, maybe it'd be worth it for a founder or an early employee where there is a strong pressure to maintain a low headcount?
On the other hand someone who can do both code and design has huge advantage of knowing where to cut corners, how to use platform features effectively and thus higher chance to make robust solution. But you need to have envinroment that allows this.
I think in the future product designers will shift into two factions. Live code generation and design system development. Design systems will be the backbone of any quality AI interface generation system. How we build those design systems will be the interesting part. Will most people unify around material/carbon or will they invest in house teams to ensure their UX doesn't fall behind the competition?
This has always been the case. Zero to one with a single developer or a very small team is the most exciting part of the lifecycle of a project. Medium to large size companies have very different challenges.
Figma is alright, if you use it right. The issue is that people are trying to create pixel perfect graphics designs in it, which is very fiddly and then has to be replicated in code.
So, you end up doing double work. An additional problem is that especially responsive applications with e.g. dark mode support, animations and css transitions, etc. can only be partially modeled in a pixel perfect way in Figma. You can do it but it's just very fiddly to do in Figma. And besides Figma's code export is useless for this; aligning design and implementation is mostly still manual work. And of course users only ever use the code version.
The proper way to use Figma is to focus less on the look and feel and instead use it to prototype UX flows. This is tedious and slow to prototype in code and this is where Figma can shine. Having a good component design system in Figma means that you just reuse the same components and don't have to waste brain cycles on their look and feel when designing a UX flow. It will roughly look like the real thing and you can click together a few new screens in minutes and compare a few alternatives. I work with good UX people and I see them use Figma effectively. Our designs aren't pixel perfect; generally. Though we do use it for e.g. icon design in svg form as well. But design and UX are two separate skills at this point with separate tool sets as well. Figma is alright for icon design but probably not the best tool.
This is of course not a new problem. People were designing web applications in Photoshop at the beginning of the century. UX was not a consideration and the people doing the design were graphics designers. Figma is arguably better but not necessarily aimed at graphics designers. It's a UX tool.
Many of the people in this thread are talking about designing web-sites. But I did work on mobile, specifically Android for the past decade.
It's amazing to me how many designers have always just designed for iOS, which just had a few form factors (1 or 2 iPhone sizes (more now) and 1 iPad size) -- I could never get them to design "responsive" like for Android's various form factors (device sizes + different resolutions).
Creating pixel-perfect designs that aren't flexible has always been the issue.
I was involved in a few projects back in the glory JSF days, where the customers expected pixel perfect Web UIs, like they had been doing for years with Win32 and Motif.
Slightly off-topic, but I dislike this trend of "designers over-designing everything". This website is aesthetically pleasing, and has it's own unique style, but scrolling the home-page is laggy on my $4,000 Macbook (Chrome). I guess it's because it downloads 14MB of resources and tries to download more based on scroll position?
The website is made in framer (https://www.framer.com/) no code tool. If you look at Framer homepage it's also laggy to me on my macbook. It's worst on FF. I don't think its the scroll effects but many blurs/shadows - they seem to be less performant in FF than in Blink and since everybody test these in chrome... you got this outcome.
When is the last time you restarted your mac? I had this guy complain to me, everything is laggy and chrome is slow (memory leaks?). A simple restart fixed everything. Clear your chrome cache/etc. Disable all extensions you dont use and try again.
I think the assumption here is that once you make a component library in code, you can just map low-fidelity wireframe components (from something like Balsamiq) onto those "real" components, and go from a napkin sketch to a functioning website without the awkward middle ground of vector designs and clickable slideshow prototypes.
It's an interesting idea. I'm skeptical that, in the real world, you can reliably infer everything you need to produce code from a simple wireframe: how do you deal with specific interactions, specific data, specific operations on that data? Balsamiq-style mockups are all about not getting specific, in order to keep the fidelity low and the velocity high.
In practice, with Figma, the thing I've noticed is that I use low-fidelity wireframes less than in the past, because it's just as easy and fast to use high-fidelity components from my design library. If I'm just stacking Lego blocks together to make a UI, why would I use low-fidelity blocks, if I already have high-fidelity blocks that are much less ambiguous?
In other words, I'm not sure Figma is in the middle ground between sketches and code anymore, I think it's just as easy to think of it as a brainstorming tool that happens to produce high-fidelity results if you use it right.
my problem with Figma is that it became too technical and code-like. By the time I finish setting up layouts, paddings etc...I'm catching myself thinking - why didn't I just code it straight up, could have been as fast.
> But you know what AI will be great at?
> ...Turning wireframes into frontend code (limited logic)
> ...Wielding (and extrapolating) your design system
> ...Creating beautiful visuals from screenshots and mood boards
I don't think the argument works. It imagines AI will be able to do things that our current AI do not.
Our current AI work in terms of what they've been trained on. Natural language to code works as well as it does because coders have been asking and answering questions about code a lot on the internet, that's been collected into data sets, and those data sets have been used to train LLMs.
For AIs that work like our current ones to be great at the things the author envisions, they will need a lot of examples of those things, and of a high quality too.
The author wants AI to turn natural language into wire frames, let the designer adjust and improve the wireframe, and then turn the improved wireframe into production code.
But I don't think the training data for those two transformations exist. What even is the intermediate wireframe format? AU will produce and consume it, but it also needs to be in a form human designers can iterate on.
Since the training data doesn't exist, it would need to be created. Is that feasible? If you can't harvest the internet for it for almost nothing, it would cost a great deal to create, and I wonder about the quality of the result.
Frankly, I am not even sure what "frontend code" means in this context. What stack? How is state managed? How is this code integrated into the larger production system? If by "frontend code" they mean fairly clean React code - that's just a small subset of what is actually needed for production.
As a programmer, I find that much more than a wireframe guide is distracting. That said, I tend to have a good understanding of the UX rules for a given design style (often material) and the ui library/tools I'm using. Sometimes I might have questions about the interaction.
On the flip side, I've seen developers that just about need a functional example to work out anything and will still have issues with real functionality. So YMMV.
How shitty is Figma’s current “export as css/html/js” functionality? How many people do you think they have working on improving that? How many of the people Figma is paying to fool around with AI do you think are experimenting with building an AI stuffed full of css/html/js tokens, and other functionality for improving Figma’s ability to pick up working css/html/js, tweak it, and re-export it?
I don't know if these are supposed to be leading questions, or questions combined with assuming an answer to make a point, but tl;dr code export is good.
I genuinely have no idea whether Figma's current code export is any better than FrontPage or Dreamweaver. I do web design stuff about once every four or five years and it mostly involves me firing up TextMate to edit Wordpress themes.
I've been working as a product designer for the last 10 years, but for a few years before that I was a software engineer. I've been interested in moving back towards the technical side of things. It seems that role, and what is described in this article, would often be called a "design engineer".
However, I don't quite understand what the role of a design engineer is. If a PM is the "what", design is the "how", and eng is the implementation. Where would a design engineer fall? I'm sure it is very much a spectrum, but I'd be interested in hearing from some folks who have filled this role.
Are you focused on the "how", but using code to achieve that? Are you focus on the "how" and it simply turns into the implementation? Are you focused on the implementation, but with the background and skills of a designer?
Figma is a tool and nothing more, despite some people to turn it into the end all be all of user experience. It will eventually be replaced with something, just as it replaced Sketch, and just like Sketch replaced Illustrator. I also noticed that the author barely touches on the people who make the interfaces (product designers). If the author gets their wish, businesses won't hesitate to axe their UX teams to save some costs.
Disclaimer: I'm a product designer who is very skeptical of the enthusiasm around AI as I can see a future where product will instead rely on AI instead of designers to create interfaces.
author here I'm also a product designer! I'm skeptical of the current approach to AI-generated interfaces. But am a big believer that AI will fundamentally change the way we design products.
My high-level hypothesis is that in the same way browser-based design (Figma) displaced Sketch... code-based design will displace Figma. It will start with the longtail and smaller teams. Figma has a stranglehold on enterprise. But I refuse to believe I will be making vector pictures of products in the longrun. It will feel as easy to design interfaces in code. The article is an attempt at discouraging text-based prompting in that world though. I'd much rather have a modern sketching/wireframing tool connected to my code base and design system.
Getting designers willing to setup their workstation to hand code a React app with dozens of dependencies and be constrained by the DOM is not going to go very well. And then doing it all over again with several other web libraries/languages. This is not even design, it's a developer role who just happens to paint UI with code.
One thing I kinda wished was the ability to code into Figma, much like how in Storybook I can have a resource of brand compliant components. For me, it's much easier to rectangle draw and even work with auto-layout, but one side of me just wants an environment where I can define my Figma components with code and just drag 'em around.
That type of middle ground to me, isn't awkward because usually before I want to implement, I am trying to increase the velocity of me trying to play around with ideas before doing raw implementation. ...but that's just me.
I find Figma useful for quick ideation on small projects to see potential constraints and challenge assumptions. The lower-fi, the better. I only do mobile-design to focus on essentials, use grayscale colors to not be distracted, and don't make a mobile global navigation.
If it was a larger project though, I'd definitely consider sketching as the speed is so much faster. And then jump into code.
I can see authors point when it comes to smaller website or app. I work on enterprise products that are rather complex with large surface area. Despite being a pretty good coder (or at least used to be), I wouldn't attempt to iterate on changes directly in the code and link all the flows etc. It would take much longer and I'd lose ability to make rapid changes.
Figma could adapt by making something that actually produces code well too? Although it would add a lot of complexity and designers might not like having to make different versions for different platforms, like the 'android', 'ios', 'flutter', 'web', etc. There are tools like judo.app that make 1:1 native SwiftUI designs.
my push back on this is that unless you have a pretty robust visual design system the outputs are going to be incredibly unoriginal. Yes it will make solving UX problems faster but at the cost of visual differentiation. There is always going to be a place for high fidelity exploration for styling innovation and brand identity.
it's a good push back. I do think this assumes some (small) design language to extrapolate. But that's also something that will become borderline free in an AI world so I think it's a safe assumption.
What's more interesting that doesn't exist yet is the ability to create more compelling visual languages/systems based on inspiration screenshots. That's a big unlock IMO. Everything right now is very generic.
Interesting thread, because last week I was tinkering with an idea I had built out ( AI assistant for browser-based UI development), and I was worried that there was no point because Figma will inevitably do the same, and they'd dwarf the raw HTML/CSS/JS designers. Maybe not?
Figma is for people to share and collaborate between team members. Especially between designers and devs, but devs at my company use it directly as well. You get something picture perfect that others can comment on or tweak. You can update it easily. Try out different colors or images or icons rapidly. You then also have visual documentation that can be sent to business people or partners.
If it’s just you, you don’t strictly need it. Personally though, I find it really useful precise because I’m not a great designer. I can fiddle around with sizes and layouts in figma until I get it the way I want it, then I turn that into code. I could jump straight from scribble to code, but having that middle step where I can exercise the idea without screwing with components or css feels nice.
Empowered with chatGPT (now claude), my partner as a designer pulls off extremely workable implementations of all different ideas without much need for sketching in a non-functional design tool.
When she does draft in design tools it’s usually more graphic in nature (branding etc).
There's this, which is more "will we fire all the designers?" (No), and there's the other massive problem: they were a nice, simple, web-native thing that was easily positioned to displace Photoshop and Sketch.app.
They never really successfully landed things that we used to call "major version bumps" and it's devolved into quite a mess. Not anywhere near Photoshop-level, but...it's a strange situation to me because you could build a successful business based on the premise of "that, but only 60% of it, with 5% of the headcount"
As a mobile engineer, I do not have the visual & product skills that designers have. They can create something visually appealing and aligned much faster than I can and have all sorts of skill sets that take a while to hone. I might have more taste than the typical backend engineer, but it doesn't really translate to visual skills to the level of most designers.
Note: Professionally I do practically nothing with the frontend of web development, so my experience may be far from normal, but when I do have to do something frontend related for personal work or the rare work-related task, I prefer a very rough wireframe using something like https://excalidraw.com/
I think Figma is fairly interested in lofi mockups too thus Figjam.
Their components aren’t code exactly but I think that’s because they will ultimately directly output / sync full components to a variety of platforms from their abstracted representation.
Or Figma becomes the IDE? Not the direction I like (I like coding), but it kinda makes sense (for Business People?) to have "Export As Final App" in Figma.
framer makes a few steps up from figma and that's why I design/prototype straight in framer these days: you get all the wysiwyg of figma and infinite canvas while supporting breakpoints and publishing to the web for testing
i'm working on build the 'missing tool' ridd mentioned, a tool that blurs the line between design and front-end. if you're interested in learning more hit me up at ahmed@designwithfalcon.com :)
The future is Miro. I've noticed that I can create mockups out of boxes more quickly than drawing something with pen and paper, then putting tons of notes and arrows, then just implementing it.
I honestly cannot understand the hype around figma. it's such a weak product. it's laggy, the interface is not fantastic and it isn't even able to convert the proposed interfaces to code?
why would I want to use figma when I could use a non-laggy product that can convert my designs to code?
If you work on a big team, collaboration is everything. Figma enables collaboration in a way that very few other tools allow. SOTA before Figma was sketch files in dropbox or emailing them back and forth.
A lot of commenters here are lamenting the practicality of modern design culture (which is often centered around figma) for smaller teams / earlier projects where collaboration may not be as much the bottleneck. The tool itself is still very useful for small team collaboration though, and for folks thinking through ideas without having to code them up.
Figma also pioneered putting complex tools into the browser. Today people take multiplayer and 60fps canvas for granted but Figma basically created the space. It was a humongous technical achievement and continues to be a very difficult thing to copy, though folks are obviously trying (e.g. Penpot).
AI conversion of components to code is WIP for all toolmakers but obviously on the roadmap. Another hard problem you're kind of trivializing here.
> why would I want to use figma when I could use a non-laggy product that can convert my designs to code?
Figma passed on my resume, so I’m not particularly incentivized to leverage my (very deep, thank you) engineering / design / UX expertise and offer my product guidance for free. They have a ton of momentum, so there’s a lot of room to make mistakes before it shows up as more than a blip in the quarterly numbers. They’ll probably be fine without me, but seems like an unnecessary risk. ;)
I'm a designer. I built brainglue.ai without Figma, a design system, or a UI library. I just went directly to code (react+tailwind) and let a style organically emerge.
I'm not saying that I'm a unicorn and that my idea-to-code-to-design execution is flawless, but I certainly believe that in this situation, if I hadn't done it this way, I wouldn't have done it all. However, doing this would be wasteful or dumb in almost every other situation that requires my design output.
People pay for Figma precisely because it's a middle ground. It was a middle ground before, and it will continue to be unless something fundamental changes.
Small suggestion, I would preload the contents of each tab and the images in the circle after the main content is loaded. There was a good two second lag loading the images here in Australia.
I'm one of these codey designers. The madness that exists in modern design teams (I used to manage a team of 50!) is insane. There's a lot of time spent on "design systems" in Figma. Very generally Figma is not the website, and the effeciency additions of building tools there is a lost cause.
Modern CSS and your JS frontend of choice is a lot quicker and more powerful for component building and general design work. There's way too much to do with media break points and tokenization there. There's a misguided group of designers that are learning a lot of esoteric Figma features that don't translate into something users will ever touch.
10 and 15 years ago designers needed to learn the code part too. Somewhere along the way we put them in a corner and made learn these prototype tools.