What developers look for during design handover
As a designer, you think your job is 90% done after the design handover session to developers. Strangely, you always get lots of questions and change requests from the developers once you have moved on to a new project. What have you missed and why do you need to redesign the flow? Hopefully, this article is used as a guide to ensure designers prepare developers enough information to kick off development.
Navigation
Screen navigation should base on the purpose of the each screen. A common mistake made by designers is misusing contextual presentation hierarchy. There are two common native navigations in mobile which are push(with hierarchical stack) and present(pop up).
DON’T:
- ❌ present two screens one after another. When a screen is presented, it covers whatever the existing screen was, and to show another screen you have to dismiss the current screen (so that it’s back to the navigation stack) to do the next transition. This creates an ugly sequence of animations where the screens are flashing up and down to change.
<Present> Screen A → <dismiss> → <Present> → Screen B presents
(ugly!)- ❌ put a back button on a presenting screen. The back button is applied to push transition with hierarchy. Close or Cancel button is for presenting transition. Period. Do not use these two interchangeably.
- ❌ create a “shortcut” whereby the user miraculously jumps back to the first screen without dismissing the child screens. The navigation in mobile is quite different from web navigation. If you stack things in a hierarchical way, you shouldn’t abolish the stack right away, expects no animations of removing the screens just to jump to the desired screen. Mobile navigation doesn’t work that way. (unless with tab navigation)
Example: Users need to go through few screens to complete forms and by canceling it will immediately bring the user back to the main page. The flow of the screens has been considered in this case. - ❌ hide back button or change the navigation bar title after an action: mobile is not a web. Hiding a back button on push navigation is not encouraged.
DO:
- ✅ use push transition if you have to drill down into the hierarchy.
Negative paths and complicated use cases
It’s quite often that developers need to go through many rounds of clarification with designers. This is due to resources and time limitations on a designer to produce a complete flows of the product. Hence, there is tech refactoring(wasted efforts) to cater to new discoveries and paths.
DO:
- ✅ provide error paths like offline, user or system errors. Tell developer if you have different error handling like dropdown errors to indicate system error, redirect screen or prompt alert for an offline scenario.
- ✅ provide loading behaviors. It's often suggested by designers to use the native activity indicators but should it block the user from performing actions? what about content loading and form submitting?
- ✅ provide empty states. What should the users experience if they reject access permission? What happens if the list is empty?
- ✅ provide validation rules for all input. Do check with the product owner on the validations based on their system structure. Not for common validation rules like email field but fields that based on business context. For example, users can only input below<X> amount of money per transaction due to country regulations.
Native system behavior
Multiple system version and device size supports
It’s better than designers have the basic knowledge of mobile functionalities and human interface guidelines in both the iOS and Android platforms as they would know how to cater to system limitations as well.
DO:
- ✅ create two sets of flows (compatible and non-compatible) if you happen to use something that is only available on the latest system version. With something that is new or uncommon on most of your supported devices, you need to create a fallback flow.
Example: Notification in iOS 10 and above can provide multiple selections and image attachments. Imagine what will be available to iOS 10 and below user. What happens if user fail FaceID, TouchID after multiple attempts or not be available in certain iPhone/Android devices. - ✅ cater for small device screens too. The same design running on a bigger device size look “congested” due to the width and height limit of small device.
Example: The design for iPhone SE is very much different from iPhone Plus. Should the developer reduce the font size, maintain UI ratio with scroll view or some secondary functionalities? - ✅ create experiences are different on iOS and Android platforms.
Example: In Android, permissions are asked before an app is installed while on iOS it can be asked only when you are requesting access to the services.
Accessibility
It’s very common that accessibility is being pushed to the backlog as this is considered tertiary functionality and soon be forgotten if time resources runs out. Designer often doesn’t give clear instructions on the coverage of the accessibility.
DO:
- ✅ consider making accessibility into phases so that accessibility will not be pushed back due to resources limitation. Can the developers roll out accessibility little by little gradually in each sprints?
- ✅ know your target audience accessibility needs. Quite often designer just wants to implement accessibility for the sake of “covering it” and it does not serve any value to implement at all. Dynamic text is the most common accessibilities that developers are being asked to cover with not many requirements.
- ✅ provide high colour contrast, font weight and icons to represent state changes. Sketch is known to provide sharper resolutions. However it might not be obvious on different device displays. Not to mention colour blindness user.
- ✅ classify text styles (headline, sub-headline, body) according to the text hierarchy within the limit. (with iOS compatibility consideration as well)
DON’T:
- ❌ introduce more than 10 font styles for dynamic text (depends on minimum iOS version support). There are only 10 types of UIFontTextStyle markup supported on iOS.
Business Value
Developers have to produce the highest business values (priority is set by the product owner) hence they are most likely de-prioritize fancy animations or UI, putting functionality first. Don’t be surprised when developers come back to you and ask for a more feasible option.
DON’T :
- ❌ over-design native components as it’s hard to hack around the current system. Design is important for the look and feels for the app but if the development effort is way much more than the business value, there’s no point in spending lots of time to hack around. Hence, simplified design is requested.
Example: Gradient(left to right) for a navigation bar. This is a complicated design as the status bar color is expected to follow the navigation bar as well. In reality, the system doesn’t support such behaviour. - ❌ design something that has been handled by the system.
Example: Avoid offering a setting for opting into biometric authentication within your app. If biometric authentication is enabled at the system level, just assume the user wants to use it. If you implement an app-specific setting, the user may get into a state where biometric authentication appears to be enabled in your app when it’s really disabled systemwide. Same goes for notification settings at app-level.
- ❌ use different designs for same actions. One action should only has one consistent design in the app.
Example: Back button are not being standardized. - ❌ design complicated animations (like a progress bar). Drawing custom animation in code takes a lot of time. Developers have to consider the business value of it will bring: is it a luxury, good to have, or a must.
- ❌ adding different font weights in system native UI.
Example: Bold text in alert prompt. It’s really not worth developers time and not. It is even more challenging if there are multiple languages to support.
CONCLUSION
These are not all. I believe a team can create a better user experience if designers know what the basic concerns that developers have considered as they are going through the design. And hopefully, by sharing this, designers can reduce the need to rework project flows or make better use of saved time to craft a better user experience.
Amy is a software engineer. While she was typing out this article she was busy munching a handful of almonds. Here are her Twitter, LinkedIn and personal website.
