Hi HN. I've been working on a new browser-based design tool that's ready for you to try.
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
Noya looks great, so this isn't a criticism of them, that said:
> 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.
I broadly that this sounds like a people problem rather than a tooling problem, but I would add:
>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.
> None of them actually solve this problem because they can’t generate the actual code. That is a crucial part.
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
I really appreciate the thoughtful feedback. You described the problem extremely well - I might have to use some of those points when I talk about Noya!
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.
If you are targeting code generation, try Framer.