Sharing work regularly with the extended team helps maintain alignment in brand, component usage and customer journeys.
Providing and reviewing feedback does involve a time overhead, however, the following guides aim to make the process consistent and eventually second nature.
Projects go through a number of stages before they reach development. The stages are non-linear as goals and feedback can reset a brief back to the start. It is important to request feedback in the early stages and a final review before delivery from the wider team.
Design critiques are a constructive part of the design process and asking for input from your team regularly provides a different view point or often just a second set of eyes.
Feedback and Reviews can be considered two different levels of critique and should be considered.
Feedback - Is early in the design process and the usual level of critique is high level and often designers are looking for input at the 🚀exploration phase and alignment with the wider team.
Reviews - Reviews are not a request for feedback on the work that has been completed. They usually at the end of the design process when work is ready to move to🚦 In Review. The review process is more thorough and our extensive checklists should be used as a point of reference.
When asking for a feedback or review share a link to the Figma file(s) in the Team UX Show and Share channel.
Accompany your links 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
Providing a short presentation of the work allows you more detail to walk through the problem and proposed solutions. With a distributed team that is not always able to attend review sessions, this allows you to give a wider audience in their own time.
Loom, Quicktime, and other video tools allow you to screen capture and record your voice. Loom has the advantage of having a 5 minute limit, keeping demo's concise.
This is an example project summary at the exploration stage. I'm looking for some early feedback on these concepts.
- 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
Aside from what has been requested from the creator this time can be used to make sure work is meeting the standards of our wider design system guidelines.
- Identify any potential issues that may not eventually meet the guidelines of our design system. You can use the review checklists as reference
- Make sure that the latest versions of components are being used. If there is a reason the components are not the latest please it include the reason in your notes for context
- Make sure that the correct Figma styles are used:
- Has the platform specific typography been used?
- Is the correct typographic hierarchy in place?
- Are colours being used from the shared library?
- Make sure that components are being used, we should always look for ways to refactor custom UI with shared components
- Check that layouts align with our 8px soft grid and visual hierarchy guidelines
- Unless highlighted all designs should follow our mobile first approach
- Depending on the stage of the work in the design process you can highlight any other issues not meeting guidelines for good file management. Remember files should be able to be picked up by any other member of the team and consistency reduces the learning curve
Comments should be added within the Figma Files for context on the work. As the creator will receive a high volume of comments it is best practice to make sure that all comments are concise and constructive.
Provide comments as full sentence(s) that relate to the work or thread, one word statements don’t help anyone.
When you make changes based on a comment or complete it always add a tick and then resolve. Otherwise explain why no changes are required and resolve.
It is possible to tag specific team members using the @username syntax. Links and emojis are also able to be utilised to provide tone or context. Make use of threads to contribute to a conversation within context.
Asking for critiques often isn’t a one-time process and it can be necessary to reach out to the team again.
The above steps can be created but it is important to update the context
- Provide an updated description of critique required. It is worth citing key changes that were taking onboard and applied
- Clear out previous comments either as deleting or resolving