But wait, now, in order for your validated design to transform into a reality, is InVision really going to help remove the bridge between Designers vocabulary and Engineering?
Nope. If you don’t want tot confuse upside down your developers colleagues, you should start by not only having a basic html/css/javascript knowledge, but also key concepts when it comes to Product Components and Features:
- Definition of a Component.
- Constraints.
- Use Cases.
Developers, by default, are way more structured than right-side creatives (designers).
Definition of a Component (for instance: Dropdown menus, Right Clicks, Unordered Lists): Basically, is to state the purpose of this element and how many types there are.
Constraints: When and where should appear that magical feature that users will love? When it should not? What is the Information Architecture (logic) behind? What is the generic spacing between text boxes and paddings?
Use Cases: Use cases are key actions accomplished by the user (displayed visually in a diagram) when they are navigating through the app. This is crucial to understand so that developers are able to structure a clear plan for the Back End Development process.
To learn how to create Use Cases, I recommend this video from Lucidchart:
In our team, we use Confluence, by Atlassian to manage the documentation so that new members of the team can get a clear view of the user’s flow
What are the key benefits of documenting all the components and assets?
In conclusion, if you are part of a small team of designers or you are the ‘solo’ designer at your company, I strongly recommend using this methodology to help you have Empathy, not only for your users, but for your colleagues too, especially if they are the ones who turn your dreams into reality.