Some say that programmers have their own language – it’s technical, full of difficult words, and it doesn’t sound like any known human language. And let’s say that a mobile developer meets a graphic designer to discuss a brand-new project on which they will work together. How can they find a common language? Let’s try!
Most of the rules of cooperation between the developer and graphic designer are universal and also apply to the whole project team. Primarily, I recommend learning at least one of the project management methodologies, like the very popular SCRUM. It will help you to understand the specifics of working in a group.
In this article, I will draw attention to issues related to the whole team but also to those typical in collaboration between the mobile developer and graphic designer. I will start with establishing basic definitions, then I will talk about the project, and at the end, I will show you some useful tools.
Basic definitions
What’s the goal? It should be common for the whole team – to create an excellent application that will be used enthusiastically.
What about the perspective or standpoint? If the goal is shared, you can’t use your judgement to achieve it. And this is not easy because the solution more convenient for us won’t necessarily be the best solution from the user’s perspective. For example – implementing native navigation will take five minutes while creating an original one will take a week, but maybe the original will amaze users?
And the last definition – what is good design? Primarily, it should meet every business and functional requirement. This means, among other things, that it has to have a good User Experience (we covered this subject in some of our previous blog posts). Anyone who takes care of the UI must be acquainted with the UI/UX standards of the platforms on which a particular application will be available.
Starting the Project
First of all, let’s meet (not) for the first time! It doesn’t matter whether it’s a call, a lunch or going out for one or two beers. In my opinion, it’s always good to get to know each other before diving into the work: say who you are, what experience you have and what you expect. The other person should say the same things about themselves. Congratulations – the ice-breaker went well!
Now let’s establish the rules of design implementation.
- Does everybody know how the UI of the application usually behaves on different screen sizes?
- Fonts are the same, icons are the same, and a bigger screen contains more
- “Display zoom” effect – what we saw on the iPhone 5S, we see on the larger screen of the iPhone 6S. It’s a good option if someone has sight problems
- A graphic designer usually provides one design version in one resolution, so it’s important to decide for which device this particular design is dedicated. On this specific device, the size of elements and the spaces between them should be the same as in the design.
- Let’s determine how UI elements should behave on screens of different sizes. It’s not a problem when it comes to the device for which the design is dedicated – in this case, we can create even a pixel-perfect UI. On smaller or larger screens, UI elements may be stretched, scaled or centred but we have to make a decision about that.
Time for Collaboration
The moment of truth – the graphic designer provides further portions of designs, and the mobile developer implements them. Of course, problems are unavoidable, and the most common among them are listed below:
- Poor UX and design not adapted to the platform, i.e. checkboxes instead of switches on iOS or desktop-like design on mobile devices
- iOS devices don’t have a “back” button, so it’s crucial to allow the user to exit or return to the previous screen
- Text which is not falling within the screen or field – especially in multilingual applications. It’s good practice to include the most extended versions of text that can be displayed in the app (i.e. instead of “9.99” let’s put “9999.99”)
-
What’s in the design, should be in the application – it’s a trap! It’s common that the design describes what
should be included in the application thoroughly, including exact phrases.
In the beginning, that’s not a problem, but later, these phrases can change. And the graphic designer will have more tedious and non-creative work to maintain consistency between the documentation and the actual application.
Solution: The design should be treated as a template, and content should be housed elsewhere
- Lack of consistency in screen naming and versioning. Each screen should have its unique, permanent identifier, which follows a particular scheme, i.e. feature.screen.version. Unique and permanent because we will be referring to it in the documentation, emails, calls, etc.
- Less frequent problems like wrong asset sizes, redundant asset margins, poorly prepared 9-patch files.Solution: Dear programmer, use applications like Zeplin.
Tools
Have these tools in mind and check them out if you don’t know them already:
