New Feature Checklist

The following list could be used for reviewing PRs, as well as for reviewing your own code before you push it.

Writing these down led to the revelations that 1) most of these are related to state in the app, and 2) nearly all UX-related. (That’s right, being thoughtful about UX is not just for designers but also for engineers.)

This doesn’t cover everything that a quality PR review should handle. This is assuming you have already reviewed the logic of the code itself for errors, best practices, potential conflicts, etc. This also assumes that the feature meets the ticket’s spec, and is something that your application truly needs. 

These questions are more about whether this new feature works.

The Checklist

Accessibility
It’s just simple courtesy to make sure you have covered basic accessibility around your new feature. 

Have you ensured your text size is scalable and isn’t cut off when the user has toggled on a larger text size? Are you supporting both light and dark mode? Does content have captions or descriptions provided for users that require a screen reader?

Empty state
What happens when there is no data to populate this feature’s views? If a view is loading or taking a long time to load, is the user shown a loading spinner or dummy UI to indicate as such?

First use
Does this feature work correctly the first time is it used? Should there be some instruction for the user the first time this is accessed? Does the feature correctly distinguish between the first use and other potential empty states?

Offline mode
Will the feature work if the user is offline? Are there any views that require an internet connection to load? Is there data that could be cached to make the feature work without too much friction when the internet is not available?

There may also be situations where even just bad network conditions or slow wifi can cause glitches with UI, persistence, etc. Testing with the Network Link Conditioner can also help to reveal race conditions.

Localization
If possible, does this feature support localizing text direction, language, currency, time, units of measurement, etc? 

Authentication
Is the user’s login state detected and handled appropriately? How is unauthorized access dealt with? Does this feature work correctly for any arbitrary user account type? Is this hidden from users who should not see it?

Some apps may have more and less complicated authentication flows with multiple auth states: logged in, not logged in, logged in with a valid oauth token, attempted login with an expired token, etc. Others may not have user accounts at all. Are all of the reasonable login states addressed?

Accessing from unusual routes
Will this feature still work if accessed via deep linking, universal linking, etc? Is it accessible or able to be launched from everywhere in the app that it should be?

Persistence
Are things that should be saved from one session to the next persisted in the correct place (server vs. client, UserDefaults vs. File Storage, etc)? Are they saved at the right time in the flow of interaction? 

Should the app remember the user’s last state when they interact with this feature? For example, consider how Chrome remembers the last tab you were on when you open the app again or how your email client saves your draft.

Multiple users
Does your logic account for scenarios involving multiple users? Is there a possibility for race conditions?

CRUD
If this feature contains interactive components, do these support all four elements of CRUD?

Navigation
Is it easy to navigate backwards? Does moving backward or forward from this feature take the user where they would expect to go?