Research Documentation Amalgamation

[onezerojeremy]

In an attempt to consolidate and open up our user research process, we're attempting to move it into a more public place.

Our first draft at this is in a github wiki.

[edmullen]

copied from slack

I ​prefer​ the approach to findings being cataloged in the wiki but placed in issues (from whichever relevant repo) like this example from Jeremy or this one from me...

…rather than putting that content into a wiki page like [this example(https://github.com/18F/FEC/wiki/4-26-test). This is particularly the case when the thing being tested is a smaller feature-level thing.

I do like the idea of bigger directional decisions that come out of research having wiki pages. I’m thinking of something like this which is the recap from the initial legal resources research and workshop. It signaled the broad directional approach which would be foundational for someone on-boarding to the legal project.

[jenniferthibault]

Love @edmullen 's idea of having a section of this wiki for summarizing process/directional decisions.

My feedback is going to focus mostly on how we capture usability results, and won't get much into other areas of the wiki-to-be yet.

On general IA models—as someone who would be using this, I'm:

• interested in tracking history of specific features or elements (and would probably recognize those features by name)
• less likely to recognize the date on which they were tested
• interested in what aspects of those features we tested, what questions we asked, and a summary of the results on their performance. What changes were made, if it was tested again at a later date, and if there was improvement or not.
  • Here I could see the Google Doc with the script being linked to from the testing date as source material reading.

To get to ^^ I could see something like this broken out from the format of testing date, instead to individual pages for the tested features. In that way, we could track what we're learning in the wiki, but file work to be done as actual issues (as Ed said) which is how it enters our week-to-week sprint planning activities. These issues could be linked to in the wiki article once they are filed. (Obvs that's not the only way, just trying to offer constructive thoughts!)

I particularly like the format of the table used in this MyUSA example from Liz for why a feature was tested, how it was investigated, and what the synthesized result of the test was: (Goals/Questions/Hypothesis/Results) . I also think the little thought bubble icons are helpful for pulling out quotes that are helpful to surface. Though the rest of that doc is definitely more that we'd need for our purposes.

[noahmanger]

Love this discussion. +1 to a hybrid issue + wiki approach for all the reasons said above. I think that wiki pages are helpful for the raw script and notes from that days testing, so I wouldn't lose those, but Jen raises a good point and maybe the synthesis should be broken out into separate pages for features, which in turn contain references to the issues. Or does that get too circuitous?

Can you nest pages in these? Could we have a section each for:

1. Big picture direction and strategy decisions
2. Synthesized findings by feature
3. Raw usability notes and materials

[onezerojeremy]

These are great thoughts, and I think I pretty much universally agree with them!

I'm working on a new version; the balance I'm trying to strike is getting both great documentation and making sure that the process is easy/fast*.

[onezerojeremy]

Ok posting a revision.

After a conversation earlier this week on the subject with @ethanheppner @jenniferthibault and @edmullen we made some headway. From Jen's notes:

• [x] make sure spreadsheet is set up for multiple note takers, try using it this week done! we'll synthesize today and see how it goes.
• [x] try putting research questions in the spreadsheet ahead of time
• if 10 minutes ahead of time counts, then success.
• [x] try synthesis from the spreadsheet into issues or MD file
• today!
• [ ] proof of concept: continue to try to get things from previous weeks gathered into consistent frameworks to kick the tires

Still don't think we're there yet but let's keep iterating I focused on one page, figuring that if we can get one page sorted, we can build and build out the IA later. Bottom up. Here's what it looks like:

here's a link to it: https://github.com/18F/FEC/blob/master/features/advanced_data_tables.md

[jenniferthibault]

❤️ ❤️ ❤️

The sections in this feel really helpful! I begin to wonder how we might compare notes on features that appear on multiple page templates, but some smart cross-linking should be able to do the trick, AND keep the notes contextually relevant. Feels like this is set up to grow in that direction!

Tables:

• I had no idea you could put gifs in tables! So cool! And really useful to see the interaction.
• What do you think of adding one/two words for each GitHub issue so that you can tell what each addresses without clicking into it? Something as simple as "Findings 1594, Findings 1652, Styling 105 .

Feature intros

I was reading this GDS article that Carolyn posted in the research channel today, which raised the 💭 of re-stating the user needs each feature addresses in the documentation. Based on what you have going on already, we could easily turn the sentence under the feature or page from prose to bullets stating user needs, if that seems useful to other folks as well

[edmullen]

I like this approach a lot @onezerojeremy. The only thing I'd add is that I think there could be some clarification of the term "feature". In your example it seems both "Advanced Data Tables" and "typeahead" are referred to as features. I'd recommend coming up with a new term for what Advanced Data Tables is. Maybe its a "feature set". The distinction means for feature sets, you make the markdown page. Features stay in issues.

Also, I'll skip today's syth, since I didn't attend the tests. But I'll review the output from that and provide feedback from the perspective of being fully asynch and reading the conclusions after the fact.

[noahmanger]

Yessss. This is so great. Nothing constructive to add—thanks for getting this together!

[adborden]

Heads up, I moved the usability research to it's own page and set up the home page to be our standard README greeting.

[noahmanger]

No further action happening on this, so closing.