Sharing Work

Guide for sharing work and requesting feedback from the team.

Overview

Providing and reviewing feedback takes time. These guides make the process consistent and help it become routine.

Project Life Cycles

Projects undergo multiple stages before reaching development. The stages are non-linear as goals and feedback can reset a brief back to the start. Request feedback in the early stages and obtain a final review from the broader team before delivery.

Feedback v Reviews

Design critiques are a constructive part of the design process. Regularly asking for input from the team provides a different viewpoint or, at the very least, a second set of eyes.
Feedback and reviews are two different levels of critique.

Feedback

Occurs early in the design process. The level of critique is high. Designers seek input during the 🚀 exploration phase and ensure alignment with the broader team.

Reviews

Reviews are not a request for feedback on completed work. Reviews usually occur at the end of the design process when work is ready to move to 🚦 In Review. The review process is more thorough. Use the extensive checklists as a point of reference.

When asking for feedback or a review, share a link to the Figma file in the Team UX Show and Share channel.

Accompany links with the following notes to provide team members with context:

Project Title

Project Status - 🚀 Exploration, 🚦 Final Review etc

Description of critique required

Highlight key points to check out in the file

Identify known issues or work in progress

Provide links to live or existing points of reference

Deadline - include a timeframe as a cut-off for any comments

Video Intros

Loom Sample

Screenshot of a Loom walkthrough

Providing a short presentation of the work allows for more detail when walking through the problem and proposed solutions. A distributed team may not always be able to attend review sessions in person. Videos enable a broader audience to review work at their own convenience.

Loom, QuickTime, CleanShot, and other video tools allow screen capture and recording of voice. It is best practice to keep demos concise and to the point.

Sample Slack Comment


                                                        
                                                        
                                                            Project Title
                                                        🚀 Exploration 
                                                        
                                                        This is an example project summary at the exploration stage. I'm looking for some early feedback on these concepts.
                                                        
                                                        Key Points:
                                                        - Item(s) added
                                                        - Change(s) made
                                                        - Idea(s) tried
                                                        
                                                        Known Issues: This or that
                                                        Out of scope: This is out of scope
                                                        Figma Links: <Link>
                                                        Deadline: EOP Friday 25th December

Sample Comment for Slack show and share channel

Plan and allow at least a week for the team to provide feedback on your files, particularly final reviews that require a more detailed inspection.

Providing Feedback

Add comments within the Figma Files for context on the work. The creator will receive a high volume of comments. Ensure all comments are concise and constructive.

Provide comments as complete sentences that relate to the work or thread. One-word statements do not help anyone.

When making changes based on a comment or completing it, always add a tick and then resolve. Otherwise, explain why no changes are required and resolve.

Tag specific squad members using the @username syntax. Links and emojis can also provide tone or context. Use threads to contribute to a conversation within context.

Peer Reviews

Sometimes, requested feedback can be more detailed and in-depth. A colleague may want final designs checked before handing them over to developers.

Use this time to ensure that the work meets the project standards or wider Compound guidelines.

Every platform is different; confirm the boundaries of the project that is being reviewed.

Check that files are organised and easy to read

Correctly name all frames

Where a page uses a key, make sure it is clear and consistent

Check pages, sections, and frames can all be navigated in inspect or dev mode, where relevant

Identify any potential issues that may not eventually meet the design system guidelines

When component libraries are used, ensure that the latest versions of components are utilised. If components are not the latest, include the reason in notes for context

Ensure the correct Figma styles are used:

Does the design use platform-specific typography?

Is a typographic hierarchy in place?

Does the design use the correct design tokens and styles?

Check that layouts align with the 8px soft grid and visual hierarchy guidelines

Unless highlighted, all designs follow the small viewport-first approach

Depending on the stage of the work in the design process, highlight any other issues that do not meet guidelines for good file management

Remember, files must be accessible to any other squad member. Consistency reduces the learning curve

Further Rounds

Asking for critiques often is not a one-time process. It can be necessary to reach out to the team again.

Follow the above steps, but update the context:

Provide an updated description of the critique required. Cite key changes that were taken on board and applied

Clear out previous comments by deleting or resolving them

Repeat the processes above