[methyl]

> 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?

[tenaciousDaniel]

There'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]

I 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.

[ProfessorLayton]

It’s worth noting that Design is a pretty broad term, and not a jpg department. There are various subsets of designers such as:

- UX Designer: How it functions

- Visual Designers: How it looks

- Interaction Designers: How it behaves

- Product Designers: Hybrid UX Designer, but with a focus on company goals, similar to a Product Manager.

Of course hyper specialization isn’t necessary in tiny startups, but it is for larger orgs. Similar to engineering, it isn’t necessarily feasible nor reasonable to have one person be an expert in every domain.

And if you do know someone who knows everything, they’ll also know they’re a unicorn and charge accordingly.

I do agree that familiarity with the tech stack is very useful, but beyond that I’d argue its best to let those focus on what they do best.

[jdelafargue]

> I do agree that familiarity with the tech stack is very useful, but beyond that I’d argue its best to let those focus on what they do best.

+1

[tenaciousDaniel]

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.

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]

> 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]

Exactly. We need an elegant interface between design and development that effectively hides each teams implementation details.

[jdelafargue]

Yep 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]

was this something that Framer [0] was attempting to address?

[0]: https://www.framer.com/

[jdelafargue]

Not sure about Framer but I know of https://flawlessapp.io/ that does this for iOS