DisneyNOW Design : Zeplin

Goals

• Setup Zeplin so that it best supports our immediate project needs
• Support both a view into DisneyNOW today, as well as the next "release"
• Define the cadence for our design team

Tasks

• Discuss with Davery & Ulisses
• Connect Mike G. with David, and Dave
• Refer development leads to Visual Design for Zeplin administration and management
• Identify new DisneyNOW Zeplin manager: David Avery
• Evaluate Abstract Inspect vs Zeplin https://www.goabstract.com/blog/introducing-inspect-where-the-file-is-the-design-spec/

Background and strategic fit

Our engineering team is extremely grateful for Zeplin. Sketch and Invision meanwhile have added the same feature into their tools. We have no desire to remove any efficiency at this time, however understand that we should continue to evaluate our designer (to development) workflow to see when we should make the move in the future.

Today, our goal is to adapt the Zeplin project management into a manner that better supports the needs of our development teams, many of which are becoming more and more aligned to agile and scrum principles. e.g. sprints, etc. Previously the ask was "version control" but we've expanded the need to the ability to design adeptly across sprints/releases.

Assumptions

• Design's Zeplin structure will map to our dev's project needs
• Zeplin is only being used as an inspect tool... we need to know all the ways our partners use Zeplin so that we can use this as a user requirements list for our new tool evaluations.
• Sprints or releases are the way to organize Zeplin projects... or is there a better way? One project where Zeplin ties to a JIRA ticket?

Guiding Principles

• Review "How We Set Up Zeplin"
• One sprint = One project e.g. DNOW 3.1/Web or DNOW Web 3.1 (sprint don't align across platforms)
• Tag Zeplin screen with JIRA ID e.g. WEBDNOW-1045
• As the stories get picked up by developers during the sprint, they can easily find the relevant designs by using the ID of the current sprint, what platform they work on, and the ID of the story.
• At the end of each sprint—if we have managed to avoid spill over—we can archive the project in Zeplin. 
• If we for any reason need to backtrack, we either re-activate the project containing the affected story, or go straight to the actual design files which we version with Abstract.

Requirements

Research

Points below via Git repository for designers as you’ve never seen: Abstract (+ Sketch)

• We can work together on the same file.
• We can review the differences and decide which one is the right one.
• We can merge many branches in a Master file (so that we save many time instead managing by hands new Artboards, Symbols and Styles).
• We can collaborate through the team with comments and suggestions during the team work.
• We have a version history so that we can move through the timeline, opening, editing and reviewing the design more and more time.
• We have a clean, stable and updated Master file.
• We know the status of the work for the several tickets we are working on.

Pros

1. Abstract works fine as it is. Start to use it and it will work in few seconds!
2. Everything is automatically saved on the cloud
3. A simple plugin in Sketch permit to commit changes in a quick and easy way
4. You can create branches and manage the status of the work
5. You can merge branches by choosing the correct version if there are any conflict
6. You can collaborate actively with the rest of the team (and all the user that have access to your repository)
7. You can send (currently only) Artboards url’s to your teammate or colleagues and they can look at your work and comment it
8. You can follow all the history of a project

Cons

1. Large file saving is a bit slow (because the App needs to translate the entire file every time there is a save) [the team is working actively to improve this]

User interaction and design

Analytics

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing

Usability