Improving the UX review process through standardising on Review Apps
The UX review process is currently non-standardised and makes use of a variety of workflows in order to get merge requests reviewed:
- Screenshots/video captures
- Review calls between UX-FE
- Ngrok tunnel
- Review apps
The most complete and asynchronous way of reviewing has always been through using the GDK. However, this often proves to be a huge timesink in what otherwise would be a quick inspection of said improvement due to having to fix errors and updating the local environment.
Additionally, the gdk means you often have to recreate the exact same testing environment configuration geared towards showcasing said improvement, this is non shared between people and requires additional setup + time.
This causes us to often move away from this review method to save time creating the alternative review methods listed above. This not only causes inconsistencies, but also a subpar reviews and/or missed edge cases.
- Related slack discussion thread https://gitlab.slack.com/archives/C03MSG8B7/p1553272584252200
- This was also discussed within the UX/FE call: https://youtu.be/5F68Rno4bPc?t=1254
One of the alternatives actually has the potential to be the superior UX review workflow. Review apps have the potential to:
- Online readily available environment
- The environment is configurable by multiple people
- It supports an asynchronous process
- Dogfoods one of our own features
Review apps have "recently" became active for the CE and EE projects (though are still missing some functionality like gitlab-ce#54185), however there seems to be no alignment on standardizing them in both the Engineering development workflows or the UX review workflows.
Let's see if we can standardize on this method and incoorporate this into the default workflow. This needs:
- Check for feasibility
- Buy-in from the engineering and UX managers
- Handbook and engineering workflow documentation adjustment
This can be moved to a separate issue, but wanted to include it initially as it was part of the discussion in the UX/FE call.
As UX'rs we can do a more consistent job of describing the intended user journeys we'll be testing for. This way, Engineers can test them themselves similar to us before setting the merge request up for review.
- Handbook adjustment