Experience Quality “Checklist” – Kim Spencer

As design teams are created, evolve and mature it can be difficult to adequately maintain high level quality standards when you’re designing and developing at scale. Designers on the ground can range dramatically in education, experience and expertise. Designers may be well versed in web design but not iOS or Android or vice versa. More and more is being asked of designers, making it difficult to become subject matter experts on any one ecosystem. Regardless, everyone is running the marathon together and everyone needs to cross that finish line.

This checklist was created as a means to provide support to all designers within an organization. There are sections that are best sourced early within the creative process. Other areas for SMEs reviewing the work and more sections that address accessibility, content and guidelines for dev handoff. This list is extensive. Exhausting. Therefore it can be picked apart and put back together again to best fit your scenario or organizational needs.

Ensure text has a minimum color contrast ratio of 4.5:1 compared to surrounding colors.
Don’t convey information or interactivity using color alone.
Don’t use flashing animations which could cause seizures or physical reactions.
Ensure decorative or redundant images will be hidden from assistive technologies by ensuring that decorative or redundant images are documented for development partners.
Ensure meaningful graphics and iconography have minimum color contrast ratios of 3:1 compared to surrounding colors.
Use descriptive, meaningful headings and titles.
Include audio descriptions for video content.
Provide brief but robust alternative text for meaningful images.
Don’t rely on sensory characteristics (shape, position, etc.) as the sole indicator for understanding and operating content.
Every page must have a single level 1 heading and content should be nested in heading levels of descending order.
Use clear, consistent, and commonly understood language.

Include captions and/or transcripts for audio content.
Use link and button text which make sense out of context.
Provide descriptive, permanently visible labels in proximity to their respective form controls.
Don’t use placeholder text for important information and avoid placeholders which add no value at all.
Design clear focus states on custom components so keyboard users will know which element is in focus.
Design for all applicable keyboard interaction standards.
Ensure content can be magnified and/or text size can be increased up to 200% without loss of content or functionality.
Provide generous touch/click target sizes, using a minimum of 44×44.
Provide enough time for users to read and interact with content.
Avoid mixing design patterns (checkbox within a radio button group).
Provide controls to pause, stop, or hide animations.
Animations are removed when a user has selected “Reduce Motion” in accessibility settings.

Adheres to the organization’s content guidelines (i.e. use case specific, contextually relevant, natural language, etc.)
Use the standard language for common terms as outlined in the organization’s language glossary
Use approved digital files for the organization (and associated) logos.
Follow organizational brand standards for photography.
Follow organizational brand standards on logo placement and scale.
Follow organizational brand guidelines on color palette for all visual assets (illustrations, photography, and iconography).

Personality traits do not interfere with, or reduce the efficiency, of completing a task
If I read the content aloud, it sounds like I’m having a natural conversation with a friend—while respecting their time and accurately reading the room
The personality traits present in this experience are easy to identify
The personality traits in use match the context of the moment and enhance the experience organically
Any personality trait that is in use is not at the expense of another (i.e.: secondary traits at the expense of core traits)

Animations follow the organization’s animation principles
The functionality of new or custom controls/widgets is obvious, usability tested, approved, and shared with global pattern libraries.
Use a screen transition style that is consistent throughout the app.

The design uses the appropriate design system, platform standards (i.e.: web, iOS, Android) and new patterns are submitted for global usage.
Icons are visually and conceptually distinct. New icons have been usability tested, follow brand guidelines, are approved, and have been submitted for global pattern usage.

Unhappy paths/errors are designed and available for review.
The experience is designed in a way that prevents users from making errors.
The experience makes it obvious when and where an error has occurred (e.g. when a form is incomplete, highlighting the missing fields)
Error messages tell users what went wrong and provide a path that allow the user to recover from error and move forward. They don’t blame users.

The experience ensures that work is not lost (either by the user or site error)
Important instructions remain on the screen while needed, and there are no hasty time outs requiring the user to write down information.
The experience prompts the user before correcting erroneous input (e.g. Google’s “Did you mean…”).
The correct design system components for the type of error that was triggered are used.

Immediate feedback on user input or actions is provided, whether successful or unsuccessful.

For all high-impact actions, a user must be presented with a clear summary of the action for them to confirm. User confirmation is *required* before carrying out potentially “dangerous” or other high-impact actions (e.g. deleting something, sending money, anything that cant be undone).

