Will Figma become an awkward middle ground?
dive.club
dive.club
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.
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.
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)
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...
Edit: Though even simpler than that is the width media query, which I think you might be looking for: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/widt...
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.
Though maybe I use it incorrectly.
I'm always open to learning something new :)
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.
https://stackoverflow.com/questions/40722882/css-native-vari...
https://www.w3.org/TR/mediaqueries-5/#at-ruledef-custom-medi...
<div className="text-sm lg:text-lg"> Hello World </div>
I don't know how resizing defaults would work well for most cases instead of specifying what you want.
font-size: clamp(3.125rem, 3.464vw + 2.229rem, 5rem);
It’s not obvious how to increase/decrease the font size at a later date.
It generates step size variables and a comment linking back to the web calculator filled with your values.
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.
text=[1.2em] md:text=[1.0em] lg:text=[0.8em]That should reduce the media query worry to one single breakpoint, no?
text-sm md:text-base lg:text-lg
Mobile: font-size: 0.875rem; /* 14px / line-height: 1.25rem; / 20px /
Tablet: font-size: 1rem; / 16px / line-height: 1.5rem; / 24px /
Desktop: font-size: 1.125rem; / 18px / line-height: 1.75rem; / 28px */
<div class="sm:text-lg lg:text-sm" />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.
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.
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.
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.
They are canvas based clickable mock-ups with fancy transitions and a few more things.
But it can’t generate / export to HTML which comes in handy when you need to use it offline.
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.
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.
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.
I don't want non software engineers touching production code. It's too hard, and the depth of skillset for a product/UX designer is already huge.
If you find css and js faster for prototyping and mockups, then sure. I'm doubtful and still yet to see that work in the wild.
Silo-ing off code because someone isn't a "software engineer" also feels kind of funny to me.
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.
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.
1. I work for Figma
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.
[1] https://non.io
[2] https://www.figma.com/design/im8a7L7axmbj0S0lm27NKa/Nonio-iO...
> 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.
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.
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.
https://www.figma.com/community/plugin/1305869752760258922/k...
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.
Disclaimer: I work here.
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.
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.
How is this react related? You could always write crappy css. A team creating non responsive react apps would not create responsive non-react apps
You can copy+paste anything from any Office product and it will render in your email. It also makes doing mail merges much simpler.
So as a corporate email tool it's a smart idea. Making it harder for advertisers to design fancy emails is just an added perk.
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.
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.
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.
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.
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.
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.
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?
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.
What a fun it was. /s
If it does not, try another browser.
:D
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.
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.
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.
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?
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.
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.
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.
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.
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.
When she does draft in design tools it’s usually more graphic in nature (branding etc).
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"
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.
Well, that’s because they can code.
For the rest of designers, or designers working in a team. Figma will remain where it is
why would I want to use figma when I could use a non-laggy product that can convert my designs to code?
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?
Can you list some examples?
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.