
Launch HN: zeroheight (YC S19) – UX design docs that stay up-to-date - jdelafargue
Hi HN!<p>We’re Jerome and Robin, the founders of zeroheight (<a href="https:&#x2F;&#x2F;zeroheight.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;zeroheight.com&#x2F;</a>).<p>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.<p>Documentation is the first piece of the puzzle – our vision is to enable any company in the world to have a &quot;design system&quot;: 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. <a href="https:&#x2F;&#x2F;www.lightningdesignsystem.com" rel="nofollow">https:&#x2F;&#x2F;www.lightningdesignsystem.com</a> (Salesforce), <a href="https:&#x2F;&#x2F;www.carbondesignsystem.com" rel="nofollow">https:&#x2F;&#x2F;www.carbondesignsystem.com</a> (IBM), <a href="https:&#x2F;&#x2F;polaris.shopify.com" rel="nofollow">https:&#x2F;&#x2F;polaris.shopify.com</a> (Shopify)<p>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!<p>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.<p>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&#x27;t enough for us to raise money. This led us to go back to basics: talk to users...<p>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:<p>- Good design is now the default, most products need a great user experience to compete<p>- Because of this, companies are spending a lot more resources on design&#x2F;UX and growing their design teams rapidly<p>- 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<p>- 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.<p>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.<p>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!<p>2. Companies that _don&#x27;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&#x27;t built for purpose and the documentation can easily end up out of sync with the latest designs and code<p>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.<p>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)<p>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 (<a href="https:&#x2F;&#x2F;zeroheight.com&#x2F;22mjgbuf6&#x2F;p&#x2F;56796c" rel="nofollow">https:&#x2F;&#x2F;zeroheight.com&#x2F;22mjgbuf6&#x2F;p&#x2F;56796c</a>) or our demo site (<a href="https:&#x2F;&#x2F;demo.zeroheight.com" rel="nofollow">https:&#x2F;&#x2F;demo.zeroheight.com</a>)<p>That’s all for now... we’d love to hear your thoughts on what we’re building in the comments below!<p>PS: if you’re a full-stack &#x2F; front-end engineer in London that would like to help us build zeroheight, I’d love to connect :)<p>PPS: our office is nice and leafy → <a href="https:&#x2F;&#x2F;secondhome.io&#x2F;cmsimage&#x2F;image&#x2F;TB3BWi41LGEQLWbI.jpg" rel="nofollow">https:&#x2F;&#x2F;secondhome.io&#x2F;cmsimage&#x2F;image&#x2F;TB3BWi41LGEQLWbI.jpg</a>
======
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

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

[1] [https://standups.io](https://standups.io)

[2] jp at standups.io

~~~
jdelafargue
Thanks! Standups looks great but we're currently non-remote :)

~~~
jpincheira
Thanks Jerome. And sure, no worries. I thought you’d probably had a few people
working remotely apart from the office :)

------
gatherhunterer
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
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
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
Meant software _architecture_ design :) Usually no one builds frontends in
isolation. So will be good to have something e2e in one place.

~~~
jdelafargue
Got it, thanks for clarifying!

------
mattmarcus
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
Thanks for your support! :)

------
omarchowdhury
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
Cheers Omar! Looking forward to your feedback :)

------
cflyingdutchman
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
That does sound useful! Yeah I now realise the title is ambiguous :S

------
onion2k
That's really nice. Well done.

~~~
jdelafargue
Thank you :)

------
graphene
So cool to see you guys go from strength to strength since the old days in our
EF cohort!

Onwards and upwards!

~~~
jdelafargue
<3 Hope all is well with you!

------
DrScump

      in London 
    

Will you be needing "boots on the ground" in SV later?

~~~
jdelafargue
Maybe :) TBD!

------
unlinked_dll
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
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
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
Thanks for the feedback! Really helpful

------
Digg_mov
wow!!!!!!!!!