Input fields automatically enter formatting data (decimals, date formats, $, etc).
Form Fields do not contain placeholder text.
Instructional content to demonstrate what the user should enter (“1234 Main Street”) can be grouped with label.
Form Fields will alert the user if caps lock is on.
No form field requires manual entry if it’s data the organization already has.
Before a user gets to a form, they are alerted if external information is needed for completion (e.g. a passport number).
Entry fields and selections are validated before the form is submitted (at a minimum), and preferably at the field level.
It is easy to correct errors (e.g. when there is a data entry error, in addition to highlighting the field, position the cursor at the location where correction is required).
There is a clear and consistent distinction between “required” and “optional” fields on forms.
Questions/fields on forms are grouped logically, and each group has a heading.
When possible, present choices rather than an open text field.

Labels are close to their corresponding entry field (e.g. labels and fields are left justified).
Text entry fields on forms are the right length for the expected user input.
Form components (like radio buttons, check boxes, select boxes, combo boxes, text fields) are used appropriately according to the definitions of each.
The correct system keyboard is shown for the expected input type.
There should be no more than 1 step up authentication task in any given session, and content must tell the user the reason for the authentication ask.
A user is never asked to re-authenticate if they’re coming from an authenticated environment.
The first field in a form is in focus, removing the need for a user to tap or click the field. Please specify this to your development partner.
Whenever the user is forced into a task to continue (i.e. step-up authentication) the experience displays some of what the user will see after they complete the task.
Allow user to “show” sensitive information (but default to hide).

Getting help is easily accessible throughout the experience, and different methods of contact are available.
Contextual help is provided.

Help content provides clear step-by-step instructions telling users what to do rather than what *not* to do.

There is a convenient and obvious way to move between related sections and it is easy to return to home.
The major sections of the experience are available from every page (persistent navigation) and there are no dead ends.
The Back button is not disabled for web, and Apps enable back in their flows in the manner and location specified in the Apple HIG and Material Design Guidelines.
Clicking the Back button/control always takes the user back to the page or step the user came from.
The navigation system is broad and shallow (many items on a menu) rather than deep (many menu levels).
There are clearly marked exits allowing the user to cancel out of the current task without having to go through an extended dialog or a sequence of “back” buttons.
If the experience spawns new windows, these will not confuse the user (e.g. they are dialog-box sized and can be easily closed).
If tabs or a segmented control are used there are no less than 3 in a group and are used for showing differing views of the same info type and not for navigation.

Category and navigation labels accurately describe the information and features in the category.
The privacy policy is easy to find, especially on pages that ask for personal information.
iOS Navigation Bars contain no more than the view’s current title, a back button, and one control that manages the view’s contents. If you use a segmented control in the navigation bar, the bar shouldn’t include a title or any controls other than the segmented control.
Users do not have to leave the app to check the time or device battery level.
iOS Tab bars contain navigation only and are always visible within the app, except for modal views and photo capture or display of check images.
The iOS Tab bar contains no less than 3 and no more than 5 items.
Segmented controls must have less than five segments to allow for properly sized tappable targets.

Typefaces respect and adapt to the user’s device or browser settings.
Typefaces are used consistently and are readable, using appropriate contrast and size as outlined in the Accessibility Guidelines.
There is clear branding so the user always knows they’re on the same site or app.
The experience can be used without pages that scrolling horizontally. This does not apply to carousel/gallery-type components or swiping behavior on appropriate devices. If using a carousel component, use visual cues for the user to understand this function – such as directional arrows, cut off images on the sides or dots underneath the rotating content.
Things that *are* clickable/tappable (like buttons or touch targets) are obviously clickable/tappable. Items that *are not* clickable/tappable do not have characteristics that suggest that they are.
Related information and functions are clustered together, and each group can be scanned quickly.
The layout and visual hierarchy of the screen helps focus attention on what to do next.
The layout and visual hierarchy of the screen helps focus attention on what to do next.

Attention-attracting features (such as animation) are used sparingly and only where relevant.
Pages are free of “scroll stoppers” (headings or page elements that create the illusion that users have reached the top or bottom of a page when they have not). Use visual cues for the user to understand that content exists beyond the viewable area.
Standard elements (such as page titles, site navigation, page navigation, privacy policy etc.) are easy to locate.
Buttons and links have active, inactive, and visited states.
There is appropriate and platform specific buffer space between touch targets.
Visual design of any control follows the affordance best practices of the control: Checkboxes need to look like checkboxes, drop downs need to look like drop downs, etc.
Designs for web include sizes for desktop (1440), tablet (768) and phone (414).
Designs for iOS include iPhone and iPad, and will work on all device screen sizes.
Avoid interfering with systemwide screen-edge gestures

