UI Design Review
UI Design Review is a crucial process that ensures our user interfaces are consistent, accessible, and aligned with our design principles. Similar to code reviews, having a formalized UI design review process helps maintain quality and provides clear guidelines for both designers and developers.
This document outlines our UI Design Review process, including:
- When a UI Design Review is required
- Who should participate in the review
- Review criteria and checklist
- How to submit designs for review
- Review deadlines and expectations
- How to handle feedback and iterations
- Exception handling process
A thorough UI Design Review helps prevent common issues like:
- Inconsistent component usage
- Accessibility violations
- Poor responsive behavior
- Deviations from our design system
- User experience issues
- Development performance concerns
- App performance issues
By following this process, we ensure our UI implementations meet our quality standards before they reach implementation.
For UI review we use Figma Branching functionality. Read more:
When a UI Design Review is required
A UI Design Review is required in the following scenarios:
New Components or Features
- When introducing new UI components to the design system
- For major feature implementations with significant UI changes
- When creating new page layouts or templates
- When implementing complex interactive elements
Design System Changes
- Updates to existing design system components
- Changes to design tokens (colors, typography, spacing, etc.)
- Modifications to component behavior or interaction patterns
- Introduction of new design patterns or guidelines
Complex Changes in UI
- The review is not required when fixing UI issues or adding something small like one more button/field/etc. to the existing UI.
- However, if the changes are complex and introduce something new to the screens, then the review is required.
UI Design Review Formalization
UI Review frequency:
- At least 1 review per day.
UI Review checklist:
- All reusable global elements are created as components.
- No custom colors or icon sizes.
- No custom styles for components, except for corner cases.
- All text nodes use the Typography component from the design system.
Required reviewers:
- UI/UX designers
- At least 1 Frontend Engineer/Tech Lead - this process is primarily created for frontend engineers.
Optional participants:
- Product Owner
- Business Analyst
- QA Engineers
UI Review Flow
Author
- Follow this guide for Requesting a Figma Branch Review
- If reviewers write comments:
- Answer questions, ask your questions, or apply suggestions.
- Notify reviewers about fixes in the threads.
- After 1 approval from Frontend Engineer/Tech Lead and 1 approval from UI/UX designer:
Reviewer
- If approving changes:
- Tap approve.
- If not agreeing with changes:
- Open discussions in comments.
- When the author notifies about resolving:
- Double check ⇒ Resolve comment or write questions/suggestions.
Exceptions
- If two people cannot reach an agreement in a discussion - Ask the opinion of other reviewers.
- If there is no time for resolving review discussions - Only if the Task Priority is Emergency, create a comment in mainline or Jira ticket with a description for fixing the discussions. After that, you may merge and fix the discussions in the future.
- If the priority of the issue is low and the changes are minor - The UI designer can perform the QA check themselves.
Why Engineers should review UI and are allowed to request the changes
- Product engineers who own product decisions ship faster and better. This approach attracts ambitious, talented engineers with an intrinsic motivation for building great products.
- Impact from Engineers in UI/UX decisions increases development performance and quality -Don’t let designers dictate to engineers
- Over indexing on design polish reduces speed
- he best engineers want freedom (and will probably quit if they don’t get it)