Using Invision as the center of your project workflow

NOTE: THIS POST WAS WRITTEN IN 2017. OUR PROJECT MANAGEMENT HAS CHANGED A LOT SINCE THEN AND SOME OF THE INFORMATION PRESENTED HERE IS NO LONGER A REPRESANTATION ON HOW WE MANAGE THINGS

Ok, so we know about Invision here at the company for a long time now. We’ve been using it and have a paid account for years. And we mostly used it the way 90% of people use it. We made some designs or wireframes and we went to Invision to connect them together into a working prototype. We’d send that to the client or internaly, discuss it, iterate and move on. We knew it had some power features beyond that like commenting of prototypes, but we never really tried using them.

Living Design Documentation

About 6 months ago things started to change. We we’re working on Aurora which is our internal project. We decided to use the opportunity to experiment with our project workflows and try to improve them. From that point on Invision became one of the most important tools in our arsenal. It became our living design documentation.

It works this way. Let’s say we’re at the UX phase. A designer completes some wireframes. He then puts them into Invision and connects them into a prototype. He also uses the commenting system to write documentation. Everything on each screen that is not 100% clear what purpose it serves gets a a small pin with a comment detailing it. The designer is encouraged to overdocument. These pins have a yellow color indicating documentation.

Whoever reviews the designs can also place comments but these need to use a purple pin indicating they are regular comments. It’s up to the designer to resolve these comments. Sometimes these will be just plain questions asking to further explain how something will work. Other times they will turn into tasks for the designer. He is responsible for his design and managing the design documentation. If he does some revisions he needs to update the screens on the prototype. The prototype is always considered the final version of the design. If it’s not in the prototype it’s like it doesn’t exist.

Workflow feature

Another nice thing we started utilising is the Workflow feature. It’s basaicly a canban overview of your screens. It looks like a Trello board except you don’t have tasks – you have your screens. The workflow here is that the designer places his screens here and the screens are in a “needs review” state until all of the iterating and feedback gathering is fully complete. The project manager is the person who gives the final greenlight on the screens. When he  feels a screen is fully iterated and all comments about the design are resolved he moves the screens from an in-progress state to an Approved state. It’s important to notice that develepoers take part in the feedback phase. They need to review the screens from their perspective. They might notice things that are missing for a successful tech implementation, or things that seem good on paper but are not possible or hard to implement.

Moving from UX to UI

Eventualy once the project moves from the UX phase to the UI design phase wireframes will iterate into real designs and the designer will just replace the same screens with their designed versions. He then needs to update the design documentation for the screens where it’s needed. Everything goes into another round of revisions and needs to move from a “needs review” state into “approved” state.

UI Screens in the approved state are ready for implementation by developers. They move screens from the “approved” state to the “implementation in progress” state while they are working on a particular screen and they move it to the “implementation complete” state when they are done with a screen. Keeping this in sync from their side is important because of further iterations.

Everything in previous phases is intended to prevent the need for any iterations and design changes while the project is in the development phase. But sometimes this still happens. Developers can leave comments for the designer as they implement a design and the designer again resolves them. Sometimes this will result in screens getting further iterated. If this happens the designer moves the screen back to the needs review state and notifies the project manager. The project manager approves the screen and the developer moves on with implementation.

Conclusion

This sort of workflow might seem a bit tedious but it improves the quality of the project, removes uncertainties and makes sure everything is on track. It has worked wonders for us and improved the quality of the work we produce. It might not be for everyone but it’s worth a try.