The most important aspect of the UX process is peer review and making the review and the collation of feedback as simple and efficient as possible. Each step in in the UX process is presented for review with a document that is a chronological journal in descending order of the entire UX process for an epic.
Every posted review has an entry in the journal with links to a video overview of the work, all supporting materials, explanatory notes that clearly and accurately communicate rationale for decisions made, W3C considerations, complex responsive behaviours, technical and experience debt servicing, pattern deviations and rationale for them, and any known technical issues or other risks. The posted review has clear instructions to the reviewers as to how to add their review notes and contributions to the journal.
If there are any outstanding items from a prior review they are clearly summarized to avoid needless repeat documentation of previously noted issues.
At the completion of the review, a summary of the changes to be made is posted for confirmation. And the cycle repeats until the UX prototype is delivered to development.
Every step of the UX Process is iterated with the Product Owner until the Designer and Product Owner are in agreement and then the work is presented to the Team and another Co-Designer for their review and approval.
Understand the Problem To Be Solved
Review the application, Presentation, hardware... whatever is involved in the problem to be solved to fully understand all aspects of the issue. Confirm that the measure of success for the solution is correlated to the problem and the proposed and that it can be quantified within the expected validation time.
Summarize the understanding of the problem to be solved, the assumptions made, and an of the approach for the proposed solution. Include unexpected use cases and edge scenarios to push the limits of the proposal.
Confirm and elaborate in the text the jobs to be done to solve the problem. If complex states are involved define state transition diagrams to enumerate them and where possible simplify to solve the problem in the smallest iterations possible.
Define the storyboard of how the jobs to be done are implemented in Google Slides. Boxes and text only. No investment in images, animations, etc. Typically one slide for each job to be done but where applicable more slides can be introduced to represent various states or complexities of one job. On every slide document the job that the slide defines. Confirm that every term on the slides adheres to the Terminology Guide with the guide being updated only as required.
Contrarily, if the prototype is dealing with an area that has experiential or technical debt then all efforts are to be made to not further propagate the debt and instead eliminate all instances of it as part of this epics work. Clearly identify debt that will be serviced as part of this implementation.
The prototype branch contains only the code needed for the feature that is to be released and never more than one feature on the same branch. If the prototype requires style changes, the accompanying style branch is limited to what is applicable to a single features related style. In order to keep branches organized it’s recommended that the feature code and style branches share the same name.
Once the prototype is ready for hand-off we need to make sure that all the existing accessibility issues are cleared and that we aren't introducing new ones. This needs to be communicated and referenced on the Pull Request so that the reviewer can verify.
- 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.