Chris Strahl’s Post

View profile for Chris Strahl, graphic

Chief Executive Officer at Knapsack • Design Once, Build Once, Use Everywhere

Like many the folks at Knapsack, I was pretty excited to see what Figma was going to announce today regarding design systems connectivity. There is a lot to be stoked about with typography, component metadata, etc. and a lot of great moments (I'm not just talking about the elevator music that was🔥) However, I keep wondering how much engineers (and their managers) are going to be willing to commit to including and maintaining extra code in their repository to be able to them see it presented back to them in Figma. It is an odd cycle. Take a design of a component from Figma, build some code, add specific code to allow you to connect it back to Figma... all to see the thing you built in Figma? This feels like swimming upstream? (obligatory salmon pic attached) Wouldn't it make more sense to just gather data from Figma and put it in the place developers already work? Would love to understand what you all make of this, especially dev voices.

  • No alternative text description for this image
Kevin Muldoon

Design Systems @ Dow Jones | Technologist, writer, speaker, and creator of genomecolor.space

3mo

I am confused with what Figma presented today @Framework 2024, which feels weird given all the excitement. I write Figma Plugins, customize Style Dictionary, and create custom apps to support our DS, but I'm not grokking these updates or what problem they are trying to solve. Furthermore, I do not appreciate Figma not fully supporting Typography variables, leaving us to support both Styles and Variables which I was hoping to avoid.

I can think of a world where Figma is working towards bringing both parties (design and dev) in a single tool. I am not sure if they work towards that strategy as they bring more code in Figma and they've been focusing on these features. Also I don't think it's possible to fully move the developer out of their world. Perhaps this becomes more catered to that UX engineering role since it's what the industry is seeking lately.

Dan Hiester

Product Designer | Design Engineer | UX Strategist

3mo

The code samples I saw reminded me a little bit of some of the code I’ve written for Storybook stories. The timing of this is funny, because I was just telling someone over the weekend that I think Storybook was conceptually influenced by React Sketch.app, an open source project by Airbnb that imported React components into Sketch, taking advantage of React’s ability to have different renderers (ReactDOM, ReactNative, etc). Based on Figma’s recent acquisition of a no-code app builder, I’m personally speculating that they’re preparing to take their prototyping features to a whole new level. They may try to even make development happen directly in Figma—but if they try that, my guess is they’re more likely to be adopted as a prototyping tool in practice. It’s too early to say how any of this will turn out. But it’s going to be interesting to keep an eye on!

Jonathan Taylor

Strategic Partnerships @ Figma

3mo

Hey Chris! What are your thoughts on the VSCode integration that Figma / Dev Mode has? Would that address what you are thinking about here, bringing Figma / Design to where Developers are already working? https://www.youtube.com/live/xAipdCNtvR8?si=VSpRhJe_etmjhBVd&t=581

Marc Obieglo

UI & Design System Principal ø Design System Mentor

3mo

I can see _some_ value for it in the context of a traditional designer-developer handoff scenario in product/feature teams where there is a time when both disciplines collaborate in a Figma file. It could make life a tad more convenient for an engineer, being able to quickly copy & paste code snippets while having the actual spec open and not having to go back & forth between Figma and DS docs. But i also think that’s where its value ends, adding on to that the expensive paywall for dev mode, effort required to maintain more code, more process/workflow management…

Josh Harwood

Design Technologist, Design Systems

3mo

Lots of additional training/expectation of Figma knowledge for developers, understand there is often a gap, now it's a bigger gap

Yeah, that was what I was thinking about the Code Connect feature: it is SO cool for UX design-minded engineers but how many of them(well, us) are there amongst engineers who are implementing Design System components? And what are engineers who are less design-focused going to actually end up referencing?

Lee Nelson

Founder & builder at 2Fold

3mo

It's an odd paradigm, releasing dev features to a bunch of designers. I don't see the adoption being worth the effort right now. I do like that they acknowledged dev mode was previously most useful for writing new code and that they want to improve upon that. When it first came out, I didn't see it connecting any bridges at all. To me it felt like it was designed for agencies focusing on building views and pages instead of components.

Stephen James

Accessibility & Inclusive UX Leader, Design Systems @ Salesforce

2mo

I haven't seen the product being introduced. What do you mean by "Wouldn't it make more sense to just gather data from Figma and put it in the place developers already work?" Many products have pursued designing with coded components--UXPin Merge and Framer come to mind. Historically, Figma is an excellent UI to make "styled div tags." Unless Figma "components" are mapped to existing semantic and ARIA widgets, engineers will mostly use Figma for visual styles (design tokens or CSS rulesets). If the goal of this recent Figma work is to sync design and coded components, I believe it's much easier to convert coded combobox elements into "static div" that can be used by UX designers in Figma than it is to export Figma without semantic tags. However, this could change as browser widgets get more semantic and interaction patterns get more baked-in such as with `dialog`.

Like
Reply
Matias Peinado Greco

Lead Product Designer, Design Systems

3mo

Classic answer: It depends. I’d argue it has pros and cons… ⚖️ If you are a Consumer engineer, and are looking into a ready to dev design, you are interested in knowing which available asset you should pick in the component library to develop that fearure in parity with design. However, rhe connected code it has less value to a DS engineer that will build the component. It will generate a bit more of maintenance effort in favour of users experience, but well, it is what it is when you are building a product, you make the best you can to make your user’s life easier. In the end, it will always depend on how you use Figma for building and maintaining systems and how your users consume your assets from Figma when designing and implementing fetures using your DS.

Like
Reply
See more comments

To view or add a comment, sign in

Explore topics