I design stuff in Figma, for an iPhone 8, based on pixels. But we need to find a way to implement it in Flutter in a way that the design fits all the other screen sizes. One way we figured out so far is calculating the ratio of every element in relation to screen size… but that can’t possibly be the best practice, and it takes forever. Any insights, ideas or resources that come to mind?
There isn't a one-size-fits-all answer to this (no more than there is a one-size-fits-all layout for all screens!)
It would be laborious and not terribly useful to go through every possible screen size and ratio and specify exact pixel sizes for every element. What tends to be more successful is
- Determine the set of devices you plan to target, to establish the range of sizes (both pixel- and real-world) you need to design towards. If your application is mobile plus desktop you'll have a large range of sizes you need to design for, but even if it's mobile-only you may want to consider including layouts for portrait and landscape views.
- Build layouts for the significant extremes within that range of sizes, as well as for the "sweet spot" that you expect to be the primary, most commonly used size. There's no formula here, it will require judgement based on your expected userbase and on the details and relative complexity of the product itself. Sometimes you'll need to design lots of individual variant layouts, other times you can get away with just one or two; it really depends on the product.
- Collaborate with your development team. Throwing a finished design over the wall for them to implement in isolation is the worst-case scenario; ideally you should be able to communicate with the developers, find out what they need in order to realize your vision and what information is useful, and iterate on the design when (as will inevitably happen) some layouts turn out to need adjustment. And they should be able to communicate with you, when aspects of the design turn out to be difficult or not possible to implement, so you can work together to come up with a mutually agreeable solution.
The amount of detail that needs to be included in your specifications will depend on the development team's skills, and on the level of ongoing communication and collaboration you have with that team. When necessary variations come up, some developers will be able to adjust a design in such a way that meets the design intent without a highly detailed specification; others will need more direct guidance. More open lines of communication will always make this easier for both teams. Other things that tend to make this easier for them to implement (and more willing to cooperate with you), include
- Relative sizes are almost always better than specific pixel sizes. Specifying, for example "1em of whitespace" is generally better than "14px" or etc; even setting pixel density aside that sort of thing leads to more unintended variation across devices (and more brittle layouts overall.)
- Fluid layouts are generally better than fixed-size layouts. They're easier to implement and to design; you can let the browser or device do a lot of the work of fitting things into the available space, rather than you and the developers having to go through and hardcode a zillion possible fixed sizes.
- Style guides are generally more useful than mockups. All projects will of course require mockups of at least the key screens and features, but handing off a design that is solely mockups means you have to design each and every individual screen; a good style guide will help the developers realize your intent without having to come back to you for a layout for each and every widget and modal.
I see Welf von Hören as a designer who wants to best work with their development team. I am someone who has to implement such designs and I appreciate a clear vision to work with!
I agree that responsiveness falls to the development team, but some projects undergo painful rework when the implementation does not match the designer vision. Collaboration is certainly the key.
I think your best starting point is to find out what approach your dev team is using is to code for responsiveness. For example, my team uses Bootstrap, so we can design to the breakpoints that bootstrap uses. My advice is to sit down with a front-end developer and a qa tester to work out a process that makes the project transition smoothly through the cycle :)
Most development tools or frameworks provide support for multiple screen sizes. In case of Android, Google has arranged screensizes into groups, which makes dealing with this issue a little easier (more info here).
IOs development has a very similar situation (docs here ) and it is easier in the apple ecosystem since there is a very limited amount of devices with varying screensizes (compared to Android anyway).
I would suggest doing some research on the most common screensizes (and resolutions), and if Apple doesn't already has groups like Android, then group them yourself. Make a design for each group, and deliver to the development team. Most frameworks deal with responsivenes in groups anyway, so that would make it easier to translate design into code.
If you are worried that this would be too much work, keep in mind that designs don't change that much from one group to another.
Implementing responsiveness is development's job.
How to get the site to work is development. Responsiveness is part of that. Design creates the best definition of the product they can then development creates the best product they can that meets that definition.
Design should create the highest level prototype or mockup they can and define it in density pixels. In essence, you're measuring things by their real world size which is the best way for both design and development to think about things.
There's a great definition of pixel density in Material Design: https://material.io/design/layout/density-resolution.html#pixel-density