Define a way to keep track of major UX & design changes in the Handbook
@jackib and I touched on this in our 1:1 yesterday. We're starting to introduce larger UX changes in some Growth-related flows and we feel that these should be documented somewhere that's not an issue, ideally in the Handbook. This would be a one or two sentences long description and a link to the original issue to not compromise the SSOT.
Questions to all designers:
- How much time do you feel you spend researching how something works or other background info in order to inform your work? Is it easy or hard to find this information?
- Have you ever felt that you're introducing such large changes (or complex specifications/rules) that they should be documented and communicated more broadly?
- If yes, do you think it should live in each team's Handbook section (Growth UX, Plan UX, ...) or in the main UX section? Or somewhere else?
- Should we, eventually, introduce a "UX improvements & changes" blog post that gets published somewhat regularly?
Example
I recently worked on auto-renewal and renewal banners: informing the user that their subscription will either be auto-renewed or that it's running out. We're completely revamping these notifications, changing the logic of when the banners show up the first time, the second time etc. The issue has flow charts, designs, copy, illustrations and detailed G/W/T and requirement sections.
The logic and the designs for the two cases are the same, but the flows are slightly different depending on if it's auto-renewal or not. This work spans across two issues: gitlab-org/growth/product#102 (closed) and gitlab-org/growth/product#143
As it's hard to keep track of these changes once the MRs are merged and the issues are closed, it'd be a good idea to document this larger change to how our renewal banners work somewhere else, but link to the issue as the SSOT.
I think the place to document this should be the Growth UX Handbook page unless others feel that they should also document things and maybe it needs to be somewhere more "central", the main UX handbook page?
Conclusion
We'll keep using Pajamas for documenting information about components and their usage throughout the product, and the handbook or a GitLab project to document product-specific rules or specification about how we implement those, with links between relevant content.