4 ms·
> designs and front-end code can live side-by-side in the docs This one sparked an idea. We all know that it's really hard to automatically convert designs to
by methyl 7y ago
> designs and front-end code can live side-by-side in the docs
This one sparked an idea. We all know that it's really hard to automatically convert designs to code (eg. React components). Right now the only feasible way is to code it manually.
If you are able to import and show designs side by side with real React components using Storybook, would it make sense for you to tackle diff-checking between those two, making sure the design is coded correctly?
- jdelafargue 7y agoYep that's actually something we want to do in the future: giving design/front-end better continuous integration/testing tools such as diff-checking and visual regression testing
- crtlaltdel 7y agowas this something that Framer [0] was attempting to address? [0]: https://www.framer.com/ https://www.framer.com/
- jdelafargue 7y agoNot sure about Framer but I know of https://flawlessapp.io/ https://flawlessapp.io/ that does this for iOS
- tenaciousDaniel 7y agoThere's a Hard Problem here, and it's that in order for this to work, there has to be 100% parity between the component breakdown on the design side, and on the development side. In theory this doesn't sound too bad, but in reality, it's very difficult to know exactly which bits of the UI are going to become a component in code, before implementation. Therefore, there's a very high likelihood that the visual components coming from design are not going to cleanly align with the implemented components in Storybook.
- jlukic 7y agoI think there’s a general issue with design at startups— the actual products of most design departments are “jpgs”, and so most professional designers are really professional jpgers. This means designers are part of an upfront handoff process and not active participants in feature development. I think the only recourse is to hire designers who understand how to interact with a UI component framework in code, and have design be a code stubbing process not a jpg producing process. This does require for your design department to be built upfront to handle this kind of process, good luck trying to retrofit existing design departments codified around “jpg handoffs” to work with an implementation level source of truth.
- tenaciousDaniel 7y agoI'm actually building a tool right now that aims to solve this problem. I partially agree with your statement. Yes, designers need to learn how to interact with a UI component, but I don't think they should go so far as coding. Code necessarily involves implementation details that are not relevant to designers. Also, there are so many different platforms for UI code that it's not a realistic goal, unless designers are willing to constrain themselves to one platform. My view is that a truly modern UI design tool will allow designers to express the "visual logic" of the application. The output/handoff would essentially be a set of visual specs that are platform agnostic.
- jdelafargue 7y ago> I'm actually building a tool right now that aims to solve this problem. I partially agree with your statement. Yes, designers need to learn how to interact with a UI component, but I don't think they should go so far as coding. I agree with this. UX design and programming are skillsets that are sufficiently complex/different that the key is to allow each discipline to have the tools to _understand_ and interact with the other really well, but not to expect all designers to become programmers or vice-versa.
- tenaciousDaniel 7y ago