govuk-prototype-kit
govuk-prototype-kit copied to clipboard
alphagov
Add guidance or support to the kit for versioning prototypes - discuss
Teams often need to record the prototype state at certain points, for example what was tested with users. There have been different approaches to this, would be good to research into best practice and if there is any functionality we could add to the kit to make this work better for users.
As reference, here's @alextea's post on the subject: https://designnotes.blog.gov.uk/2016/05/13/archiving-versions-of-a-prototype/
Please feel free to comment in this thread with any experiences you have of this, thanks!
We've written some guidance recently about organising and structuring your prototypes, that expands a little on the article you mention: https://ukhomeoffice.github.io/coe/resources/structuring-maintaining-prototypes/
Another post on this https://designnotes.blog.gov.uk/2017/04/07/things-to-consider-when-designing-in-alpha/
Also shared via Joe: https://ukhomeoffice.github.io/coe/guidance-tools/versioning-prototypes/
Documentation around this should probably also cover maintaining a design, research and then development instance of a prototype. I've done this in the past using branches and a lightweight version of git-flow.
Using Heroku review apps you can spin up an instance for each branch by creating a pull request. Removing a lot of the manual stuff in @alextea's post.
Hi @joelanman .. I showed what I was doing last year in this issue: Allow for sub-applications - Might be useful.
@paulmsmith oh thanks for flagging that up! I'd forgotten about it in the time since you raised that and me joining the Design System team. Will take another look when we get round to working on this aspect.
Are you looking to collect info about how people currently solve this problem?
My way is to copy all relevant files intov1 / v2 etc folders.
Then I link to the versions from the index page of my prototype like this:
This of course means I have loads of duplicate files in my prototype, but the benefit of anyone on the team being able to access old changes outweighs that minor disadvantage.
Then for logging why changes were made, I've got my user researcher to log research insights as Issues and then I reference those issues in Pull Requests.
Works well for me!
@sanjaypoyzer yeh definitely looking for how people do it, thanks v much!
We have to consider that old versions might rely on older versions of Frontend, and will stop working if you update the kit.
Just a quick note that the home office blog post linked about 404s—the new location is here: https://ukhomeoffice.github.io/coe/guidance-tools/versioning-prototypes/
In my case, versions in prototypes take the following format:
- Each new version gets its own branch (version-1, version-2 etc)
- A version is current until it has been through a round of user research
- a new version is created the day after the last research session for the previous version (in most cases)
- Prototype kit upgrades to latest versions get their own dedicated branch, kit-upgrade, and happen in isolation without any changes to the user journey.
- A/B testing can be done by appending a/b/c to a branch (e.g. version-1a, version-1b etc)
- On Heroku, each version, or key version, gets its own app instance. All Heroku apps are set to auto-deploy their own branches and are named to identify the version (e.g. ch-prototype-v1)
- Heroku also contains 3 additional apps for each service prototype, named:
- ch-prototype-dev Always the most recent version currently being worked on, before a round of user research. (unverified)
- ch-prototype-uat Always the version currently being tested with users. (undergoing verification)
- ch-prototype Always the last version to have completed a full round of user research. (verified)
- The 3 apps above give us a way of sharing the prototype in a way that does not require someone to keep track of what version we are on. We use the -uat app for user research sessions. For A/B tests will will use the version instances, -4a, -4b, etc instead of -uat
- Versions used for service assessments get their own app instances, e.g. ch-prototype-alpha. They are manually deployed from a specific version branch and are static from that point on.
Something I've considered but not had time to put into practice yet is release versions. At present, any and all of our version branches could be in a state of flux where some problems are fixed but others are added. It would be good to highlight any point where the user journey is broadly stable as a 'release candidate' version.
on support, someone having difficulties with a custom approach to versioning that had over 7,000 lines in a routes file managing each page individually