The default search uses natural language, not syntax (no Boolean operators).
The search results page does not show duplicate results (either perceived or actual duplicates).
The search interface is located where users will expect to find it (generally at the top of the page, middle or right).
The search results page shows the user what was searched for and it is easy to edit and resubmit the search.

The search box and its controls are clearly identifiable as a search widget.
If no results are returned, the system offers ideas or options for improving the query based on identifiable problems with the user’s input.
The search results page makes it clear how many results were retrieved.
The scope of the search is made explicit on the search results page and users can restrict the scope (if relevant to the task).

The user does not need to enter the same information more than once.
Users do not need to remember information from place to place (design for recognition over recall).
Progress and status indications / feedback are displayed, as they are critical to a user’s perception of ease of use.
Important calls to action, like ‘Apply’, are highly visible.

Design supports the primary activity, eg Scanning transactions, comparing presented options (product comparisons), determining what’s available before proceeding, etc.
Fitts’ Law is followed (the speed at which a user can click a target, without errors, is decreased the nearer and larger the target is).

The experience is free of typographic errors and spelling mistakes.
Link names match or are a very close approximation of the title of destination, so users will know when they have reached their intended destination. Links and link titles are descriptive and predictive (i.e. no “Click here!” links).
Content is designed for the appropriate platform (i.e. not pulled in from a PDF).
Content is quick to scan, with ample headings and sub-headings and short paragraphs. Body copy is always left-aligned for readability.
Call to actions are task-specific (e.g. Sign up vs. Submit) and begin with verbs/action words (e.g. Pay a bill). Avoid vague calls to action, such as Learn more.
Use sentence case almost everywhere—including in headings and buttons. This means capitalizing only the first word of the sentence or phrase in headers, listed items, body text and buttons.
In most cases, omit periods in headings, buttons and labels (even with complete sentences). You may use a question mark for questions and an exclamation point if it’s appropriate for stylistic emphasis.
Ampersands: In headers, subheaders and banners, you may use an ampersand if space is limited or if needed for a creative execution. In most cases, omit ampersands in body copy and buttons.
Use bulleted or numbered lists correctly: Include at least 2 list items but no more than 6, use end punctuation only if the list item is a complete sentence, and use parallel construction for each item in a list.
Avoid directional language (read below) and superlatives (quickly, easily).
Remove minimizing words like just, only, simply that make assuming about someone’s ability to comprehend or perform an action.
Avoid apologizing unless we truly messed up (not because the system is performing as expected but may be causing an inconvenience to users).
Limit please for when you’re asking the customer to go out of of their way.
In error messages, describe what triggered the problem and then respectfully tell the user what they can do about it.

Em dashes. Don’t include spaces around em dashes and don’t capitalize the word after an em dash (unless it’s a proper noun).
Hyphens. Use hyphens to indicate ranges of dates and times (April 2020-April 2021) and as joiners (such as in compound modifiers: small-business owner).
Citing numbers. Use numerals for all numbers everywhere, (1-10+) except when 2 numbers are next to each other in text: She planned to purchase eight 3-prong binders.
Citing phone numbers. Use this format for phone numbers: 212-621-1500 and 800-456-0343. Follow vanity phone numbers with the actual numbers: Call 800-SPENCER (800-555-5555)
Citing time. Use this format when referring to a specific time: 8 p.m. ET or 8:30 p.m. ET
Citing time range. Use this format when referring to a time range: 2-8 p.m. ET
Citing months of the year in non-tabular material. When citing month alone: Spell out the month. When citing month + day or month + day + year: Abbreviate only Jan., Feb., Aug., Sept., Oct., Nov., and Dec. and follow the abbreviation with a period. Spell out March, April, May, June, July (e.g., Jan. 13 or Jan. 13, 2022; April 15 or April 2022). Don’t follow a date with st, nd, rd or th.
Citing months of the year in tabular material. When citing month alone or with a specific date: Use these three-letter forms without a period: Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec. (e.g., Nov, Oct 13, Jan 5-Apr 6). Don’t follow a date with st, nd, rd or th.
Citing days of the week. In non-tabular material, spell out days of the week when they appear alone or with a specific date (e.g., Tuesday, April 15 or Wednesday, Aug. 12, 2022); in tabular material, use these three-letter forms without a period: Sun, Mon, Tue, Wed, Thu, Fri, Sat (e.g. Tue, Oct 13).
Use pipes (also known as vertical bars) to display contextual page attributes, tags or links in close proximity to one another.