The most important aspect of the UX process is peer review and making the review and collation of feedback as simple and efficient as possible. We do this using a Design Journal - a shared Google Doc that contains journal entries from the Designer, and each entry is published to her peers for review and feedback. Each entry in the journal should include; a video overview of the work, supporting text that clearly and accurately explains rationale for decisions made, links to all supporting materials, any design considerations that impact the design; W3C considerations, complex responsive behaviors, known technical issues or other risks.
Peer Review Guidelines
- We do not move forward in the UX Process until the Designer and Product Manager have reached full agreement on the outcome for the phase being worked on.
- Design revisions based on peer feedback, or for any other reason, are summarized in the Design Journal by the Designer and published to the Product Manager for review. The Designer does not proceed with the revisions until the Product Manager has agreed to the revision summary.
- Any confusion or disagreement is resolved with a video call. Going back and forth in text in a doc is inefficient. Video calls are summarized in the design journal to ensure we are fully aligned on the work we are pursuing.
The goal is to complete each phase of the UX Process in 2 or less iterations.
Review the Problem to be Solved
Before starting any design work the Designer reviews the Epic Concept defined by the Product Manager to understand the problem the Epic is setting out to solve. The Epic Concept provided by the Product Manager should articulate the Jobs to be Done with supporting UI text. If any of this information is missing the Designer does stops their review and asks the Product Manager to provide any missing or incomplete information necessary for the Designer to fully understand the UI requirements.
When the Designer fully understands the problem to be solved, the Designer uses the related application to experience the same friction points that our users do.
Designer Summary of Problem to be Solved
Once the Designer and Product Manager are in alignment on the Epic’s problem to be solved, the Designer summarizes in the Design Journal the problem to be solved from the UI point of view including; W3C considerations, complex responsive behaviors, limitations, risks, etc., and sets the target date for completing each phase of the UX Process.
The Designer publishes the summary and timeline to the Product Manager for review and does not move forward until the Product Manager has reviewed and confirmed the Designers summary of the problem.
Low Fidelity Design
The Designer produces low fidelity UI sketches using Google Slides. We do not want to invest in images, animations, etc. Just boxes and the UI text per the Epic defined by the Product Manager.
Low Fidelity Design Guidelines
- One slide per Job to be Done with the Job to be Done stated on each Slide.
- The Accessibility Checklist is used to verify accessibility concerns are addressed.
The journal entry published for review includes a link to the Google Slides Doc in addition to the details defined in the Peer Review section above.
High Fidelity Design
When the low fidelity design is finalized, the Designer begins work on high fidelity design using Sketch. Throughout the process the Designer validates accessibility concerns are addressed using the Accessibility Checklist.
When the Designer has completed the high fidelity design, the Designer exports the design to Zeplin. The journal entry published for review includes a link to the design in Zeplin for review purposes in addition to the details defined in the Peer Review section above.
Handoff to Development
Once the high fidelity design has been finalized the Designer publishes a journal entry to the the Product Manager and Dev Lead for the respective team that includes all assets that will be required by development in order to implement the design.
Design Post Mortem
The UX Process ends with the Designer performing a post mortem to confirm the number of iterations each phase required and updating the Iteration Tracking Spreadsheet accordingly, then working 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 [ PTBS Review | Low Fidelity Design | High Fidelity Design | Dev 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?
- The app is usable at a minimum width of 320px
- The interface is fully operational using zoom levels from 75%-150%
- 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
- 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.
- Provide text alternatives for non-text content. Images and icons must have text labels that describe their content or functions.
- 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
- Accessible by keyboard only. Any action can be performed with a keyboard only (e.g. hit enter to submit)
- Every link’s purpose is clear from its text. We avoid using non-descriptive links for actions or navigation (e.g. Click here)
- 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).
- 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.