Issue Templates for Figma Kit research

[kelenelee]

DS will be doing at least usability tests of the Figma Foundation template prototype. I have been tasked with creating Github issue templates so that researchers may duplicate them to make their own issues. #376

A usability test will be conducted on each FF page, and therefore each test will require the above individual issues

• Cover page
• Start page
• File menu
• DS page
• Plugin library
• Individual component page

I don't have any experience conducting usability tests. But I know where to find good guides on best UXR practices, and so I'll start from there.

I also believe that the data we have collected via the interviews do not give us enough granular detail of user tasks to justify conducting usability studies. I am concerned that, even with my best template writing, that these usability tests may not result in reliable data and are not in the best interest of the DS end users.

This task has turned into a greater evaluation of how templates should be handled in the future.

Templates as issues vs issue templates

• Delete unused new issue templates. This was before I knew that deleting .md from the file name would hide it from the new issue templates page. Regardless, these templates exist in other HfLA repos and there will be no problems with re-adding them if it becomes necessary to do so. In the future making a lot of issue templates should not be a problem as long as the issue template folder is updated to reflect the team's needs at the given time. Also, the templates page orders templates in alphabetical order of the file name. This can be used to customize the order in which templates are displayed.
• Create new issue templates that our team can use, removing issues that are "templates". Templates and copies as individual issues create a lot of repetition and spam and makes it harder for future people to sift through the board. Templates will now be copied in the comments of 1 issue. The main body of the issue will contain tasks with people's Github handles. This way, the wheel of tasks completed will accurately reflect issue progress, instead of the subtasks remaining unchecked.
  • Automate labels in issue templates (projects and milestones cannot be automated, unfortunately)
  • Add directions to add certain labels and milestones within the issue
  • Write tips on how to write a good issue in the standard issue template

Templates for the usability studies

• Research usability best practices
  • Find resources to link in the templates, to help HfLA researchers quickly learn how to conduct the study
• Experiment with the best content for templates to contain, while minimizing markdown writing and project board clutter
  
• Create templates for revising the plan, and conducting, taking notes, and analyzing a session
• Create an issue for recruiting participants

[kelenelee]

Updated issue templates are currently live on the new issue templates page.

I have also updated the Figma Kit plan so that the plan should not really need to be updated for each type of test, so the planning template either needs to be re-edited or is no longer needed at all.

[kelenelee]

Resources on how to conduct a usability test

• https://www.usability.gov/how-to-and-tools/methods/running-usability-tests.html

[kelenelee]

technically this task is complete. however this process has opened up a whole new project to rethink how we use github generally. See issue #395

[kelenelee]

I am revising the templates to better reflect the iterative nature of the FF tests

Kelene

piggybacking on this to ask if Yas or Wataru could write down the plan for round 1, 1.5, etc of testing, mentioned in last night’s all-hands meeting. I can’t find any documentation on it

Wataru

The whole round 1 and 1.5 isn't necessarily a official thing that was documented. It was just the way I described it to confirm if my understanding of the bigger picture was what Yas had in mind.

Yas

Yes as Wataru mentioned we never discussed the naming of the rounds. But from the very beginning, the iterative nature has been baked into the process when we shifted the direction towards the FF ( we discussed it numerous times during meetings.) If you are looking for a specific written document, take a look at UX/UI discovery Figjam. There should be a series of slides that I put there very early on when I presented my vision for the FF to the team.

[kelenelee]

tasks have been completed. you can see the issue templates here by clicking the green button "New issue" which appear on individual issues and on the "issues" page of the secondary nav.

Reflections

Parents "stories" and children "subtasks" are both visually equivalent as cards in Github's Kanban.

To create a visual that matches the hierarchy of epics, stories, and subtasks, I have gone with using subtasks to replace repeated templates that volunteers used to submit as their own issue. Now, the issue templates in Github's issue templates page tell users to add subtask assignees as checkboxes. The contributor work is now a template inside the main issue, which individuals then paste as a comment. The story wheel of ⭕️ # of # tasks now accurately reflects each contributor's progress to the overall story.

This has the benefit of decreasing the amount of cards present in the Kanban columns. The assignees of the child "subtasks" have been added to the parent "stories" so that volunteer contributions are not missing from Kanban search.

There are other approaches, such as custom cards with subtasks linked, but this would require archiving subtask issues, which the Kanban search feature would then not be able to display. Because Kanban search is important for the PM role workflow, we did not go this route.

[allthatyazz]

Amazing progress!