Checklist for designers. Directed by front-end and mobile developers

dev.family
6 min readSep 30, 2022

--

Why did we made it?

In an ideal world designers, backend and frontend developers are all from the same team. But our world is far from perfect, so we often have to work with what we are given.

After another “alien” design, our developers boiled over and created a basic checklist for designers. We decided to share it if someone also suffers something like this. Therefore, if incomplete layouts are sent to you, or you have to determine the colors on the screens yourself, or even select the right font, feel free to send a “specialist”…our checklist.

Mobile developers ask you not to forget

General rules

  • There should be a color schema within the project design. It means not only create a palette, but use color names within design
  • The same should be done to fonts used in design
  • Create icons to export with the same size (ideal will be square form with some with indentation from the edge). Take a look here.
  • Make logic blocks for the app’s screens.
  • If you are going to use fullscreen background images. It’s better to prepare them for different device sizes.
  • Splash screen image and app image must be done when development is starting!
  • Make a plug for all images rendering within the app.
  • Remember Android has some troubles with shadows, that’s why don’t use it too much.
  • Account deletion is MUST HAVE feature, so don’t forget to add it.
  • Remember that a mobile phone’s width starts with 370px and ends with 428px. The same for height (small, big) so in critical cases don’t forget to add a variant for both (small / big) screens.

Components/Screen States

  • Each app should have a popup/alert/screen for handling error, at least fatal/global.
  • Make a popup/alert/screen that says device is not connected to the internet.
  • Make 4–5 states for input (yes they will have such an amount of it). For example in focus, blurred, with error, disabled, if you wish on blur with value.
  • Make 3 button states: standard, disabled, when something is loading.
  • Add empty states for screens. If they are similar — one time will be enough.
  • Make a loader/skeletons and add it components block.
  • Add header state on scroll if it changes.
  • If app requires camera permission keep in mind that user may don’t allow to use it and u need to add a screen that asks to go to settings and give access.
  • Make a screen for force update.
  • If we have analytics and need a permission — create a screen that tells what is the permission for (not only analytics, contacts too).
  • Don’t forget about state for selected filter if they are in the app.
  • If there are a chat, don’t forget to add states for messages (delivered, not delivered, received, sending).
  • If chats have photo/video — don’t forget to draw it.

App Store Graphics

  1. Splash screen for app while booting.
  2. Make spinners on loading.
  3. App icons in 1536x1536, 1024х1024 resolutions and generate with https://makeappicon.com/
  4. App Store images in 1242 x 2688, 1242 x 2208 resolution.
  5. App Store images in 2048 x 2732 resolution, if there is iPad version.

Play Store Graphics

  1. App Icon in 512 x 512 resolution 32-bit PNG (with alpha channel).
  2. App Icon 96x96 grayscale (with white logo) and transparent background.
  3. Image for description 1024 x 500 (Width x Height) JPG or 24-bit PNG (without alpha-channel).
  4. App screenshots . JPEG- or 24-bit PNG-file (not transparent).
  5. 320–3840 px. Aspect ratio = 16:9 (for horizontal images). To 8 MB. You can draw smartphone images separately, 7’ and 10’ tablets or you can use the same for all of them.
  6. App’s splash screen https://docs.expo.io/versions/latest/guides/splash-screens . In short, it must be 1242 х 2436 with centered element 508 х 508.

Front-end developers ask you to remember

General rules

  • Compilation of uikit. Put all the elements that the user interacts with in a separate frame. For example: select, input of all types, textarea, links, buttons, bread crumbs, etc.
  • Draw default, hover, focus, and disabled states for buttons, links, and inputs. For inputs, also draw error states.
  • If there is a select in the form, it is mandatory to draw the state in plain text.
  • Provide popup/notification for notifications and errors (for example: the request was executed successfully / with an error).
  • If there are filters on the page, then provide how the status of the search process will be displayed when the result is found and if nothing is found.
  • Drawing up a diagram of the fonts used with an adaptive. And it is mandatory to use the same size both in the mobile version and on the desktop (i.e., if we use the h2 font for the header, then the same h2 font should be used in the mobile version, and not change it to h3, for example). Use no more than 6 sizes for headers (h1 … h6). Fonts to take out in uikit.
  • The project should have a color scheme. (Not only do we make a color scheme, it is important to use the same naming for the project). The color scheme should be taken out in uikit.
  • Icons in one block should be made of the same size. If the icon has hover effects, use icons whose color is formed from fill or stroke. Using 2 of these properties complicates, and sometimes makes it impossible, the description of styles for hover effects.
  • Be sure to need pictures with sizes w:1200 h:630 and w:300 h:300 for previews when sharing in various social networks and messengers.
  • Favicon in svg format size w:32 h:32. If the favicon is in png format, then the size w:310 h:310 is needed, but it is better to use svg. Usually you can use a logo, but there are often three-dimensional logos that are not suitable for a favicon.
  • Group composite images so that you can export them, as often we don’t have access to editing the layout.
  • Draw pages 404(page not found), 500 (server error), popup with cookies stored.

P.S. It would be more convenient if the design of the mobile and tablet versions were located next to the design of the desktop version, and not spaced across different pages.

--

--

dev.family

💜A friendly bunch of developers who used to treat themselves as a family 🍔We are really good at food tech, but like to dig into e-comm as well.