> 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 1634 days ago [-]
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 1633 days ago [-]
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 1633 days ago [-]
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 1633 days ago [-]
> 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 1633 days 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.
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 1633 days 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 1633 days ago [-]
Exactly. We need an elegant interface between design and development that effectively hides each teams implementation details.
jdelafargue 1634 days ago [-]
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 1634 days ago [-]
was this something that Framer [0] was attempting to address?
Super cool guys. Congrats on the launch. You're touching on a big pain. Will most definitely give it a try within our upcoming re-design of our app. [1]
By the way, if you're a remote team, I'm happy to talk with you guys and get in touch [2], love what you built. Sick landing page.
Thanks! Standups looks great but we're currently non-remote :)
jpincheira 1633 days ago [-]
Thanks Jerome. And sure, no worries. I thought you’d probably had a few people working remotely apart from the office :)
Digg_mov 1633 days ago [-]
super cool guys its weer
gatherhunterer 1633 days ago [-]
It irks me when a page’s minimum width is wider than my phone’s screen. I am still using an iPhone SE (I just did a warranty trade-in for a brand new one and I have no intention of “upgrading” soon) and these pages feel under-designed. The “floating” feel that comes from the page sliding back and forth as I scroll is not quite as bad as when the content is chopped off (e.g. elm-lang.org). The iPhone 5/SE dimensions are still available in responsive mode (at least for Firefox) so it seems like a choice to omit this use case from the design consideration.
option_greek 1634 days ago [-]
Confluence sucks for requirements, design capture even for software development but alternatives that are focused purely on design are rare. You should try and expand into design capture for SW development as well.
jdelafargue 1634 days ago [-]
As in front-end engineering? Or software _architecture_ design? If you mean front-end then this is already something we enable as we have integrations with front-end coding tools like Storybook and have plans to build on that :)
option_greek 1634 days ago [-]
Meant software _architecture_ design :) Usually no one builds frontends in isolation. So will be good to have something e2e in one place.
jdelafargue 1634 days ago [-]
Got it, thanks for clarifying!
mattmarcus 1634 days ago [-]
We've been using zeroheight at Modern Treasury and are big fans thus far. It's clearly built for design versus other platforms we considered, and was way easier than building something ourselves.
jdelafargue 1634 days ago [-]
Thanks for your support! :)
omarchowdhury 1634 days ago [-]
My first question was to ask if we could style the design guide itself to our design system, and of course you make that possible under 'Styleguide settings'. Fantastic, looking forward to using it! Congratulations on your launch.
jdelafargue 1633 days ago [-]
Cheers Omar! Looking forward to your feedback :)
cflyingdutchman 1634 days ago [-]
When I read "design docs that stay up-to-date" I thought you meant system architecture docs that integrate with AWS, Azure, GCP, DBs, etc. I hope someone builds that.
jdelafargue 1633 days ago [-]
That does sound useful! Yeah I now realise the title is ambiguous :S
cflyingdutchman 1634 days ago [-]
maybe Lucid will
onion2k 1634 days ago [-]
That's really nice. Well done.
jdelafargue 1634 days ago [-]
Thank you :)
graphene 1633 days ago [-]
So cool to see you guys go from strength to strength since the old days in our EF cohort!
Onwards and upwards!
jdelafargue 1633 days ago [-]
<3 Hope all is well with you!
DrScump 1633 days ago [-]
in London
Will you be needing "boots on the ground" in SV later?
jdelafargue 1633 days ago [-]
Maybe :) TBD!
unlinked_dll 1634 days ago [-]
This is a pet peeve of mine, but I really hate when products like this don't affix a prefix to their tool description.
As in this isn't a "design" tool. It's a "front end" design tool or "UI/UX" design tool.
I may be flamed for this opinion, but seriously, stop referring to GUI/front-end design as just "design." There are a lot of people that are designing different things and it sucks when we search for new tooling and only get the next GUI tool.
Like when I read your title, my first instinct was that it was a CAD/EDA tool.
edit: <\gripe> this is a really cool product idea and clean implementation from the looks of it. imho quality/easy docs are the difference between loving a job and burnout!
jdelafargue 1634 days ago [-]
I agree with you and to be honest this is something we get picked up on often when talking to people outside the (UX) design world... we're just so used to people using the term like that in our space that we forget!
> imho quality/easy docs are the difference between loving a job and burnout!
That's a great quote :)
chatmasta 1634 days ago [-]
FWIW, in the title I parsed "design" as a verb, so I thought it was something like readme.io for more general documentation.
Cool product!
jdelafargue 1634 days ago [-]
Thanks for the feedback! Really helpful
Digg_mov 1633 days ago [-]
wow!!!!!!!!!
Rendered at 07:37:36 GMT+0000 (Coordinated Universal Time) with Vercel.
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?
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.
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.
- 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.
+1
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.
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.
[0]: https://www.framer.com/
By the way, if you're a remote team, I'm happy to talk with you guys and get in touch [2], love what you built. Sick landing page.
[1] https://standups.io
[2] jp at standups.io
Onwards and upwards!
As in this isn't a "design" tool. It's a "front end" design tool or "UI/UX" design tool.
I may be flamed for this opinion, but seriously, stop referring to GUI/front-end design as just "design." There are a lot of people that are designing different things and it sucks when we search for new tooling and only get the next GUI tool.
Like when I read your title, my first instinct was that it was a CAD/EDA tool.
edit: <\gripe> this is a really cool product idea and clean implementation from the looks of it. imho quality/easy docs are the difference between loving a job and burnout!
> imho quality/easy docs are the difference between loving a job and burnout!
That's a great quote :)
Cool product!