2

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?

  • 1
    Different screen sizes and aspect ratios are a complex problem. You will have to provide additional information, what your requirements are and why a simple resizing of the content to the screen size is not a good solution. - Do you want to support landscape and portrait mode? Tablets? What is with older phones with a very coarse resolution, they may need a lot bigger font size compared to the screen size... – Falco Feb 14 at 14:38
0

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.
  • Since you're critiquing answers...determine range of sizes, build layouts, throw design over the wall, em vs. px, fluid layout vs. fixed, is all development not design – moot Feb 15 at 15:57
  • 1
    Strong disagree. I've worked on both sides of this, I'm mostly a developer these days rather than a designer (note how much of my answer is focused on making this easier for the developers...) Ideally this should be a collaboration rather than a pitched battle; but even in companies that don't have that process in place, most of that stuff belongs in the designer's territory imho. – Daniel Beck Feb 15 at 16:00
  • I'm both UI designer and full stack dev too. Designers should design and developers should develop. Of course they should work together from the start. – moot Feb 16 at 23:43
-1

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

  • Implementing it is indeed development's job. Design still needs to provide guidance on what design to implement, though: different screen ratios or sizes may require different layouts. This is independent of the question of pixel density. – Daniel Beck Feb 15 at 13:35
  • Of course design is in charge of design. It's up to development to try to implement the design. Working in DPs solves many major responsive design issues. DPs are the way design should communicate with development. – moot Feb 15 at 21:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.