Web Designer Job Description Template

Figma systems work · 22%
This role relies on producing production-ready Figma files that use components and scale with the design system. Evaluated in Round 1.

• Weak: Creates screens without using components or produces inconsistent styles across states and breakpoints.
• Meets the bar: Uses components and variants appropriately with consistent spacing, type, and color across key states.
• Strong: Builds maintainable component-based designs with clear variants, tokens/styles alignment, and documentation that reduces engineering rework.

Accessibility and usability · 20%
Accessibility is required for shipped web experiences; the candidate should apply practical WCAG patterns. Evaluated in Round 2.

• Weak: Misses basic accessibility considerations (focus order, contrast assumptions, missing states or semantics cues).
• Meets the bar: Applies accessible patterns in design (contrast-aware color usage, focus/hover/active states, logical layout structure).
• Strong: Designs incorporate accessibility checks into the workflow and anticipate issues (keyboard navigation behaviors, error/empty states, meaningful structure).

Responsive UI execution · 18%
Web designers must ensure designs behave correctly across breakpoints and user scenarios. Evaluated in Round 1.

• Weak: Designs do not account for key breakpoints or layout behaviors; breaks in smaller/larger views.
• Meets the bar: Designs define responsive behavior for major breakpoints with readable typography and consistent alignment.
• Strong: Designs demonstrate polished responsive layouts across edge cases (long text, wrapping, varying content density) with consistent interaction states.

Dev collaboration clarity · 16%
The role requires working with developers to ensure accurate implementation and minimal rework. Evaluated in Round 3.

• Weak: Hands off designs with ambiguous specs, missing interaction notes, or inconsistent asset/state definitions.
• Meets the bar: Provides clear specs, states, assets, and responds to engineering feedback to align implementation.
• Strong: Proactively identifies implementation risks, iterates quickly with engineering, and documents decisions to prevent repeated misunderstandings.

Requirements to design · 14%
Mid-level autonomy depends on turning well-defined requirements into wireframes, flows, and high-fidelity designs with clear criteria. Evaluated in Round 2.

• Weak: Translates requirements into designs with unclear structure, missing key states, or unclear rationale.
• Meets the bar: Produces wireframes and flows that map to requirements and results in high-fidelity designs with defined states and content guidance.
• Strong: Creates strong problem framing in wireframes/flows, defines decision points, and ensures the design covers the full user journey and edge cases.

Ownership and iteration · 10%
Independent work requires ownership, iteration from feedback, and reliable delivery against scope. Evaluated in Round 3.

• Weak: Relies heavily on others for direction and struggles to converge designs based on feedback.
• Meets the bar: Independently drives defined work to completion and iterates based on feedback and quality checks.
• Strong: Demonstrates strong judgment and iteration speed, improving outcomes using measurable quality signals and lessons learned.