[HN Gopher] Launch HN: Noya (YC W23) - a new kind of design tool
___________________________________________________________________
Launch HN: Noya (YC W23) - a new kind of design tool
Hi HN, we're building Noya (https://noya.io), a product design tool
that lets everyone design like a designer. Here's a video:
https://player.vimeo.com/video/797476910. Getting from a product
idea to a design is too hard. Wireframing tools (e.g. Balsamiq) are
limited and their output is too low-fidelity to get people excited
about the idea. On the other hand, high-fidelity design tools (e.g.
Figma) require advanced skills and are better for tweaking fine
details than hashing out a big picture. Meanwhile, companies have
an insatiable need to make new screens and change existing ones,
and hiring more designers is time-consuming and expensive. David
and I were on the design tools team at Airbnb when we realized
there's another solution: let designers encode their knowledge
(e.g. design rules and components) into a tool, then let non-
designers (PMs, marketing, engineers) use that tool to make new
screens and features. This helps remove design as a bottleneck for
a lot of product development. We built such tools at Airbnb, and
with Noya we're building them for product teams everywhere.
Current design tools are too freeform for non-designers to design
great products. They let you do anything, like draw rectangles and
move text blocks anywhere, so it's easy to mess things up,
introduce inconsistencies, and so on. With Noya, designers set up
"guardrails" in the form of a design system (rules and components
for a company's design), then non-designers work within those
constraints. This makes it harder to mess up and quicker to build
something that fits in with your product. Footguns begone! It all
starts with wireframing, i.e. drawing a minimal layout that shows
the elements that would exist on the screen. Noya combines
wireframes and design systems to generate high-fidelity designs and
code. If you have an idea for a user interface, you can use Noya to
quickly wireframe that idea by clicking and dragging to place
blocks for each element of your user interface. For each block,
choose a type and provide any content that goes inside it. Based
on the rules and component library of the design system you select,
Noya automatically turns your wireframe into a high-fidelity
design. This design can be exported to design files, to Figma or
Sketch, or to React code. (If you're curious what the React code
looks like, try exporting and take a look! There's plenty of room
for improvement, especially around responsive layouts, but we think
it's a reasonable starting point. The code export is configurable
on a per-design-system basis so that it's closer to a company's
preferred standards). Most tools in this space are optimized for
either low-fidelity wireframes that are quick to create (e.g.
Balsamiq), or high-fidelity output that's slow to create (e.g.
Figma). We think there's a gap in the market for a great
wireframing tool that produces a high-fidelity output quickly. For
example, two-thirds of Figma users are non-designers. While there
are many valid reasons for a non-designer to use Figma, there's
often a lot of upfront effort required to learn the tool and set up
components. We think there should be a lower-effort way for non-
designers to create high-fidelity designs. Based on feedback from
our Show HN (https://news.ycombinator.com/item?id=34848583), we've
improved our onboarding, revamped our entire block library, and
added a documentation reference for each block type. The docs are
interactive, so you can play with our editor without signing up:
https://noya.io/app/docs. Startup founders and PMs have used Noya
to build landing pages, dashboards, and other flows of their apps.
We have some templates on our site (https://noya.io/templates) that
give examples of what people commonly build in Noya. We use Noya
ourselves, and have been surprised by how frustrating it was to go
back to existing design tools after using even the earliest
prototypes of Noya. Existing design tools just aren't built for the
comprehensive design systems that products are based on today. The
source code is available here (though largely undocumented &
unlicensed): https://github.com/noya-app/noya. We're not focused on
growing our open source community or supporting other design tool
builders just yet, so we haven't published our packages (renderer,
canvas, etc) to npm, but we're planning to use the Apache V2
license. We make money by offering a paid subscription. Noya
currently supports one design system based on Chakra UI. We're
adding additional design systems soon, including Material Design,
as well as the ability to import custom design systems. If your
company has an open source design system and you're interested in
trying Noya with it, we may be able to integrate your design system
for free. Get in touch if you're interested -
dabbott@noyasoftware.com. We'd love for you to try Noya and let us
know what you think! It's still very much an MVP and all kinds of
feedback are welcome.
Author : dabbott
Score : 79 points
Date : 2023-03-30 15:50 UTC (7 hours ago)
| JusticeJuice wrote:
| Super interesting.
|
| 1. How are you going to get over the layout logic hump?
| Converting from elements on an x/y canvas to actually good
| frontend code (Properly nested dom elements, responsive etc) is
| really hard. I'm pretty sure it's why no 'design to code' tools
| are actually used in production.
|
| 2. Would you consider making this as a figma plugin, as opposed
| to a seperate tool?
| dabbott wrote:
| These are great questions:
|
| 1. The way I've been thinking about it now is similar to how I
| use autolayout in Figma. Simple x/y is convenient for a very
| first rough draft. Then I'll refine my design by making
| components and adding autolayout as needed once the project
| grows or I want to collab with somebody. Similarly, Noya will
| support putting components in "stacks" and other layouts (some
| of the built-in components do this already) that translate
| cleanly to e.g. flexbox. The hump is definitely there, but I
| think we can make it relatively pain-free. Since code export is
| configurable on a per-design-system basis, a company can also
| adjust the code/config export to match what they do in
| production.
|
| 2. We'd definitely be _open_ to it, but it might be difficult
| /impossible to make it a good UX. We render actual React
| components from a company's component library in the browser
| DOM, whereas Figma renders shapes on a webgl canvas. It might
| be possible to mix and match with Figma widgets in some way,
| but would probably be janky. Could still be worth trying
| though!
| JusticeJuice wrote:
| Autolayout is definetly a good approach. Webflow is a good
| commercial example, their builder isn't a canvas experience,
| it's a nested block experience, so you're forced to think
| about the layout from the start - and it works. I know of
| website design agencies who's staff are just designers who
| can't code - but they build everything they deliver to a
| clients in webflow.
|
| What webflow doesn't have to deal with compared to a tool for
| webapps, is that most websites are just static. Web apps have
| all this extra code mixed into the frontend for functionality
| - providers, routers, state management methods, api calls
| ets, all this extra stuff in your components that isn't just
| "view". Taking some generated static react and adding
| functionality is easy. But then coming back to a page 5
| months later, and refactoring the design in Noya, and merging
| that new code with what's actually been built? Kinda tough.
|
| It really depends if code export is a core goal, or more a
| side effect. There's a lot of value imo in a tool for
| designers, devs, business owners, whoever at a company to
| mock up an idea really quickly, with something that looks
| like their companies actual design system. Like the napkin
| sketch on steriods - but then still implementing it
| traditionally.
| dabbott wrote:
| Definitely agree on there being a lot of value in the
| napkin sketch on steroids approach, and that's where we're
| starting.
|
| Creating real designs and shipping to production within a
| constrained environment (e.g. https://medium.com/airbnb-
| engineering/a-deep-dive-into-airbn...) can be super high
| leverage, so that's ultimately where we want to go. Right
| now every company that wants to do this has to build it
| themselves. We didn't use an off-the-shelf solution like
| Webflow at Airbnb (afaik) because there was no realistic
| way to integrate it into our stack. I'm not sure if Noya's
| code export will be what people end up using for this -
| maybe some kind of JSON-config or something else will be
| the more useful artifact.
|
| As an analogy, Retool makes it easy to create internal
| tools, and is usable by more than just eng. But somebody on
| the eng team needs to first configure it a bit (e.g. plug
| in the company's data sources) before making real tools
| becomes possible/efficient. Noya will require a similar
| level of configuration to become usable in these more
| advanced scenarios, but we think the value it delivers will
| be worth the effort.
| whoomp12342 wrote:
| not able to copy/paste images in from the clipboard is very
| limiting for me. I make my wireframes with powerpoint and love
| this idea, but I cant do it without snipping stuff around
| dabbott wrote:
| We can add this! We have image drag n drop already so should be
| very easy to also support pasting from clipboard.
| Tepix wrote:
| The video is pretty slick, however i can't help but be reminded
| of the other story that hit the HN frontpage earlier today: "The
| age of average" https://www.alexmurrell.co.uk/articles/the-age-
| of-average
|
| These designs are not new and exciting, quite the opposite.
|
| I'm happy to be proven wrong!
| dabbott wrote:
| That's a very interesting point.
|
| By guiding people down the "happy path" with "guardrails", we
| may end up in mediocrity land. Additionally, Noya is optimized
| for solving user/business problems and not visual exploration.
|
| At Airbnb we had a really strong set of design guidelines,
| patterns, and components that (I think) both looked beautiful
| AND solved user needs. I think as the tool evolves and
| companies integrate their own opinionated design systems (vs.
| just Chakra UI, which is very neutral), the output will start
| feeling more polished & unique. But perhaps there's more we can
| do here.
|
| Definitely something we'll need to think through!
| claytongulick wrote:
| This seems spectacular, and I already would have added my CC and
| purchased a subscription, except for two major things:
|
| 1) I don't use react, I use web components. This product seems
| very React centric, which kills it for use for a lot of people
|
| 2) It's not helpful to me to be limited to the Chakra UI design
| system, in order for this to be useful for my teams, I'd need to
| be able to add our web component design system. I assume there
| would be some sort of "mapping" process where I could indicate
| "this is a header component" and "this is a sidebar" component,
| etc...
|
| The absolute killer feature would be to allow me (storybook
| style) to add any web component and place it on the screen. I've
| been searching for a visual designer like this forever, it seems
| like the obvious solution with web components, but I still
| haven't found it.
| FpUser wrote:
| Amazing. I was about to write literally the same. Stick to web
| components and plain JS. Add some small routing library of your
| own if needed and ability to import web components.
|
| Basically look at what Delphi / Lazarus / MS .NET Form
| Designers do and replicate best parts of it.
| dabbott wrote:
| Thanks for the feedback! This is super valuable.
|
| 1. There isn't anything fundamental about that tool that
| requires React. We have a lot of React experience and it's a
| very popular framework, so it made sense for us as a place to
| start, but we can definitely consider supporting other options.
|
| 2. Absolutely! We have a first draft of our mapping protocol
| already that works reasonably well, but still needs more
| iteration before we open things up. It supports a custom hook
| for attaching things to the DOM, so shouldn't require React
| specifically either.
|
| Can you share a little about how you use web components, so we
| can better understand what an integration should look like? Do
| you use any kind of JS framework (at build time or runtime)? Do
| you use JSX, or is it all vanilla HTML?
| claytongulick wrote:
| Pretty much vanilla, but it depends on the component.
|
| For components that need reactivity and have frequent
| renders, I use lit-html for rendering on a property setter
| change.
|
| I mix and match components from different frameworks, I use
| vaadin-router, but sometimes include lightweight components
| from other systems too (ionic, shoelace, mwc, etc...).
|
| Mostly though, it's just light-dom vanilla Web components
| with bootstrap (or similar) for base styles.
| dabbott wrote:
| Got it! Thanks for the info, it's very useful to understand
| the workflow.
| joduplessis wrote:
| This looks really interesting. I'd be very interested to see how
| you guys iterate to accommodate other frameworks or actual design
| systems. IMO Chakra isn't so much a design system as it is a
| framework (like Tailwind) - it's an abstraction to make common
| tasks easier. Would love to see something a little more "ui-kit-
| agnostic".
| dabbott wrote:
| That's a great point! For simplicity we've been referring to
| our current "design system" as Chakra, but it's definitely more
| nuanced than that. We think of a design system as "a library of
| components and tokens, and rules for how these are used in a
| design". Our current design system uses Chakra for the
| component library part of it, while we created the rules for
| using those components in a design.
|
| We're currently working on a protocol for adding new design
| systems, which will support integrations at different levels,
| from component libraries like Chakra to more complete design
| systems like Airbnb's DLS. We'll have more to share on this
| soon!
| mwcampbell wrote:
| > There's plenty of room for improvement, especially around
| responsive layouts
|
| How is the accessibility of the generated UI?
| dabbott wrote:
| Right now it's not very good since that hasn't been a focus for
| us yet - but both David and I worked on fairly advanced design
| tools for accessibility while at Airbnb, so we have a lot of
| ideas here!
| brianjking wrote:
| This looks fantastic, gonna try it out if I can once I'm on a
| computer shortly!
|
| thank you!
| dabbott wrote:
| Awesome, let me know what you think once you do!
| whoomp12342 wrote:
| Search image for an Orange Circle. The results are hilarious
| dabbott wrote:
| We're currently searching unsplash for stock photos. I didn't
| find anything too weird when I tried that query, but they do
| sometimes feel random. We want to add multiple image providers,
| include generative AI-based providers.
| fishtoaster wrote:
| This seems pretty cool! As a dev who is, for lack of design
| resources on my team, frequently asked to pretend to be a
| designer, this could very much come in handy!
|
| That said, the real value to me would be using this tool to make
| medium-fidelity mockups that look like my existing site. It looks
| like maybe your templates would allow me to make mockups in Noya
| that match my existing colors/etc, but I'd be coupled to
| ChakraUI. If the pre-existing components from my pre-existing
| site don't match Chakra's components, it sounds like I'd be out
| of luck?
| dabbott wrote:
| At the moment, yes, since our MVP is still pretty limited. We
| have a first draft of a protocol for integrating any
| components/theme into Noya that should support the use case
| you're describing. It still needs some more iteration though
| before we ship it!
| whoomp12342 wrote:
| under your table widget, it fails to render date formats
| correctly, like 1/1/2003 will just display 1
| dabbott wrote:
| Thanks, will look into this!
| ethanbond wrote:
| My philosophy toward design has always been that the architecture
| of the problem/solution is the hard and important part of design,
| but in most design tools (like Figma) the bulk of the tedium goes
| into making things look visually convincing and not messy.
|
| I'm super excited by this direction. Even for designers like
| myself I think it could help us reclaim a lot of time for solving
| the hard parts of the problem!
|
| Great work guys
| dabbott wrote:
| That's a great way of describing the problem we're trying to
| solve!
|
| As the tool grows, we definitely hope it becomes powerful
| enough for designers to use too.
| codetrotter wrote:
| How does it look at different screen resolutions? Are the
| generated designs responsive, so that they work on phones and
| tablets as well?
| dabbott wrote:
| Right now the individual components are responsive, but the
| entire design as a whole isn't (i.e. top-level components are
| absolute positioned). This is definitely an area we want to
| improve a lot, and allow users to customize what happens at
| different resolutions.
| [deleted]
| candiddevmike wrote:
| FWIW it's not obvious that you can pay monthly on your pricing
| page, it seems like the only option is $120/year until you scroll
| down on mobile. Also it doesn't mention how many users can use a
| subscription?
| dabbott wrote:
| Thanks for the feedback! I'll take another look at the pricing
| flow on mobile, I'm sure it could use another UX pass to be
| more clear.
|
| It's one user per subscription, though you can have unlimited
| shares/viewers - what would you want it to be/say?
| candiddevmike wrote:
| Probably some kind of "/per user" near the per month part.
| dabbott wrote:
| Gotcha, we can do that!
| whoomp12342 wrote:
| any ability to import custom boostrap themes? This is great but
| like, I know we would want it in our style
| dabbott wrote:
| Custom theming & design systems are coming! That's what we're
| focused on building now. We can definitely support a bootstrap-
| based design system with custom theming in the future.
| KianHooshmand wrote:
| [dead]
| dabbott wrote:
| [dead]
___________________________________________________________________
(page generated 2023-03-30 23:00 UTC)