Based on concept testing, there is some light discovery needed around the concept of Templates within the A2J form platform. Currently, templates describe a set of fields that come prepackaged such as Name, (first, middle, last, etc.) Address (street 1, street 2, city, state, zip, urbanization) etc.
Now: There is an assumption coming out of testing that "Templates" are larger units of reusable elements but this needs further validation. In the short term, the recommendation is to rename “templates” in the Add Element sidebar to a smaller unit term.
Next: Do additional discovery on the mental model of templates/taxonomies and what level of the forms users expect to be template-able.
Later: Explore a designing a community template feature as a broader stream of work to allow for desired knowledge sharing of best practices and time-saving workflows.
UX considers this a major feature/issue due to it coming up with some participants. Review details from the research in the research report.
Overview
As a , I would like , so that I can _.
Context
Optional: Any reference material or thoughts we may need for later reference, or assumptions of prior or future work that's out of scope for this story.
[ ]
Acceptance Criteria
Required outcomes of the story
[ ]
Research Questions
Optional: Any initial questions for research
Tasks
Research, design, and engineering work needed to complete the story.
[ ]
Definition of done
The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.
[ ] Behavior
[ ] Acceptance criteria met
[ ] Implementation matches design decisions
[ ] Documentation
[ ] ADRs (/documents/adr folder)
[ ] Relevant README.md(s)
[ ] Code quality
[ ] Code refactored for clarity and no design/technical debt
[ ] Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies; dependency rule followed
[ ] Code is reviewed by team member
[ ] Code quality checks passed
[ ] Security and privacy
[ ] Automated security and privacy gates passed
[ ] Testing tasks completed
[ ] Automated tests pass
[ ] Unit test coverage of our code >= 90%
[ ] Build and deploy
[ ] Build process updated
[ ] API(s) are versioned
[ ] Feature toggles created and/or deleted. Document the feature toggle
[ ] Source code is merged to the main branch
Decisions
Optional: Any decisions we've made while working on this story
Based on concept testing, there is some light discovery needed around the concept of
Templates
within the A2J form platform. Currently, templates describe a set of fields that come prepackaged such asName
, (first, middle, last, etc.)Address
(street 1, street 2, city, state, zip, urbanization) etc.Now: There is an assumption coming out of testing that "Templates" are larger units of reusable elements but this needs further validation. In the short term, the recommendation is to rename “templates” in the
Add Element
sidebar to a smaller unit term. Next: Do additional discovery on the mental model of templates/taxonomies and what level of the forms users expect to be template-able. Later: Explore a designing a community template feature as a broader stream of work to allow for desired knowledge sharing of best practices and time-saving workflows.@jimmoffet This issue was added as a result of the UX Concept testing in https://github.com/GSA-TTS/atj-platform/issues/116 . It needs further refinement and prioritization.
UX considers this a major feature/issue due to it coming up with some participants. Review details from the research in the research report.
Overview
As a , I would like , so that I can _.
Context
Optional: Any reference material or thoughts we may need for later reference, or assumptions of prior or future work that's out of scope for this story.
Acceptance Criteria
Required outcomes of the story
Research Questions
Tasks
Research, design, and engineering work needed to complete the story.
Definition of done
The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.
/documents/adr
folder)README.md
(s)Decisions