The idea is you work on your design in low fidelity wireframes, while still getting a high fidelity output that you can share or use as a reference for your implementation. The way it works is by mapping low fidelity blocks you draw into high fidelity design system & React components.
I spent several years working on design tools at companies like Airbnb, and I think the ideas behind many of the tools we built for designing at scale could really help startups and small teams as well. I would love any feedback you have!
PS: Most of Noya is open source at https://github.com/noya-app/noya
-keeping design consistent from wireframe to mock-up to finished product is a challenge. Esp with small, bootstrapped teams without a dedicated design person (let alone department) consistent, professional design is a challenge. This will allow me to mock-up exactly what I want and pass it off to dev in one process.
-I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there. None of them actually solve this problem because they can’t generate the actual code. That is a crucial part.
-This bridges the gap between having a designer create a design system and deliver mood boards, fonts etc. and actually putting those things into practice technically and consistently. Getting a design made isn’t the problem, there are a million designers out there - actually using it consistently in a way that’s practical is another challenge entirely.
Thanks for this product, can’t wait to actually use it more.
> keeping design consistent from wireframe to mock-up to finished product is a challenge [...] this will allow me to mock-up exactly what I want and pass it off to dev in one process [...] I use figma, balsamiq, photoshop and have tried probably every other wire framing tool out there.
If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using. Code generation does not replace developers, it's an augmentation at best, and so if you're running into these challenges with your current tooling then you're going to run into them with Noya (or any other tool that does not replace your developers).
You should either replace your developers with developers who can deliver to a specification, or change your approach to business (by not building software any more). I'll bet that the problem you've described here is not your only problem with the developers, rather it's one symptom of the problem.
Code is the easy part of software engineering, any competent developer can churn out code faster than it can be specified. The hard part of building software is translating a business need into a specification. Prototyping tools (like Figma) are very helpful upstream because they help the business provide a much more robust specification -- if you're building a prototype in Figma of how a user interacts with a page, you won't forget to explain what a specific button does.
If you're already doing all of that work to provide developers with a pixel-perfect rendition of what you want, and they're still not delivering it, just giving them a bunch of code instead to represent that design is not going to solve the problem.
A helpful model for evaluating the development work of developers is to think of it like construction workers: if a construction worker is given a plan for a square 250 sqft bedroom, and they build a 100 sqft shed instead, and you had clearly communicated that you wanted a 250 sqft bedroom, you would not think the input was the problem. You'd start to question the workers. Just because you can't write code, does not mean you need to allow developers to get away with churning out things that aren't what you've asked for.
>If you have a team of developers and they're not able to deliver to a specification, the problem is with the developers, not the tools you're using.
Or the problem lies in the designers providing the specification, which is also a situation I've seen a few times. A good design specification isn't just providing a view of the overall layout, it's also providing the pieces that went into that design: the visual components, the guidelines used for layouts, a list of colours and distances used, etc.
Simply providing a "pixel perfect" version will not get you good results, because that's essentially a lossy translation of the designer's intent. To implement that intent, you need information then just, for example, how big each button needs to be, you need to know how big a button can be, how small it can shrink to, what should happen with oversized or undersized text, how it will be positioned in its containers etc. Partly that's because intent is often a clearer way to communicate things than results, but mainly it's because there's no such thing as a pixel-perfect render target. Browser sizes can change, phones can be rotated, and people will insist on all sorts of different resolutions. It's only by describing intent (this element should fill the space, this point should be equidistant between these two points, etc) that you can adequately support all these situations.
That said, I broadly agree with you that this sounds more like a people problem than a technology problem.
Because there are a million ways to generate that code (if we're talking about the browser), and they will all break when coming into contact with reality.
- your sizes are in em/rem, and your root font size is off? Goodbye design
- you absolutely need something at the bottom of the screen (think media controls), and you have absolute positioning? Goodbye design for large combinations combination of screen/positioning
- you need something centered on, say, third element from the right? And then another element is added on the left? Goodbye design
- you need something animated? Goodbye design
- etc. etc. etc.
However, for some established patterns you might get away with some standard design choices and some generated code
Honestly the current version is an MVP and probably won't deliver on the promise just yet. But I'm confident we can make it good enough to fill that gap in tooling.
If you get stuck or don't like how things work, feel free to throw feedback at us. We've added/updated a lot of stuff based on what the first few people have suggested already.
How does it work with responsive layouts?
At the css level, "top-level" components are absolute positioned, but nested components are layed out with flexbox.
There's no way to bring your own React component library yet, but once that's possible, you can always make things responsive in the library itself too.
I’m not the target for this kind of tool, so please take this as a soft critique if any at all: everything up to this point has struck me as positive, but this registered a big “yikes!” in me. I’d think top level components would be by far the simplest to handle reflow without any specific positioning considerations.
In the 'age' of GPT, interacting with software via 'tools' is severely outdated.
Further - the era of web pages is just about over. I don't yet know what will replace them, talking heads? A talking splash screen? Or something else? Or maybe we will finally be free of staring at pixels? I don't know, but the change will be bloody fast.
All great, but these days it seems outdated. I don't buy it.
So I think you're wildly overestimating AI tools, and underestimating that design tools like this are still very valuable.
That's one of the things I really missed while working at a big co like Airbnb. The infra team sat separately (depending on the re-org, in a different building) from the design team. I feel like so much great stuff happens when sitting side-by-side.
Disclaimer: I work at Relume
That's great to see. You're missing a LICENSE.md though, is it MIT licensed (as per package.json)?
Also, what does "most of" mean? What parts are closed source? Do the open source parts comprise a complete and usable app?
As for the license, I still need to sort that out. It will very likely all be Apache 2.0, but perhaps dual licensed MIT or something else. Licensing/docs/contribution guidelines/etc are lacking right now, so I don't recommend using the source code for anything yet - but may be interesting to poke around on GitHub.
We generate a simple React app with two files (App.tsx and package.json). It imports the component library (currently Chakra UI) and provides basic code for what you designed in Noya. The code can be used as a starting point or as a reference for adding your design to an existing React app.
The app frontend is open source while the backend is closed source, at least for now. It should run without the backend, but some things like sharing projects won't work. I'm planning to publish the individual frontend packages to npm as an "SDK for building design tools", so anybody can import "noya-canvas", "noya-renderer", etc, to build their own design tool.
I'm on Windows 10, Firefox 109.0.1
Since Noya is web-based, there's a lot of options to avoid getting completely stuck, though some things are certainly more difficult than others.
Who is your target user? Right now it feels like this could be a superpower for non-designers but a bit limiting for designers.
I remember a medium article (I think?) about the Airbnb team building something similar to transform whiteboard sketches. Were you a part of that work?
Thanks for sharing, hope you don’t mind the feedback — the tech is impressive!
I definitely want to support more design systems, including higher fidelity ones. I started with Chakra due to its popularity and simplicity, but agree that visually it's not the most compelling demo.
I think the people who will get the most value from what Noya can do today are founders, PMs, researchers, and engineers - people who want to show a mockup to their team or customers, but who don't want to spend hours in Figma.
Part of the goal, which I think could be valuable to designers too, is to help smaller companies leverage design systems without needing a person/team to support them. E.g. Airbnb had a design system team AND a design tools team, and I think that's a big part of what made it work. At smaller companies, trying to use a design system without the proper support can often make things worse. We think Noya might fill that gap. With Noya, a smaller company could make mockups and prototypes with their existing React component library, without having to maintain a separate Figma library.
My cofounder David worked on the Airbnb sketching interfaces project: https://airbnb.design/sketching-interfaces/. But mostly the output of that plugged into the higher fidelity (internal) design tools that David and I were building.
A decade ago, I relied on simple tools like Inkscape (to remove Adobe hegemony for my workflow) for mockups and high-fidelity design, using HTML and CSS for coding a prototype. I could open and work on those files without any intermediaries, making my work much more efficient.
Today, I find myself forced to use Figma for design and collaboration, Notion for organization, and Webflow (SaaS Dreamweaver) for creating prototypes, all while relying on countless plugins for Figma to compensate for the software's shortcomings. It seems that designers are now more focused on keeping up with the latest updates, trends and tools than on delivering solutions to real-world problems.
It's time for a change. We need a new tool that simplifies our workflows, focuses on the needs of designers, and offers a library of boilerplate design system solutions with headless components and tokens. This tool should be accessible to offer the option to export code and assets without any paywalls or SaaS limitations (on top of subscription). Such a tool could revolutionize the design industry and save us all valuable time and resources.
Currently, my subscription total for all the different tools I use exceeds $120. With a simpler, more streamlined workflow, designers could focus on their work, rather than the tools they use.
* Instead of exporting a file, I'd prefer to see the code in the UI and then decide if I want to piecemeal or just download the whole file with package.json, etc. As someone who iterates it would be annoying to continually download new zips
* Is it possible to define custom primary/secondary colors to use as hashtags? Almost like tailwind config file where I can set up my theme in advance and reuse or @apply through the hashtag. And like tailwind, it would be great to just do #[000000] to set a custom color or value on the fly for a button, etc. or explicitly define #bg-black #text-white etc.
- I think showing the code in the UI makes sense!
- We definitely want to allow theme customization. I'm not sure exactly what that'll look like, but right now it feels pretty limiting without it. I think primary/secondary could make sense as a place to start.
So I wanted to see how radios looked at work, but I completely unable to understand what i needed to do to actually see an example. I clicked the "+" sign, drew a "box", and set it to radio...and...
...nothing happened.
I tried adding some text and hit enter, think maybe as I added new lines of text radio buttons would magically appear...and...
...nothing happened.
No help, no examples of how to use the "Radio" selection in the box pulldown to, you know, actually generate a radio component.
I mean I'll admit...I'm almost 60 years old and have been working with these sort of tools since Delphi/Borland came out in the 90s (80s?), so almost surely my expectations of how these things now work is totally shaped by my now ancient understanding of this sort of thing, so I'm sure its my ignorance and not the fault of the developer.
Could you perhaps add a form or two that are preloaded with the various controls so I might learn the proper incantations for the use of your project?
Thanks for your hard work in developing this tool.
We will definitely add examples and better onboarding content. Since we are creating a tool experience that's different than what's already out there, the responsibility is ours to provide the resources necessary to become productive with it.
At least for now it's pretty rough around the edges, so I'm hoping to underpromise and overdeliver
Edit: I didn't know HN doesn't support emojis, cause I just added one but it got stripped out lol
There's a basic tailwind integration already - on some blocks you can write tailwind classes to style them e.g. #bg-red-500, #shadow. But the code export still includes Chakra UI components. At some point we want to support exporting plain html/React + tailwind without Chakra or other design systems.
Why not just generate CSS and vanilla JS logic and allow the end user to consume that accordingly? Later you can add and should focus on user customizable APIs for this sorta thing because most autogenerated code is at best a starting point but most often useless unless it can be tailored to a specific use case
