Introducing Review Requests and Comment History
A scalable, lightweight workflow for collaborative design reviews.
As design increasingly becomes a core function of every organization, large and small, collaboration around design is becoming more cross-functional. This creates challenges for internal design teams, agencies, as well as stakeholders working on product, engineering, and marketing teams.
As teams attempt to collaborate, we often find feedback siloed in disparate systems: email, Slack, etc., making it hard to interpret and make a confident go-no-go decision. Stakeholders lack the clarity to know what’s ready for feedback and how much feedback to give. Meanwhile, designers are left in limbo, wondering if their work is good to go or in an ambiguous and frustrating state of “review.”
Establishing a clear, consistent process for design critique and review while maintaining agility becomes critical as teams scale. Introducing more transparency into the design review process means feedback can be incorporated earlier, all stakeholders have context for decision-making, and the finished product can ship faster.
With features like Inspect and Collections, we’ve highlighted how Abstract can become your central hub for design. Now, with the introduction of Review Requests and Comment History, we’re rounding out your workflow by providing two lightweight ways for both designers and stakeholders to communicate around a project and get it across the finish line. Both of these features are available in the desktop and web app, making the process more open to stakeholders who may not have our MacOS App installed. Review Requests are only available for Business/Enterprise plans.
A transparent review process with Review Requests
With Review Requests, you now have a clear and straightforward way to signal when you’re ready to kick off the review process and specify who you’d like to be a reviewer. By centralizing your design reviews in Abstract, both designers and stakeholders have a complete record of all of the changes made. This includes:
- Who requested changes (and why)
- When designs were approved
- Who approved the designs
We know that everyone’s review process is different, so we focused on creating a lightweight way to approve a design or halt the process and request changes.
To make the most of this feature, we recommend adding an agenda item to your kickoff to discuss how you’ll approach reviews so roles and responsibilities are clear out of the gate.
Comment History, because designing as a team is a conversation
Half of design is the conversation around it. Seeing the evolution of work isn’t just about the visual side of things. To fuel more collaboration, we knew that we had to make communication around the work centralized. And we had a hypothesis that showing the full comment history for Layers would lower the barrier for teams working together more fluidly.
Like Review Requests, Comment History adds rich history to work, giving all collaborators insight into the why behind certain changes. When a reviewer has been signaled to jump into a Branch, she can see all the comment history in the same place.
Before, comments would get stuck in different Branches, and collaborators would often lose track of previous discussions. Rehashing a conversation was also a challenge, especially when changes had already been incorporated. This update brings these conversations in one, easy-to-flow thread, making work more focused and efficient.
Using Comment History and Review Requests together allows you to keep work moving forward, have clarity around developing changes, and alert the right people at the right time when input is needed or a change is ready to be merged to Master.
In Abstract, Branches are used for work and ongoing exploration that may or may not end up in the final design. Before Review Requests, you’d have to send teammates and approvers a link to a Branch or Collection to get a thumbs up on progress, or to ask them to provide feedback on your work. Now, you can request a review from a specific individual — a peer or a stakeholder — when the time is *just* right. Here’s how you do it:
Navigate to the Branch Overview tab. From here, you can add a Summary to provide context for the Review. In this section, you can add text, markdown, links, and documentation that will be relevant to the individuals you’ve asked to review your work.
On the top right of your screen in the Mac or Web app, you’ll see a green button labeled “Request Review…”
You can add multiple users as Reviewers to notify them and allow them to either approve or request changes to your work.
At this point, you can assign specific individuals as Reviewers. They’ll receive notifications that your work is ready for review and can either approve or request changes at their convenience or in a scheduled design review meeting.
Once this Branch has been approved, you’ll receive a notification and clear indicator that it’s now appropriate to Merge to Master.
When you’re managing a team or large project, it can be tough to stay on top of ongoing work and provide a stamp of approval. Now, you’ll be able to see an overview of Branches ready for review both on the Mac and Web app. When you’re assigned as a Reviewer, you also have a couple of options to approve or request changes.
Here’s how to approve or request changes:
You can locate Branches that are assigned to you in the Reviews tab at the Organization level. From this tab, there are two views, one that includes all Branches up for review in your Org labeled “All Reviews,” and another that will only show Reviews you’re assigned to. You’ll see them labeled as“Assigned to Me.” You can also filter these views further by selecting a specific Project in the top right of the Mac or Web App.The second way of locating a Branch ready for Review would be to just follow the notification from Abstract (Email or In-App) to the appropriate Branch.
Once you’re in the appropriate Branch Overview, you can view the changes made to your files as a Collection or in the Files Tab. From the Branch Overview, Abstract will surface any Collections a designer has created, along with files that have changed.
Now that you’re familiar with the changes your team has made, you can either approve these changes or request feedback through the “Review” option in the top right of the Mac or Web App.
If you decide to request changes, your team will be notified and you’ll be provided the opportunity to review the Branch again. Let’s request some changes in this example.
Once a Reviewer has requested changes, the designer will be been notified and provided with the necessary context to update this Branch before merging.
Now that the designer has affected the necessary change, as a Reviewer, you can update your status from ‘changes requested’ to ‘approved’.
Now, designers have a clear stamp of approval on their work, while you can continue to stay up to date with how a project continues to evolve.
On an average day, our team of 15 contributors commits changes to 10 projects or more. Review Requests allow us to quickly get feedback from the right collaborators, stakeholders, colleagues, without asking everyone to watch everything at all times.
Matthew Ström | Design Director at The Wall Street Journal
We believe that to move forward, design demands a codified process. With these features, we’re further supporting our vision of being the central source of truth for design, across your entire organization. We’d love to hear your how your team is using these features: share your stories in our Spectrum community and on Twitter. 🙌