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.

General

• Bi-weekly: Every other week
• Subregulatory instead of sub-regulatory

Research and Design

• 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
• Live code version
  • Stock / Legacy : eRegs more or less as you can pull it from the original open-source code (eRegs GitHub)
  • Dec Snapshot : eRegs Dec. MVP with some updates
  • Working Draft / Pilot : The current version we're actively developing
    • In more "complete" versions, review everything from punctuation to pixel alignment to animations on UI interactions
    • In less complete versions, you should get some context from the dev(s) on what level of polish/UI/content/database interaction to expect

Research

• 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

Regulation Structure

• Title: e.g. 42 (and it our case only 42)

  • Subchapter: e.g. A, C, D (not really used in eRegs structure) A grouping of Parts
  • Part: e.g. 433 A set of regulations within a Title
    • Subpart: e.g. "Subpart A" a set of sections. Not used in citations.
      • Subject group: Do not appear often (i.e. "Assignment of Rights to Benefits") and not used in citations or referenced.
      • Section : Usually, but not always underneath a subpart (i.e. 433.1 Definitions)
        • Paragraph 433.1.a 433.1.a.2

• Regulation Text / Piece of Regulation: Any bit (chonk/chunk) of regulation text

Sidebar Content Structure Naming Conventions

• Subpart Resources / Supplemental Content (SupCon): Everything in the right sidebar. Content that relates to one or more Chonk of regulation.

• Subregulatory Guidance: A specific category in the right sidebar

• Category (example: "Statutes/Executive Orders" - everything under this will be collapsed)

  • Name (example: "Social Security Act Section 1903(a)")
  • Reference (a reference to the resource, reachable by the web)

Language We are Not Using

Prototype: Use only with "limited" or "HTML," not by itself

Cupcake : Just because :-)