Design System

Quality of the project's design system, tokens, and saved styles.

File lacks a proper design system, does not fully leverage saved styles for color, font, or effects, or uses a preexisting UI kit with zero customization or--if strict adherence to the kit is deliberate--does not implement the system correctly.

File mostly uses proper global styles with few exceptions. Token system and components are either custom-built or--if using a reputable UI kit such as HIG or Material--demonstrates proper implementation of the system.

File consistently implements tokenized design styles throughout the file with very few, if any, deviations. Design system itself is mostly custom or--if deliberately using a reputable UI kit as in native app development--demonstrates masterful application of the system.

Graphic Design

The app or website's style, branding, and literal visual characteristics.

Designs show several signs of poor graphic design skills, such as inconsistent spacing and alignment, lack of clear hierarchy, confusing layouts, and several violations of the Laws of UX and Gestalt principles.

Designs are reasonably well-styled and

Project is extremely well organized with intuitive file and component structures and elegant state management.

Interaction Design

How users will actually interact with your app.

Designs are mostly static (no prototypes) and do not address basic user interactions such as navigating between screens, focusing on inputs, or tapping buttons. Little to no use of animation or motion design.

Designs are mostly static, use some prototypes, but still clearly document how components respond to user interaction through other methods like flow charts, on-page annotations. Some basic use of animation or motion design.

All designs are dynamic with rich prototypes, clearly-documented responses to user interactions. Advanced implementation of motion design with high attention to detail. Prototypes feel as indistinguishable as possible from a real, functioning app (within the limits of what Figma allows).

File Organization

How the literal Figma file itself is organized

File is generally unorganized with auto-generated layer names (e.g. Frame 92883), unintuitive page organization (it's not obvious where the 'latest' designs are), and several unused components, orphaned instances, and unused tokens.

File is generally organized with some exceptions of automated layer names, pages are named clearly and intuitively, and pages themselves are clearly organized

Files all follow a clean, consistent pattern, use semantic variable names, follow declarative best practices, and achieve a healthy balance between too verbose and too abbreviated.

Documentation

The comments within code files and the documentation around the project.

Components are poorly organized and use automated names (i.e. Component 1), conflicting components for the same purpose (i.e. Button 1 and Button 2), inappropriate use of component properties, and are mostly undocumented.

Components follow an atomic structure and are clearly arranged with proper use of different property types where appropriate. Components are mostly documented, with a few exceptions.

Components follow an atomic structure and demonstrate a masterful grasp of all prop types, with rich documentation for developers that calls attention to notes that may not be self-evident from simply examining the file.

Responsiveness

How the design adapts to different viewport sizes.

Design does not correctly use auto-layout or constraints, and resizing frames causes them to instantly break.

Design correctly uses auto-layout or constraints based on the use case, and most frames are responsive when resized with few exceptions. Autolayout spacing and padding follows a consistent system such as the 4dp grid or LiftKit spacing.

Designs are fully responsive across multiple breakpoints for desktop, tablet, and mobile devices, and our reviewers have difficulty finding a frame we can break by resizing it.