Abstract ways—how we use the abstract app at Innovaccer
While there is an ongoing debate around Figma vs Sketch, we have chosen our side. And it’s the later one. The reason, although, has got very little do to with the Sketch itself. In 2017, before Figma was popular, we were also one of those designers who struggled with versioning our files
In a struggle to end this problem, on Jun 28th 2017, we began our experimentation with the Abstract app. For developers turned designers adopting Abstract was a natural choice. And it didn’t disappoint us.
In this article, I would focus less on the features of the Abstract app. Since the Abstract team’s blog does a great job themselves (links are in the footer)
The focus of this blabber is going to be how we have used the features of the Abstract app in the last 3 years (gosh!) and perfected (nearly) our process to scale design in an enterprise. Hoping that this would inspire others who are experiencing the same challenges.
Projects
A project is specific to a product line.
Different sketch files can be created within a project as features or demo requirements such as Demo A, Demo B, Pipelines, Datasets, Goals, Tasks, etc.
To create a new sketch file. Click on the “Add File” option and choose to add a new sketch file or import a local one. You may also create/import a new file as a library, the details of which can be found here.
Create project-specific local libraries!
- Each project may have its own library to manage local resources better.
- Push patterns to the local library (helpful for demos).
?? Use libraries across projects to increase the scope of reusable components. Very helpful when you have your design system integrated with Abstract.
Branches
To edit a file you must create a branch. For a first time user, it may be difficult to name branches so here are some effective ways of naming your branches:
- For Stories: <Sprint No.> + <Working Title>
- Sprint 01 — Initial setup for the project
- For Features: < Feature/Component> + <Working Title>
- Global Search — Section Title — Behavior
- For Bugs/Quick Improvements: <Ticket No.> + <Feature/Component> + <Working Title>
- NCR-1320 — Global Search — Section Title — Behavior
By default, the Abstract will prompt you to create a new branch when you want to edit or add something.
?? A lifespan of a branch should be a feature specific — usually an epic and then branch it further to work on stories withing that epic.
Untracked File: A file from someone else’s branch or master, opens up as an “untracked file”. This file will not be saved back to Abstract — so no changes you make will be available via Abstract. Please only use this feature to quickly demonstrate something that should be saved back to the Abstract and is not relevant for the project.
A typical branching nomenclature is as follows
{PREFIX} {ISSUE-ID or MODULE NAME} — {FEATURE NAME or DESCRIPTION}
- Prefix makes it easier to identify and understand the purpose behind your branch
- An issue ID or module name could be the Jira ticket number or the name of the specific module to understand the purpose of the branch.
- Feature name or Description could be a one-two word descriptor of the main item being worked on.
Types of Prefixes:
feat or ?? Feature which you are adding or expanding hotfix or ?? A quick fix encountered while review bug or ?? Bug fix or experiment lab or ?? Throwaway branch created to experiment
Branch statuses or reviews
To ensure transparency, it’s a good habit to update the branches to its appropriate status:
- WIP — automatically all branches are WIP when created
- In Development — merge/close branch after dev is complete otherwise branch out for hotfixes
- Request review — request reviews once an iteration is complete
- Paused — if the branch is on hold. Archived paused branches after the end of the quarter.
Ask for reviews and feedback whenever required by clicking on the “Request Review” button and selecting one of your team members for review.
- Select your design lead to verify the UI and workflows between your sprint.
- Select the design system lead to verify new or updated components.
- Select the parent branch’s owner in case you need to merge it back into the parent.
Commits and Merge Branches
- Committing means saving the changes you made back to your branch. Hence, it is essential to add a commit in a branch whenever you make a change.
- As a rule of thumb, add a commit whenever you think a particular iteration is complete. You may also add commits in between as “WIP” aka work in progress. So that others are aware that this “commit” might be broken. The idea of perfect commits is to be able to extract the screens at any commit level.
- Be very specific of the changes you have made within a commit so that it is easier to read while looking at commits history.
Commit Patterns
The commits practice, in general, is different from what we follow in the git (dev) world, and the major reason behind that is the difference in the tone of the product we use.
Abstract uses the fundamentals of the Git world. However, it is a product made for designers and not developers so it works slightly differently. Git uses the imperative mood when it creates a commit on a users’ behalf — “Merge branch-name into parent-branch”. But, the Abstract uses past tense while creating a commit — “Merged branch-name”.
So to make it easier to understand, in Abstract, a properly formed commit subject line should always be able to complete the following sentence:
- In this commit, I changed the layout of the card
- In this commit, I pulled in library updated
- In this commit, I fixed merge conflicts
- In this commit, I created provider referral workflow
- In this commit, I updated worklist filters
In most cases, you can leave out details about how a change has been made. Although, in case you do feel like more information should be added, use the description box to add the details.
Usually when you have made a major change such as added/modified a workflow or created/updated a component. Since the screens update information is generally self-explanatory in this regard so just focus on highlighting the reasons why you made the change in the first place.
A good practice is to start with the problems which were identified before the change and then talk about the changes made and why you decided to solve it in a particular way.
Things to remember while merging
- Resolve all issues carefully while pulling the parent’s updates. The easiest way to do this is to remember the changes you’ve made and quickly pick your parent’s changes that don’t affect your work. Be sure to check if pulling any changes has affected your sketch files. If it has, fix those changes and then add another commit.
- Merge your branch to the parent only if the parent is owned by you. Otherwise, ask the owner of the parent branch to review your branch. Merge branch once approval is received.
- Merge to master only if it is approved by the senior designer. If there are some changes, create a “UXDEBT” and then merge your branch into the master.
?? Remember to merge your branch to master after sprint ends or after an epic is complete.
Doing a review
When a review request pops up as a notification, it means that it is time for you to take a look at the changes and the comments. When you are done with that you have two options on how to proceed:
- Approve changes
- Request changes
For both options, you can send a message back to the creator and advise them to take a look at the comments you made.