Checklist
Make sure you share each phase in the Water Cooler so that the company can review before you start the next phase one!
- Review the work and provide dates
- Design the wireframes
- Design the mockups
- Handoff to development
- Review the implementation
- Design post mortem
Resources
- Design Journal Template
- UI Designer Accessibility Checklist
- Development Accessibility Checklist
- Style Guide
- Branding Guide
- Wireframe Template
Process
Peer review
We want to make peer review as efficient as possible. We do this using a Design Journal (template) that contains journal entries from the Designer. Each entry in the journal should include; a video overview, a link to the Zeplin project, a comment tagging any necessary reviewers, and any other considerations. For ex: W3C considerations, complex responsive behaviors, known technical issues or other risks.
Once the Designer and Product Manager are happy with an entry the Designer needs to publish the journal entry in the Water Cooler so that the company can provide feedback. To keep the process moving make sure you set a deadline for feedback, for example 24 hours. The Designer shouldn’t proceed with any revisions from the feedback until the Product Manager has agreed to them.
Resolve any confusion or disagreement with a video call. Going back and forth in text in a doc is inefficient. Summarize video calls in the design journal so that everyone is on the same page.
The goal is to complete each phase of the UX Process in 2 or less iterations.
Review the work and provide dates
Before starting work the Designer confirms who needs to review the work with the Product Manager. The entire company may want to review the work and provide ideas but specific people will need to review the work. Then the Designer reviews the Epic Concept to understand the problem being solved and confirms their understanding with the Product Manager. The Epic Concept should articulate the Jobs to be Done with supporting UI text. If information is missing the Designer needs to ask the Product Manager to fill in the gaps.
Once the Designer understands the requirements they set the date for finishing each phase. The Designer provides the timeline to the Product Manager for review and once confirmed the Designer begins.
Design the wireframes
The Designer creates the wireframes using Sketch. Don’t include any images, color, animations, etc. in the wireframes, just boxes and the UI text. Keep it simple!
When the Designer has completed the wireframes, the Designer exports the design to Zeplin. In the journal entry include a link to the design in Zeplin as well as the details defined in the Peer Review section above.
Design the mockups
When the wireframes are finalized, the Designer starts work on the mockups, again using Sketch. Throughout the process the Designer validates accessibility concerns are addressed using the Accessibility Checklist.
Mockup guidelines
- The UI Designer Accessibility Checklist is used to verify accessibility concerns are addressed.
- The Style Guide is used to verify proper spelling, grammar, capitalization, etc…
- The Branding Guide is used to verify proper colors, fonts, etc...
When the Designer has completed the mockups, the Designer exports the design to Zeplin. In the journal entry include a link to the design in Zeplin as well as the details defined in the Peer Review section above.
Handoff to Development
When the mockups are done the Designer publishes a journal entry to the Product Manager and Dev Lead that includes all assets that development needs to implement the design.
Design post mortem
The UI Process ends with the Designer performing a post mortem to identify improvements we can make to achieve our goal of completing each phase in 2 iterations or less.
A journal entry is added to the design journal that answers the following questions:
- What worked well on this design project?
- What didn’t work well on this design project?
- How many iterations where required to complete the wireframes, mockups, and development handoff?
- If more than 2 iterations were required, why?
- What should we do differently to ensure this phase can be completed in 2 or less iterations on subsequent design projects?
Review the implementation
Once development has implemented the design the designer should review the implementation to make sure it adheres to the mockups.
UI Designer Accessibility Checklist
Responsiveness
- The app is usable at a minimum width of 320px
- The interface is fully operational using zoom levels from 75%-150%
Style
- The contrast ratio between text and background is at least 4.5:1 Using Contrast Analyser
- Text can be resized to 200% without loss of content or function
Navigation
- Logical structure and order. Navigation components must use the <nav> or <ul> tags. This will ensure that the contents are recognized as navigational items.
- Don’t use presentation or states that rely solely on color. Navigation item states must be obvious without relying solely on color (e.g. bold text, contrast) Links need to have underlines in order to be identifiable without color.
- Ensure keyboard focus is visible and clear. Focus styles shouldn’t be disabled through css overwrites.
- Use menus consistently. Any navigational menu must appear consistently on all listed pages.
Let users know where they are. Navigation current states must be communicated through aria-current attribute or hidden text.
Content
- Provide text alternatives for non-text content. Images and icons must have text labels that describe their content or functions. https://www.nngroup.com/articles/icon-usability/
- Present content in a meaningful order. Content like headings, lists, descriptions and instructions need to be presented in a way that matches the users expectations (e.g Instructions after the controls).
- Use clear headings and labels. Headings and labels must indicate the actions or content presented on the section and be different enough to not be confused with similar sections (e.g Address vs. Billing or Shipping Address).
- Don’t use images of text
Links and Buttons
- Every link’s purpose is clear from its text. We avoid using non-descriptive links for actions or navigation (e.g. Click here)
Forms
- Clearly identify input errors All input fields must be highlighted if they contain errors, not only with color but ideally with text indications.
- Label elements and give instructions. All input fields must be labeled and when needed instructions must be provided on how to fill the form.
- Suggest fixes when users make errors. If possible users who have validation errors on a field need to understand how to correct them.
- Use icons and buttons consistently. Icons for special input fields must be used in the same consistent way across all apps (e.g. Icon for date pickers, search bar).
Development Accessibility Checklist
Responsiveness
- The interface is fully operational using zoom levels from 75%-150%
Style
- Text can be resized to 200% without loss of content or function
Navigation
- Logical structure and order. Navigation components must use the <nav> or <ul> tags. This will ensure that the contents are recognized as navigational items.
- Ensure keyboard focus is visible and clear. Focus styles shouldn’t be disabled through css overwrites.
- Let users know where they are. Navigation current states must be communicated through aria-current attribute or hidden text.
Links and Buttons
- Accessible by keyboard only. Any action can be performed with a keyboard only (e.g. hit enter to submit)
Other interactions
- Provide user controls for moving content. Any content that is interacted through drag and drop or requires a control to be clicked needs to be accessible by keyboard as well.