UX specs readiness / acceptance checklist

20 Oct, 2021UX, Product design


As shared in this epic presentation http://xinni.co/uxeng, bad UX design practices not only hurt the end-users, but also hurt the developers by introducing more uncertainty, more unnecessary communications and more frustrations.

What's even worse is that the developers often rely on the UX specs to give the estimations before the development starts. Incomplete UX specs easily lead to under-estimations, and in the end, either the delivery of the product has to be delayed, or everyone has to work overtime to catch up with the deadline.

Thus when the UX specs are not ready, the developers should simply refuse to accept it, give any estimations or even start the development straight away.

2 key facts about software development

  • It takes exponentially longer (or more expensive) to change at a later phase of the development than it does to change at the planning phase.
  • Developers spend 80% of the time dealing with the corner cases.

The checklist

Single source of truth

  • The UX specs should be on a whole continuous scrolling workspace
  • No extra docs needed for UI designers / server devs / QAs
  • No extra docs needed for client devs apart from:
    • API docs: ideally all in one single page. If some of the information must stay on the other pages, such as error code, they should be linked in the API docs
    • UI specs: should all be linked (NOT pasted as screenshots) in the UX docs

UX docs

  • Modules, components, pages are indexed
  • Special requirements are indexed
  • Changes are clearly marked (if any)
  • Out-of-scope requirements are clearly marked (if any)
  • Logics with multiple combinations of input/output, all the possible combinations are listed (ideally in tables)
  • User flows are complete:
    • Consequences of all the interactive elements
    • Where the data comes from
  • Transitions:
    • States before, in-transit and after
    • Animations
    • Should show spinner before loading the page or after loading the page
  • Invisible logic:
    • Notifications
    • Polling
    • Refetching after mutation
    • User behaviour tracking
    • Audios
    • Keyboard shortcuts
    • Mobile client haptics

Corner cases

  • Text overflow/ellipsis
  • RTL layout
  • Regions
  • Number/time/date format
  • Loading status
  • Empty status
  • Success status
  • Failure status:
    • API error
    • Network error / Offline
    • Unable to load images
  • Maximum / minimum allowed input length
  • Responsive layout / behaviour on different resolutions
  • Browser tab title & SEO
  • Full-screen mode
  • Dismissible items:
    • Lose hover
    • Lose focus (click/touch outside)
    • Timeout
  • Accessibility:
    • On hover / on focus / on touch status

UI designs

  • Dev can export assets directly from the UI specs platform
  • Icons, backgrounds, etc are grouped in the correct dimensions for exporting
  • Good colour contrast (not only looks good on their MacBook Pro's retina display)
  • Icons:
    • Unified viewbox
    • Unified stroke colour


  • No errors or typos (missing space, extra space, incorrect spellings)
  • No grammar issues
  • Consistent use of punctuation marks
  • Consistent use of words
  • Consistent tones (Being natural, no sudden "Oops" or exclamations)
  • Consistent capitalisation
  • No internal terms, acronyms or abbreviations
  • All external links are provided with URLs


  • One primary communication channel, ideally direct comment on the UX specs
  • All the involved parties should receive immediate notification on any comment and all agree to follow up ASAP

Powered by Gatsby. Theme inspired by end2end.

© 2014-2022. Made withby mdluo.