We often get the question of who the target audience of Pagedraw is: designers or developers.
TLDR at least developers.
That’s because a designer who does not code cannot use Pagedraw, but any developer that works with UIs can use Pagedraw, even if their designer never visits https://pagedraw.io.
Of course we understand that a lot of people and teams do not fall into this designer vs developer dichotomy and that’s great! A single person acting as both designer and developer should be able to very quickly build production ready UIs in Pagedraw.
Plus, we believe the real value is when both designers and developers get into Pagedraw together. Designers can use it to check that their designs work with real data and are safe for production using tools like our stress tester. Developers can use it to generate production ready UI code that they do not have to maintain.
To understand better how we think about team workflows, here are our design principles that guide us in building Pagedraw for complex teams:
Pagedraw Guiding Principles
- Developers should worry only about data. They should never think about — or write code related to — fonts, positioning, or colors.
- Data related code (i.e. controllers) should be done however you like. Pagedraw should be agnostic to that.
- Designers should keep using Sketch/Figma/Adobe XD or whatever’s best for their creative work.
- Between Sketch, Pagedraw, and code, there should be a single source of truth for each piece of information.
- There should be a contract between design and code that serves as the bridge between the two. Pagedraw allows you to define that contract.
If you disagree with any of these principles or think there’s some principle we should add to this list, email us at firstname.lastname@example.org. We’d love to hear about it. =)