| Target release | July 2018 |
|---|---|
| Status | APPROVED |
| Product | |
| Design | |
| Development | |
| EIA | |
| QA | Omar Aziz |
| PMO | |
| Reviewers |
Goals
- Version control for designers.
- Have multiple designers be able to work on the same file at the same time.
- Have designers be able to work on multiple alternate solutions for the same feature (branches) at the same time, to ultimately select one (merge).
- A Mac and web app, sharing, comments and annotations, unlimited contributors, unlimited viewers (free), unlimited storage, guest account, collections, Slack integration and more.
- Review and decide for who wants licenses by end of trial, end of next week.
Tasks
- Review The Abstract Design Workflow
- Alpha test with DNOW IX with Rona & Jhillika
- Add Projects for Disney/ABC and access for reviewers team
- Test ABC IX Mitch Johnson (add or edit some symbols) with Chris Rinker (add or edit silent critique components) and merge your individual branches to review process
- Test Visual Design David Avery with Ulisses Guimaraes for Web platform (whatever test they choose)
- Review Design Systems features, and the Abstract blog.
- Ask for feedback in Design Team Meeting
- Setup Slack integration https://datgdigitalmedia.slack.com/apps/A2C37QFN1-abstract
Background and strategic fit
2017 Mike G. + Angela began discussing version control for the designer-developer workflow as a basis for an eventual true designer-developer design system (complete with developer components). Mature design organizations require version control in order to achieve such goals. Separately a need was identified to enable more than a file hand off between designers working in the same role on the same project and platform.
Upon review Rona recommended Abstract, and we came to learn the tool is highly recommended and pre-approved for Disney use by our pals over at DTSS. We began a 30 day trial.
Assumptions
- No group would need to adopt the tool, each group can independently choose to use or not, unless it's made as our org decision
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | ||||
| 2 |
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.
Abstract Pro Tip
Commit every time you make a change to your branch like a new exploration, when you finish a chunk of work or when you change direction.
Pros
- Abstract works fine as it is. Start to use it and it will work in few seconds!
- Everything is automatically saved on the cloud
- A simple plugin in Sketch permit to commit changes in a quick and easy way
- You can create branches and manage the status of the work
- You can merge branches by choosing the correct version if there are any conflict
- You can collaborate actively with the rest of the team (and all the user that have access to your repository)
- You can send (currently only) Artboards url’s to your teammate or colleagues and they can look at your work and comment it
- You can follow all the history of a project
Cons
- Large file saving is a bit slow (because the App needs to translate the entire file every time there is a save)
User interaction and design
Branches help you and your team keep your files and edits organized into distinct and separate lines of work. Merging allows you to bring those edits together into one place once the work is finished. In our discussions with teams before building Abstract, everyone was merging files together, but they were doing it manually by copy-and-pasting between files. The work was so sizable on some teams that there was a team member whose sole job was to be the maintainer of the design system. Abstract helps automate this laborious task and gives powerful tools to offer fine control over the process. Branching and merging are the main ways to keep all the work in its right place.
What about Master?
All branches can merge into one of two places: Master or the branch they branched from. We see Master as a place for finished and approved work, the source of truth for the project. Merging work into Master signals that it's been approved and ready to be used and implemented by the rest of the team.
How should teams arrange the merging process?
Most teams should have their work reviewed before merging. Each team probably has their own methods for approving work based on the team and company size, and how design works with the rest of the organization, but we suggest that individual communication and a thumbs up from one other person is best when merging into each other's branches, but larger, team-wide reviews occur before the work gets merged into master.
What kinds of cool stuff can I do with merging?
All kinds of things! Abstract gives you a lot of control while merging by reaching into your Sketch files to merge individual artboards, symbols, and styles inside of those files. Most of the designers we've talked with were already doing this merging by hand, and found the process difficult because they had to remember which elements were edited. Abstract tracks all your edits to automate the merging process.
Merging opens up exciting new ways to collaborate with your teammates. For instance, you could create a branch to revise a type hierarchy, while your teammates branches off of you to work on the project's color palette. Once they finish their work and merge into your branch, you would then have files which contain your type choices and their colors.
Analytics
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
|
Not Doing
Usability
