-
Notifications
You must be signed in to change notification settings - Fork 10
Team terminology
This list is for our team to help us communicate in consistent ways among ourselves! For readers outside our team, this may also be helpful as a reference while reading our materials.
- Bi-weekly: Every other week
- Subregulatory instead of sub-regulatory
-
Wireframe : Low-fidelity, grayscale design
- Review general structure and placement of UI elements and content, interactions, user flow
-
Mockup : High-fidelity, visual design
- Review colors, typography, icons, placement and language on UI elements (i.e. buttons, navigation)
-
Limited prototype : High-fidelity, mimics a working website but will not have all the functionality since it's essentially a series of flat images with links to each other (Figma)
- Review user flow, content/language to the degree it will help/hinder test users, interactions
- Skeleton / HTML prototype: Functional HTML/CSS that's not hooked up to the back-end/database - can be used for testing or connected to the back-end
-
Generative research dives into "What problem might we solve?" while evaluative research asks, "How well is our solution working? - Erika Hall, Co-founder of Mule Design Studio
-
Generative research explores the motivations, pain points, and behaviors of target users, and happens at the beginning of the design and development process.
-
Evaluative research is focused on assessing design concepts throughout the design and development process with target users.
- Formative evaluations test design concepts early and often to evaluate what works well or not and why. Typically qualitative or mixed method.
- Summative evaluations test how well a design performs overall. It is Usually done towards the end of the design process. Typically quantitative (task success rates, time on task, etc.)
-
Usability testing: usability testing is an evaluative research method that involves observing users as they attempt to use a product or service while they think out loud. The primary goal of is to understand a product or service's usability (how learnable and adaptable it is) and how good it is at preventing users from making errors
-
Snowball Sampling: Where one member of the population is identified and subsequent sampling is identified by requesting referrals for subsequent interviewees.
-
Purposive Sampling: a nonprobability sampling method in which elements are selected for a purpose
-
Convenience Sampling (aka availability): samples participants based on who is available or easy to find.
-
Participant management: Managing participants who are being tested (i.e. emails, calendars, spreadsheets, etc.)
-
Respondent management: participant management but also includes people who do not explicitly participate (functionally interchangeable)
-
Themes: A group of data pulled into a category around action, or experience (e.g. "documenting activities", "Adapting to individual learning styles") - used to create insights, also used by Dovetail
-
Insights: A description of truth that is more than a statement of fact and has emotional resonance, like a newspaper headline (e.g. "customization is the rule not the exception") - used by Dovetail
-
Findings : Anything identified through the usability testing process that is actionable for the team. Findings can be positive or negative themes, usability issues, and/or bugs
-
Recommendations : In a usability test report, any finding that requires action is considered a recommendation
- Resources: Everything in the right sidebar. Content that relates to one or more chunk of regulation.
- Subregulatory Guidance: A specific category in the right sidebar
Please note that all pages on this GitHub wiki are draft working documents, not complete or polished.
Our software team puts non-sensitive technical documentation on this wiki to help us maintain a shared understanding of our work, including what we've done and why. As an open source project, this documentation is public in case anything in here is helpful to other teams, including anyone who may be interested in reusing our code for other projects.
For context, see the HHS Open Source Software plan (2016) and CMS Technical Reference Architecture section about Open Source Software, including Business Rule BR-OSS-13: "CMS-Released OSS Code Must Include Documentation Accessible to the Open Source Community".
For CMS staff and contractors: internal documentation on Enterprise Confluence (requires login).
- Federal policy structured data options
- Regulations
- Resources
- Statute
- Citation formats
- Export data
- Site homepage
- Content authoring
- Search
- Timeline
- Not built
- 2021
- Reg content sources
- Default content view
- System last updated behavior
- Paragraph indenting
- Content authoring workflow
- Browser support
- Focus in left nav submenu
- Multiple content views
- Content review workflow
- Wayfinding while reading content
- Display of rules and NPRMs in sidebar
- Empty states for supplemental content
- 2022
- 2023
- 2024
- Medicaid and CHIP regulations user experience
- Initial pilot research outline
- Comparative analysis
- Statute research
- Usability study SOP
- 2021
- 2022
- 2023-2024: 🔒 Dovetail (requires login)
- 🔒 Overview (requires login)
- Authentication and authorization
- Frontend caching
- Validation checklist
- Search
- Security tools
- Tests and linting
- Archive