In this first post of this new series called “What do we expect from … ?” we want to expose all the most common misunderstandings between the UX/UI Team and the Mobile Dev Team.
1. Handoff
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:
● Zeplin: I think it’s the most popular. It allows to export designs from Sketch, Adobe XD CC, Figma and Photoshop CC and generate all the assets, dimensions, colors prepared for the different platforms, whether Web, Android or iOS. You can use it on your website or download the application that is available for macOS and Windows.
A very good feature that Zeplin has a Styleguide section where you can see all the colors and fonts of the App in a single app and export them.
● Sympli: Similar to Zeplin, but instead of having applications, besides having the web version, it has plugins for the different IDES (AndroidStudio and Xcode).
● Invision: Not only is it very useful for prototyping, but it also includes the functionalities already mentioned above.
● Marvel: Allows you to add animations to the designs. It has no desktop application, so you have to use the web version, which is not very comfortable to use.
● Figma: You can use Figma to design and prototype. Since designs are created with this tool, all assets are exportable automatically. This means that you don’t need to ask Designers to upload a specific asset by itself.
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 😬!
2. Assets Naming
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.
3. Color palette
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.
Color Palette TMDG 17 by Lateral View
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).
4. Assets
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:
● Automatic scaling without losing quality.
● Reduction of application size. Instead of having 3–5 pngs for different resolutions (mdpi, xhdpi, xxhdpi, xxxhdpi, @ x1, @ x2, @ x3) there is only one file.
● Better manipulation and customization. You can programmatically change certain attributes of the SVGs (which in reality are exported to a particular format on each platform), such as the colors for each shape.
5. Textures
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-patch for Android.
6. Non-Happy path Screens
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.
7. Actionable UI Components States
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.
8. Platform Guidelines
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.
Advantages:
● The components are already defined by each platform and development times are streamlined. Also, the native components have some pretty nice behavior that would take lots of work to achieve them from scratch. Examples of these are: animations, shadows, elevations, etc.
● Users are already familiar with those components, so the learning curve for them will be shorter.
● Accessibility. Native components are prepared to include the largest possible segment of users.
Disadvantages:
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.
9. Animations
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).
Lottie Animation — Lima by Lateral View
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.
Here you can find several tips on the creation of Animation in After Effects for Lottie that Gisela Abrigo, one of our prized designers, wrote: Lottie: Motion made easy for the UX UI designer.
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 😄
10. Aspect Ratio
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.
11. Screen Sizes
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. So, 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.
12. Peer Design-Dev programming
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.
13. Be proud of your team
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.
If you want to know more about technology and innovation, check us out at Lateral View or subscribe to our newsletter!
