Authored design record · fictional case
This record makes the product assumptions behind the RelayWorks roster-import practice visible. The role used to frame the questions is a fictional product operations lead. No SME interview, collaboration, product review, or sign-off took place.
Performance objective: a new training-operations coordinator can correct a blocked CSV roster using an approved people-data source, then review a structurally valid update before applying it—without changing unaffected records or inventing missing values.
Included: required fields, exact text IDs, allowed team-code values, match behavior, whole-file validation, source comparison, preview confirmation, and readiness after edits.
Excluded: real-system configuration, file transport, permissions design, email delivery, identity resolution, exception handling beyond the sample, and production deployment. This is an HTML software-practice sample, not a native Rise or Storyline course. All changes in it are local practice.
“Load the roster with the new people and any updates. Clean up obvious formatting first, then run validation. Check the preview and make sure the roster looks right before you finish.”
Authored fictional memo. “New people,” “obvious,” “looks right,” and “finish” leave consequential product behavior unspecified.
The memo could lead a learner to infer a person from a changed name or email, repair an ID by guessing, treat a successful validation as approval, or assume omitted people are deleted. The questions below turn those ambiguities into testable procedure decisions.
| Probe | Resolved answer for this fictional sample | Consequence for learning design |
|---|---|---|
| 1. Which fields are required, and what does “valid email” mean here? | Every cell in Employee_ID, Display_Name, Work_Email, and Team_Code must be present. Email must be non-space text with an @, a domain, and a dot. The check does not verify deliverability. | Teach the exact four-column check. Label the email rule as a shape check so learners do not infer mailbox verification. R1 |
| 2. How should a learner treat IDs such as 004219, and where may a correction come from? | Employee_ID is exactly six digits stored as text; leading zeroes matter. Correct an ID only from the approved source. Never guess or pad from memory. | Show the approved extract beside the file and require source consultation. Structural validity alone cannot establish the right person. R2 |
| 3. What does the system match on? What happens to rows missing from this batch? | Employee_ID is the key. An existing ID updates that record; a new ID adds one. Name or email changes do not create a new person. Absent records remain unchanged. | Contrast an ID match with an attribute change, and explicitly inspect the absent person in the second activity’s expected result. R4 |
| 4. Does validation apply good rows when another row fails? What blocks the file? | Validation checks the whole file. Missing values, invalid IDs/emails/team codes, or duplicate Employee_ID values within the file block the entire import. No partial updates occur. | Use a whole-file blocked state and field-specific feedback; do not imply row-by-row partial success. Treat duplicate IDs as a blocker. R5 |
| 5. What does a valid team code prove, and who establishes that a change is allowed? | Only OPS (Operations), ENG (Engineering), and SUP (Support) are valid codes. A valid code does not prove the assignment is right. Validation checks structure; the learner compares preview changes with the approved source/request. | Separate structural validation from authorization. Let a structurally valid but unapproved team change reach preview; make the learner catch it against the source. R3 R6 |
| 6. What makes preview confirmation stale, and what should be preserved exactly? | Any edit clears validation and preview confirmation. The learner must validate and review again. Display names, including spaces and accents, are preserved as the approved source supplies them. | Make readiness visibly reset after edits and keep source names intact. Gate Apply behind a fresh review and explicit confirmation. R7 R8 |
| Rule | Product rule carried into the sample | Evidence in the procedure or activity |
|---|---|---|
| R1 · Required fields | Four named columns; every cell present; basic email shape only. | Exact column names in reference; initial blocked file produces field-specific feedback. No claim of deliverability. |
| R2 · Exact ID | Exactly six digits stored as text; leading zeroes matter; source only, never guess or pad from memory. | Compare Omar’s 4219 with approved 004219; change only after checking the extract. |
| R3 · Team code | OPS, ENG, SUP are allowed; allowed does not mean assigned correctly. | CARE is structurally invalid; SUP is structurally valid but can be an unapproved assignment. |
| R4 · Match key and absence | Employee_ID matches; existing ID updates; new ID adds; other changes do not create a person; absent rows stay unchanged. | Two-row batch updates Lina, keeps Omar unchanged in-file, and retains absent Mei in the system. |
| R5 · Whole-file gate | Missing values, invalid ID/email/team codes, and in-file duplicate IDs block all rows; no partial updates. | Validation must be repeated for the file; duplicate ID is a blocking condition. |
| R6 · Review authority | Compare additions and changed fields with approved source; confirm preview. Validation checks structure only. | Valid update preview contains Lina’s unauthorized team change; learner restores OPS before applying. |
| R7 · Readiness reset | Any edit clears validation and preview confirmation; validate and review again. Practice data stays local. | After corrections, require fresh validation, fresh preview, explicit review checkbox, and Apply gate. |
| R8 · Preserve names | Preserve display names, spaces, and accents from approved source. | Keep names as given when correcting other fields; do not normalize, translate, or silently reformat. |
These are proposed design revisions from the ambiguous memo to the authored artifact. They are not a record of stakeholder feedback or an actual SME event.
Revised artifact: show the approved extract and ask the learner to correct Omar’s ID from 4219 to source value 004219, while preserving the ID as six-digit text. Do not accept an invented or padded value merely because it validates.
Addresses source-of-truth ambiguity · R2
Revised artifact: present required field, ID, email shape, team-code, and duplicate-ID rules; make validation block the whole file. Explain that a valid code or email shape does not prove business correctness or deliverability.
Separates structure from meaning · R1, R3, R5
Revised artifact: compare previewed changed fields with the approved request. Catch Lina’s unapproved SUP assignment even though SUP is an allowed code; retain OPS and approve the email-only change.
Adds an authorization decision · R3, R6
Revised artifact: show that Mei is absent from the batch and stays unchanged. An edit clears readiness, so the learner validates and reviews the preview again before applying.
Protects unaffected records and review integrity · R4, R7
Before adapting this exercise for a real product, a product SME would need to confirm its file schema, value constraints, email behavior, ID storage and matching, duplicate policy, update/add semantics, absence behavior, all-or-nothing behavior, preview fields, authorization source, edit invalidation, and apply controls. The fictional rules here must not be transferred to another platform by analogy.
Accessibility and usability also require direct review with the implemented sample and intended learners. Source inspection or automated checks alone cannot establish accessibility conformance or learner effectiveness.
First, ask an actual product SME to validate the fictional rule set against their own system and revise or remove any mismatch. Then have new coordinators attempt a different sample batch with its approved source and change request. Observe exact-source use, corrected field accuracy, detection of valid-but-unauthorized changes, preservation of absent records, and whether edits trigger a fresh review. Record questions and recovery behavior. Agree task-readiness criteria with the product owner before the pilot. No SME validation or learner pilot has happened, so there are no results to report.