-
Notifications
You must be signed in to change notification settings - Fork 34
Research & Testing Strategy
ButtersUSDS edited this page May 29, 2018
·
12 revisions
Note: This is a work-in-progress document.
- What is necessary to make a usable open source library for Developers?
- What is necessary to make a usable FORMS Best Practices Guide for both Developers and Non-technical Users?
- What are the most important features to add to U.S. Forms System library next?
-
Research
- Define user personas (and determine the smallest set of experience required, per Scratch Interview)
- Interview developers or other professionals who have experience with open source communities
- Interview UX professionals who have experience testing open source tools
- Do a comparative analysis of existing "good" open source tools and cite patterns in their developer experience
- Research Hackathon best practices
-
Documentation
- Post interviews on the wiki
- Post interview takeaways and comparative analysis findings in a doc on the wiki
-
Testing
- Start with a simple paper form and ask users (developers—user personas TBD) to use the tool to simply replicate it as a web form
- Determine bugs and documentation usability problems
- Fix the above
- After bugs and usability problems have been addressed, hold a Forms Hackathon wherein participants bring real government paper or PDF forms that they will transform into web forms during the event
- Forms made from the Hackathon can be featured as exemplars in the U.S. Forms repo
-
Dates
What is necessary to make a usable FORMS Best Practices Guide for both Developers and Non-technical Users?
-
Research
- Define user personas
- Interview USDS UX professionals to gather forms best practices for government form users (include PRA)
- Research best forms practices (private sector) that are also applicable
- Do a comparative analysis of writing styles and framing devices on best practice guides (e.g. are rhetorical questions the most effective framing device? Is a linear, step-by-step guide ideal? Or just a simple set of topics?)
- (optional, probably for later) Research alternative ways of integrating rhetorical questions into a form-builder GUI in order to make a seamless producer experience that organically leads to a great end-user experience
-
Documentation
- Capture the above research in raw form in the wiki
- Write a summary document and put in wiki
- Write a draft plain language Best Practices Guide for testing
-
Usability Testing
- Test Idea #1: Start with a simple paper form and ask users (developers or pair of 1 developer and 1 non-technical user) to use both the tool and the Best Practices Guide to transform the form into a web form (and improve it).
- Test Idea #2: Start with a more complex paper form and ask a non-technical user to use just the Best Practices Guide to map out (either on paper or software they are comfortable with) a better form experience that a developer could create using the tool.
- Write 2nd, 3rd, etc… drafts of the Guide based on test results!
-
Dates
-
Research
- Create an inventory of existing features to establish an accurate baseline
- Create an inventory of missing features that exist on other government forms
- Determine the forms we want to use as exemplars of the tool and cite missing features necessary to build them
- Prioritize new features based on the exemplars
- After Hackathon, do a comparative analysis of existing form builders (both open source and non) to start a backlog of nice-to-have features.
- After our community starts making feature requests, new feature prioritization can evolve based on this community activity
-
Documentation
- All of the above will first be captured in the wiki, but soon they will be move to and live in issues
-
Usability Testing
- New features for specific exemplar forms will be tested on that form's users first
- Non-specific new features will be tested for usability and accessibility using the VA's apparatus
-
Dates
- Current (Phase 2) Roadmap
- Phase 1 Information
- Release Process
- Stable: 1.2.0 (GitHub, npm)