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 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. Prototype code that’s intended for prototype use only must be differentiated from production ready code, this can be accomplished by adding letters as an appendix to the prototype-only selector names or HTML partials. For example: #pt_display-offline or pt_screenshot-state.html. The Prototype at this stage is responsive, following a minimum width spec of 320 pixels. The prototype interface is fully operational using Browser Zoom levels from 75%-150%. Layout must conform to the grid at these settings. Test the prototype on all relevant hardware.. Displays, mobile devices, whatever it takes to make it as 'real world' and solid as possible.