The designs must be applied on some friendly tool where we, the developers, can quickly obtain the assets, colors, dimensions and more.
We are in 2019 and designs in a PDF are no longer accepted.
In Lateral View we use different Handoff tools between designers and developers, such as:
Several of these tools support automatic code generation for different platforms (Android, iOS and Web), such as resources (colors.xml for Android) and more.
Personally, I like Zeplin. Their macOS Application works great, but any of the tools I mention serve the purpose: to improve communication between devs and designers and allow the creation of end-to-end products to be smoother.
If you use these tools properly, theres’s no excuses for you to have pixel perfect screens 😬 !
One thing is usually very tedious for developers is having to rename files. The thing is, IDEs (AndroidStudio / Xcode) only support a particular format. So, to save time, the assets (image files, videos, fonts) must be in lowercase and without spaces in between (use “_” as a separator). Also, if an asset is modified, I don’t recommend to specify the change in the name. For example: ic_close_v1, ic_close_v2, etc. Directly overwrite it and be consistent (ic_close), because that way we can replace it more quickly.
Be consistent with color palettes and avoid making variations that are not visually appreciated. Each selected color actually makes sense if it can be consistently associated to some behavior / component throughout the application.
This not only allows the code to be more maintainable, but it will be much easier to support multiple Themes or do a re-skining if needed.
The same is applied for fonts, keep them associated to some component and text hierarchy (headers, body).
It is necessary to ensure that all the assets are vectorized (SVGs) to be able to scale them for different screen sizes and avoid losing quality. Obviously, this does not apply to everything; being vectors, they are rendered mathematically so they must be composed of simple shapes, nothing very complex.
The advantages of this are:
If there is a textured background, and we want to make sure it doesn’t stretch, we need to receive the texture separately. We make sure we repeat it properly in the UI by using some particular format for each platform, such as 9.patchfor Android.
In an ideal world you do not need loading screens (everything would load instantaneously), there would be no connection errors, unexpected errors, etc. But the reality is different. Most of the applications consume resources from some server, they need to execute tasks in the background, etc. and many times users have to be aware of what is happening. That’s why you should not forget to design different loading components (spinners, placeholders, etc).
The same with other unexpected errors that can occur, like the Internet going down or the handling of diverse server errors.
If you are using Material components, you probably don’t need to take care of this, but don’t forget that the UI has its own life and must react to user actions, so if some UI component is pressed, long pressed, dragged, etc, don’t forget to design the Styles for each case.
Both, Developers and Designers, should know the guidelines for each platform. We should know the rules by heart in order to be able to break them if it favour product UX. So make sure you completely understand them to be able to propose informed changes:
Understanding User Interface Guidelines from each OS in depth, will allow you to create bold experiences and break the rules in an innovative way.
It is also good to analyze the different system applications of each platform, such as those of Google (Gmail, PlayStore, etc.) and iOS (App Store which was redesigned in iOS 12) that are based on their guidelines.
You could say that all applications using native components, such as Material, are similar. Here, other components are put into play such as UX, animations, content, etc.
Please, do not forget animations, a very nice app can become boring if it is very static and the elements do not come alive and react to the different actions performed by users.
Always consult with Developers when choosing one animation over another. There are animations that can take up 2 lines of code and be much more interesting than custom animations that require several days of work to be fluid and enhance the experience. Also, do not forget to include animations for the transitions between screens.
If you want to know more about why the use of animations is very important, you can not miss the article that our UI / UX Leader Elisa Goyeneche wrote: Why is motion design so important to user experience.
And if there are people who know a little bit about Adobe After Effects, they can not let the opportunity go by exploiting Lottie’s potential. It allows you to export animations made in After Effects to json files that are interpreted by the different Lottie libraries for each platform (Android, iOS, React Native).
When using vectors, files weigh very little and adapt to different screen dimensions. Before starting to create an animation with After Effects, make sure to review the limitations and what features are supported by the desired platforms.
One more tip about this: GitHub is full of super interesting animated libraries that can also be used as a reference by designers, so they can do a quick search on Github about some animation and consult it with the developers 😄
Beware of the Aspect Ratio, which is often not explicitly clarified in the designs and mistakes are made to set incorrect sizes, such as variable width and fixed height, causing the image to be stretched out. That’s why it would be very helpful if the Aspect Ratio that has to maintain each image/video is clarified in the designs. This way, developers can set the properly configurations to respect it.
As years go by, newer devices come with higher screen resolutions. This means that before you start designing, you should take into account for what devices the application will be intended. If it is an application that has to work for any device, it doesn’t make much sense to make the designs over low densities, mdpi in Android in or @x1 in iOS. It is better to apply the most used resolutions at the moment, like xhdpi for Android and @x2 and @x3 for iOS, because even if the designs are independent of the pixels there can be many variations in the sizes of the components.
It is also good to specify which components always have to be kept in a specific location on the screen, such as having a button always in the middle of the screen, so developers do not make the mistake of setting fixed distances instead of using relative distances or by percentages. It is very important to test the designs on different devices. One thing that I do, is to test the UI very quickly from the AndroidStudio preview by selecting a device with very low resolution like the Nexus One. After, I do the same with a very high resolution device like the Pixel 2 XL, and in the case of iOS you can try the iPhone SE and then with iPhone 8.
Remember to be very careful with the devices that have Notch, do not forget to respect their safe area because otherwise there may be inconsistencies between devices with and without Notch.
Something I like to do a lot is to develop with a designer, the same thing can be done in the opposite way, design with a developer. This way, both can understand how the tools at play work, understand the limitations and times.
Above all, be proud of your team. I am very proud of the Design Team I work with daily, I feel we polish our processes in the right way and that communication is very fluid.
These tips can be very useful for freelance designers who don't have the opportunity to communicate with the developers, and by doing this they can avoid any misunderstanding.
To wrap it up I repeat: communication is the key. No one who has the last word and everything must be debated. Constructive criticism from both sides is necessary to improve the process and create beautiful end-to-end applications to solve real problems and let our users enjoy the experience.