We have a long-standing checklist for merge requests. However, it hardly matches the intricate requirements for design. This checklist fills the gap.

Opscomplete powered by

Save money by migrating from AWS to our fully managed hosting in Germany.

• Trusted by over 100 customers
• Ready to use with Ruby, Node.js, PHP
• Proactive management by operations experts

Read more Show archive.org snapshot

Before starting implementing, look at all designs: are there components similar to yours? Have they already been implemented? Can you build on this prior art when implementing yours?

Checklist: I confirm my design implementation

• has been tested manually by me
• adheres to the code style of the project (e.g. BEM)
• avoids "magic numbers" (don't say e.g. padding: 20px)
• does not duplicate existing styles (for similar parts)
• respects all specifications of the design
  • spacings and sizes are correct
  • on small viewports, elements are sometimes sized differently compared to large viewports
  • edge cases have been catered for
• is responsive. When scaling a browser window from 320px to 3000px width (try negative browser zoom):
  • it looks good all the way
  • all functionality remains usable (e.g. when implementing a navigation)
• works on touch devices. About 50% of website visitors use a smartphone nowadays (depending on the website). Especially hover styles loose relevance in this light. A touch user:
  • can perform all interactions
  • can see all information
• works in all expected contexts (e.g. solitary, in a sidebar, on a dark background etc.)
• is accessible. See Barrierefreie Webseiten.
  • It navigates through elements in order (or in an order that makes sense). You can test that by clicking into the page, top/left of the new design, and repeatedly pressing the tab key.
  • It highlights interactive elements on focus (e.g. through :focus-visible).
  • Interactive elements without a text label have an aria-label.
• uses Semantic HTML
• is well usable. Interacting with the component:
  • feels natural
  • does not require unnecessary steps (e.g. when pressing a "search" icon, shows the search field already focused)
  • adheres to common conventions (e.g. backdrop click closes an overlay)
• is correctly localized (if applicable)
  • all texts
  • date/number/currency/… formats

Bonus

Add screenshots of any new or changed elements. Gitlab has a "Details block" behind the "+" button in its WYSIWYG editor that helps saving space.