Launch HN: Noya (YC W23) – a new kind of design tool
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 ( thank you! 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 It's one user per subscription, though you can have unlimited shares/viewers - what would you want it to be/say? These designs are not new and exciting, quite the opposite. I'm happy to be proven wrong! 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! Put differently, Noya feels like an exploration tool. When exploring, tents are fine. They do not provide a lot of comfort, but replacing them with houses while still exploring might not be optimal :-) Personally I don't mind average tents, as long as they don't leak. EDIT: Hmmm, maybe Noya is actually between a tent (Balsamiq) and a house (Figma) - something like an RV? :-D 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? 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! 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. 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. 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! - Overview: https://adele.uxpin.com/audi-audi-ui - The system: https://www.audi.com/ci/en/renewed-brand.html Some less brand-y examples: - https://polaris.shopify.com/patterns/app-settings-layout - https://ux.mailchimp.com/patterns/color - https://designsystem.digital.gov/design-tokens/ Frameworks or component libraries like Tailwind or Material, are not design systems. Therefore, when you say you plan to integrate open source design systems, this should not mean frameworks or component libraries. It should mean design system systems, such as: This, on transforming component libraries into design systems, is worth reading: Design Systems for Developers - A guide that teaches professional developers how to transform component libraries into design systems and set up the production infrastructure used by leading frontend teams: https://storybook.js.org/tutorials/design-systems-for-develo... There's a huge need to fill the gap for design systems that "implement themselves" in the transition from wireframe to code. Hopefully you can vector to align with actual design systems instead of components/frameworks. Serving companies with real design system needs is how you get the enterprise ecosystem revenue to get bought by Adobe for $20B in cash and stock! // Disclosure: Was co-founder and CTO of a top 5 digital (web design) agency, am enterprise customer of today's design agencies. 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. 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? 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. Basically look at what Delphi / Lazarus / MS .NET Form Designers do and replicate best parts of it. 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? How is the accessibility of the generated UI? One question I didn't see answered was: how does someone define one of these components? Does Noya infer the rules about which component to translate a user-defined shape into, or does someone have to go in and say something like "if it's the full width, and it's at the top of the screen, it's probably the navigation header"? It feels like defining the rules for page-level layout blocks, vs. fiddly little micro UI elements could get tricky. Oh, and how do components get into the system at all? Does it have to be an off-the-shelf design system (like Chakra, which you mention supporting) that you've translated into Noya, or can I add my company's design system myself? For getting components into the system: we're working on a protocol (more specifically a TypeScript interface) that defines a mapping from component types that the tool understands (sidebar, navigation header, etc) to component implementations. You can add component types that the tool doesn't understand too, but like you point out, then it's more work to define the rules they use. Anyway, you can bring your company's design system into the tool by implementing this protocol - the tool loads your implementation (currently from npm, but could be anywhere) at runtime. Right now the default rules are based on component type, so when you add a new design system implementation, you start with the default rules for known components. These can be customized on a per-design-system basis via the protocol, but again it's a bit tedious to do. We've explored using generative AI for determining component rules which seems promising so far. This could potentially be less tedious and more flexible for custom design systems, and is one area we hope to explore more. As someone who keeps running into problems with the design->develop iteration cycle, I’m going to watch this closely. Great work and good luck! Make something messy, let AI iterate through ideas, repeat. Congrats and seriously impressive stuff. Best of luck with it Also just curious, Is there a way to import our existing wireframes maybe Sketch/Adobe XD? This approach seems to work because you have rightfully assumed that 95% of what we create is template-driven. However, we're working on enabling additional design systems. We'll provide the integration for some of those (Material Design is next, but we can look into what it would take to support the premium Tailwind UI components). It will also be possible to integrate your own custom design system. We'll have more to share on this soon. If you want to create another screen by modifying an existing screen, you can duplicate the project. There is a duplicate action if you click the name of the project with the project open, or by right clicking the name of the project from the project list. You can also copy and paste between projects. - When you use CMD key the active component loses the selection (visually) this is a bit confusing, e.g. I used CMD+D and seemingly nothing happened as the selection was lost for a while and the duplicated element was just put above the original element - When duplicating an element you could maybe shift the clone's position with a small amount so the user can see it has been duplicated (e.g. top +20px left +20px) - I think it needs a list/modal to see the components created (like the list in PS layers/Figma etc) so you can see what you have in your workspace (it will also kind of help with the duplication related problem above) - I scrolled via trackpad by accident (in the left column area) and I could not get back to the area I was working with, I realized it will snap back after I resize the area (with the vertical line between the two columns or with browser resize) but I think it should also have a reset view button or similar to let the user do the same as it is not obvious - Maybe it's a ChakraUI menu z-index bug but after opening the Project/Share menu you can open View/Export/Account menus in 1x click and access the tools on the left but only from starting from those 2 menus, if you start with View/Export/Account menus you need 2x clicks to close them and open the other ones next to them, the Project menu is seemingly outside of the latter problem.119 comments
[ 3.7 ms ] story [ 240 ms ] thread