| Hi HN! We’re Jerome and Robin, the founders of zeroheight (https://zeroheight.com/). zeroheight is an online editor that lets companies create a wiki site to document their design process. The documentation is integrated with their design tools so that it’s always up-to-date, which enables large design and development teams to stay on the same page, ship faster and deliver consistent user experiences. Documentation is the first piece of the puzzle – our vision is to enable any company in the world to have a "design system": a system of reusable UX and front-end components, tools and guidelines. We want companies that don’t have the resources of design giants like Salesforce, IBM and Shopify to be able to create design systems which are just as powerful e.g. https://www.lightningdesignsystem.com (Salesforce), https://www.carbondesignsystem.com (IBM), https://polaris.shopify.com (Shopify) Our startup journey started 4 years ago at a YC Startup School event in London – it was the final push of inspiration we needed to make the jump and quit our Big Finance Co programming jobs :) We joined Entrepreneur First (a pre-seed incubator) with a list of startup ideas (including some really bad ones!) and spent most of our time emailing people and going for coffees. For two coders who were excited to code and build a product, this was a tough reality check of what starting a startup can be like in the beginning! At the time, one problem that really resonated with people was that the design-development handoff process was pretty painful. This was something we had experienced at work: designers sending manually annotated PDF specs and PNG assets as email attachments etc. We thought it was an exciting space, so we went ahead and built a design-development handoff tool. The problem was that there were already some great products in the space that had a head start – such as Zeplin (YC S15) :) – so despite gaining some customer traction, it wasn't enough for us to raise money. This led us to go back to basics: talk to users... So we went for coffee with our customers to figure out what other problems we could solve in the space and built the following series of insights: - Good design is now the default, most products need a great user experience to compete - Because of this, companies are spending a lot more resources on design/UX and growing their design teams rapidly - In order to be able to collaborate at scale, design teams have started adopting a component-based workflow – similar to how engineers have worked for years - But breaking designs down into components is not enough. In order to successfully collaborate at scale, designers and front-end coders need written documentation on _how_ to use the components. The design components are the lego bricks and the design documentation is the much needed lego instruction manual. So what’s the problem? We dug deeper and found that there are two hurdles that tend to prevent companies from creating successful documentation for their design system. 1. Companies that _do_ have the front-end engineering resources to build custom design documentation in-house (or leverage a tool like Storybook) often end up with engineer-driven documentation that is up-to-date with production code, but is hard for non-technical designers to contribute to. This leads those designers to create their own, separate documentation, which in turn causes fragmentation between design and development teams — one of the problems that having a design system is trying to combat in the first place! 2. Companies that _don't_ have the spare front-end engineering resources to build custom docs use tools like Confluence, Google Docs, Notion etc. but these types of wiki tools aren't built for purpose and the documentation can easily end up out of sync with the latest designs and code Based on this we built a minimal yet powerful editor (in the spirit of Dropbox Paper or Notion) that makes it very easy for anyone to document their reusable UX components, tools and guidelines (their “design system”). The editor is integrated with both design and development tools so that the docs stay up-to-date. On the design side we provide Sketch, Figma and Adobe XD plugins to sync UX components and styles. Designers can update the designs inside the docs at the click of a button without having to leave their design tools. On the engineering side we offer Codepen-like interactive previews as well as the ability to embed Storybook stories – so designs and front-end code can live side-by-side in the docs. In order for it to be easily accessible by the entire company (and possibly made public), the documentation can be published as a standalone website and shared with anyone using a link (or protected with a password) To get a better idea of what a zeroheight docs site looks like when shared, check out this example site from one of our users (https://zeroheight.com/22mjgbuf6/p/56796c) or our demo site (https://demo.zeroheight.com) That’s all for now... we’d love to hear your thoughts on what we’re building in the comments below! PS: if you’re a full-stack / front-end engineer in London that would like to help us build zeroheight, I’d love to connect :) PPS: our office is nice and leafy → https://secondhome.io/cmsimage/image/TB3BWi41LGEQLWbI.jpg |
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?