Progressive Design in the Abstract
Using Abstract to systemize the way we practice design.
At Progressive Leasing, a product designer’s job is much more than just pushing pixels.
Product designers at Progressive Leasing are expected to work with Product Managers and Tech Leads in order to conduct discovery, update stakeholders, document decisions, interpret feedback, and then to handoff the work for implementation.
This is why we chose to use Abstract as our design hub. It’s how we version control sketch files, collaborate on designs, and maintain a source of truth for final designs to be implemented.
As we added more and more product teams to the tool, we realized the power of the tool was in systemizing our design efforts. So we set out to document how we use the tool to help teams on-board and get going with Abstract.
We were very inspired by Outlook’s article on how they use Abstract. And while our needs for the tool are different than theirs, it helped us format documentation not only around how we use Abstract, but also why we use Abstract in the way we do.
So here is a summary of how we are using Abstract at Progressive Leasing.
Step 1: Create Sketch Files
You have three options to start designing. You can create a new Sketch file, you can create a branch on an existing Sketch file, or you can continue work on a existing branch.
Creating a New Sketch File in Abstract
We always create new Sketch files from within the Abstract hub. To create a new Sketch file, select the “file” tab on a master or branch, and click “add file.”
We name our Sketch files for the visibility and navigation of all our partners in product management and development, so they can easily find and reference our design work.
Sketch File Naming Convention
The sketch file name starts with the Product Name, and is followed by either the Breakpoint or the Design Initiative, depending on the type of file.
Sketch File Types:
Emojis clarify the purpose of the file and help other members of the design team quickly locate files inside of Abstract.
(*Quick Tip*: To access the emoji picker on the Mac, try ctrl+command+space.)
- ⚙️ — (gear emoji) production files, for high fidelity product UI.
- 🛠 — (hand and wrench emoji) working files, for exploration + collaboration + iteration.
- 🔍 — (magnifying glass emoji) discovery files, for all discovery related design.
- 📲 — (phone with arrow) prototype files, for making prototypes for tests.
- 💡 — (light bulb) reference files, used for understanding and context.
- 🗄 — (file cabinet) archived files, old and outdated work.
- 📍 — (round pushpin) design ops files, files like this one.
When should I create a new file?
You should have a file for each breakpoint on your production products. Create new files every time you start discovery on a new feature, create a discovery file to do flows, audits, and wires in.
Step 2: Organize Sketch Files
File organization is not just good design practice. It’s essential for other designers to be able to jump into your files and navigate your work, and vital that stakeholders can easily find the screens they need quickly.
Production File (⚙️) Best Practices
We believe organizing our production files is crucial to successful implementation of our designs into production:
- Sketch pages should be named by the section of the experience.
- Screens should be organized into rows based on a flow.
- We put screens on a grid and number screens for easy consumption.
Working File (🛠) Best Practices
Using a file to do iteration and exploration means that organization is not as vital as our production files. Naming your artboards before duplication is helpful. Avoid deleting your work so the progress of the exploration is evident.
Discovery File (🔍) Best Practices
We believe making our discovery files consumable will allow our learning from the exercise to be easily shared.
- Pages should be named for the type of discovery exercise.
- Screens should be named with clarity for consumption.
Other File (📲,💡,📦,📍) Best Practices
We believe other files should be organized so other designers can understand and work in these files, but leave naming your pages, screens, and layout up to individual designers.
When should I cleanup my files?
Try to organize as you design, but at a minimum make sure your production and discovery files are cleaned up before you merge a branch.
Step 3: Create a Branch
Branching lets you make changes in Sketch without altering the original files. It’s important to use a clear branch name for the thing that you’re working on to give others plenty of context on the work.
Branch Naming Convention
The branch name should include both the reason we are creating a new branch and follow this with the details of design work we intend to do.
We name our branches in the conventional version control naming convention, like how Bitbucket or Git does naming. We do this to align with our technology partners and give them better insight to the value we are providing.
The Reasons:
Ask yourself “Why am I creating this branch?”
- Feat — use when creating a *new* feature.
- Update — use when updating an existing feature.
- Refac — use when cleaning up files (or) updating UI.
- Fix — use when fixing an issue with a file.
- Explore — use when iterating or exploring.
Examples:
- feat/Make a payment
- update/Adding new payment method
- refac/Renaming artboards
- fix/Linking prototype screens
- explore/Iterate on the phase four screens
When should I create a branch?
Branching happens automatically when you open and make changes to an existing file. Abstract will ask you to either create a branch or to open the sketch file untracked. Untracked files do not save.
Step 4: Use Branching Wisely
Branching is a powerful way to work with other designers’ work. It can also get messy and unmanageable very quickly. Follow Progressive Leasing’s best practices when it comes to decisions on Branching.
Branching Best Practices
Branches should really evidence the designer’s intention to change screens. Following the naming conventions will help, but it’s important not to branch when you should actually commit changes to an existing branch, merge a branch into a parent branch, or when you should delete a branch entirely.
Avoid these branching behaviors:
- Nesting branches on your own branch more than once.
- Use branching the way we should use commits.
- Creating a new branch for every new working session.
Sometimes you’ll have to update from the parent branch before you merge. Be aware of the conflicts that your merge might have, and work with the other designers in the branches above you if you have any concerns with conflicts.
While Abstract is a great tool for a design team to have access to each other’s work, see progress on designs, and stay up to date on other’s efforts; it is not a replacement for face-to-face coordination when two or more designers are working on the same file at the same time.
When should I merge back into a parent branch?
Merge back into parent when you have finished what you added the branch for. A good rule for when to merge back to parent is look to merge before Abstract labels your branch “Stale”.
Step 5: Commit Changes
Commits are like super saves with context. When you commit you write a short description of the edits you made. This enables your team to see your commit history and know what changes where made, when, and why.
Committing
You can access the commit feature in both Sketch.app and in Abstract.app. The Sketch button at the botton of the canvas is the easiest way to commit. You can always roll back changes and access previous versions. There is virtually no downside to committing often.
Commit Naming Convention
Begin with a short summary of your changes using the imperative present tense to be consistent with generated messages from commands.
If needed, use the body of your message to provide detailed answers to the following questions:
- What was the motivation for the change?
- How did it differ from the previous implementation?
Committing Helps the Team
When we commit well, it’s easier for the team to have visibility into the work going on in each project and as a design team as a whole.
When should I commit my work?
There is no hard rule for committing, but at Progressive we believe committing more often is ideal. At a bare minimum, please commit work at least once a day.
Step 6: Merge Branches
Merging branches can be a a stressful experience if we don’t branch and merge with intention and purpose. Make sure to communicate with other designers on the project if you have concerns merging branches.
Before Merging
A good rule of thumb is to have your work reviewed by another designer before merging. Developers call this a “pull request”, but in Abstract it’s titled “Request Review”. More on this process in Step Six.
If you have new screens to add to your production file, move them from your discovery file or working files into your production file. These screens should meet the Sketch hygiene standards for production files before you merge your work.
When to Merge Back Into Master
Merge your branch into master once your screens make it into production. This creates a new version of master that reflects what’s in our user’s hands, which makes it perfect for stakeholders and even Dev to reference mocks of the production files.
Resolving Conflicts in Branching
Any designer can branch in a project, or even branch on another designer’s branch. If the correct naming is used for branches, commits, and files, it should be easy to see what others are doing and why.
When you look to merge your work, make sure to work with the designer that the merge will effect in order to align on conflict resolution.
Should I worry about merging messing things up?
All branches have to merged eventually. Don’t be afraid to merge. All actions can be undone. Conflict resolution in Abstract is simple.
Step 7: Use Collections
Collections are the best way we can share out or work with stakeholders. Collections can span multiple files inside a project, and update automatically. This makes them preferable to links to indvidual artboards or sketch pages.
What is a collection?
Collections are a combination of screens across the project’s sketch files. Collections are the primary way we should package our work for consumption by stakeholders, as the experience is optimized for consumption, understanding, and context sharing.
Collections for Stakeholders
In Abstract, you can share links to projects, entire design files, whole sketch pages, and to individual artboards. In order to reduce complexity and confusion, we should try to stay away from sending non-designers anywhere in Abstract except to collections or individual artboards.
Collections are ideal for sharing work with others because:
- Artboards from any file in the project can go into a collection.
- Collections update automatically from commits (and even merges!)
- Collections can be presented more easily and collections flows are more understood.
- The viewing experience in a collection is guided and less complex.
What flows should I include in a master collection?
The core flows of an experience should live at the master level. Like all files in master, these experiences should reflect what’s in production.
Step 8: Request Review
Requesting reviews from other designers and stakeholders is a great way to make sure you are on track to deliver the right solutions in your designs. Use Abstract’s “Request Review” feature to validate work with others.
Using Status for the Right Kind of Feedback
When you work in Abstract, you can communicate your progress through Branch statuses:
- Early work (not ready for input)
- Open for feedback (not official review, but open to input)
- Review Request: an official request for feedback
Use Collections for Reviews
Review in Abstract is the best done through collections, as context and a description of work is easily available to the person viewing the work. Requesting feedback on an entire branch or file is overwhelming and the feedback you’ll get won’t be as valuable.
Things To-Do Before Requesting Feedback
- Write a thoughtful Collection description with contextual explanation.
- Ask reviewers to use the annotations feature on the screens they review.
- Involve the right people at the right time, using Review Requests.
Who should review my work?
At least one other designer should formally review work before merging. Involving more stakeholders in review is preferable.
Download this cheat sheet sketch file and adjust it to fit your teams needs!
Written and edited by the Progressive Leasing design team.
Want to design and build great products that help empower credit challenged consumers? Join us!
