Definition of Ready that designers should be compliant with before handover of design to implementation

Where this topic comes from?

I work very closely with designers from different parts of our great globe and this is the best that I have got in my professional career. I learn a lot from all of you and become a better expert that now can look at the piece of software that is going to be created from a different angle. I see new features and new products in the way how designers would like to have them to solve given problems. Thanks to this I can make decisions upfront about technology, solutions to use, potential limitations, and so on. In other words, I find tech solutions that suit in the best possible way solutions that are under research and design.

I always encourage the dev team to engage in the design phase of every project I take part in. I feel very confident saying that we developers fulfill the design processes with good practices, with feedback based on experience that we have got in the development of other projects. Thanks to the tech pair of eyes, designers get a complete spectrum of edge cases they usually don’t consider.

Ending this short brief intro I would like to share with you a checklist that every designer should have in mind during their daily routine 🙂

Is your design Ready To Develop?

Design System

• No, any data? Do you have a placeholder?
• Some data? This is a most often happy flow that you cover at first
• A large amount of data? You can cover it with an infinity scroll, pagination, or some other behaviour.
• How to make the items unique in the collection? How to make them identifiable? If you present a list of people by name and surname and have 5 people with the same name Jane Doe, how to distinguish them?

• Empty state? Placeholder with a suggestion, hint?
• Long, long text? Should it truncate, or allow scrolling, or break the lines?

• The user doesn’t fill it at all
• User populate field against some pattern
• Make form submit CTA inactive or active?

• This is very tricky and you must be very careful here as there is a really small amount of space

• Your change language CTA must be accessible, smooth and easy to use
• Analyse if your product should now or in future will support RTL languages like Arabic
• Default language. There is a high probability that you’re not going to have a complete translation for each supported by the platform language, then probably you will use a default language, or have some other idea.
• Think about each static content, labels, titles when you design them (probably in English) to look good and work like a charm. However, if you support other “long wording” languages like german or some African langs there is more than a high probability that it will break your layout and they won't fit in the space you designed initially.

• This avoids accessibility barriers to scale spacings, margins, and fonts 2*

• Communicate to the user when the application retrieves data with some spinner, skeleton or some other progress component. This is even more important for apps that work on blockchain under the hood as each such operation may take ages!
• Communicate to the user about successes or failures of actions that have been made on submit where the action happens in the background and the form is not visible any more. Use Toast?

Mandatory pages

Processes