Around the midpoint of a capstone practicum the writing turns from argument to artifact. The deliverable stops being a document about a problem and becomes a thing somebody could pick up and use on a shift: an algorithm, a documentation template, a structured escalation tool, a teaching module. Two pieces of writing are graded here, and students routinely produce only one. The product itself has to be written in the register of the people who will use it, and a separate rationale has to explain, in scholarly register, why every design decision is what it is. Your section may print this as NR 575 or NR575; it is the same course. Chamberlain publishes no syllabi outside Canvas. The placement here is our teaching judgment from the course's catalog arc; your section's rubric decides what your week actually asks. Clinical hours, logs, site paperwork and preceptor evaluations remain your own record and are never drafted or reconstructed with help.
What a capstone product has to prove it can do
Put a draft tool on a clipboard at a nurses' station for a shift and its problems surface in about ten minutes. Nobody reads the paragraph at the top. The field labelled other collects everything. The step that requires opening a second screen never gets completed. That informal usability audit is the standard your written product is quietly being judged against, because a grader scoring an application row is asking whether this artifact would actually function in the setting you described, and the tells are visible on the page.
A usable product has a named user, a moment of use, and a decision it supports. The user is a role and a shift context, not staff generally. The moment is a point in an existing workflow: at the bedside during a rapid response, at handoff, during the first hour after transfer. The decision is the thing the tool exists to make easier: whether to escalate, what to reassess, which criteria have been met. Write those three down before you design anything and most of the design questions answer themselves.
The second half of the graded work is the rationale, and this is where the scholarly rows live. Every element of the product should be traceable to something in your synthesis. If your algorithm has a two-hour reassessment interval, the rationale says where two hours came from. If the template asks for three fields and not seven, the rationale says what the evidence supports collecting and what evidence exists about documentation burden. A product without a rationale reads as a preference. A rationale without a product reads as a paper. The capstone rows expect both.
The role boundary applies here as everywhere in a practicum course. Building a tool is academic work and it belongs entirely to you. Implementing it in a live setting, obtaining site approvals, collecting real patient data or entering anything into a clinical system is not academic work and is governed by your site and your program, not by this manual. Any real encounter that informed the design must appear in your writing de-identified, and your hours, your log and your preceptor's evaluation of you are your own record throughout.
Deliverables at this stage often include the artifact as an appendix or attachment plus a written section that develops and defends it. Where a discussion runs alongside, treat it as final copy; posts do not reopen after submission in Canvas.
The NR-575 Week 4 method, step by step
Six moves that turn an intention into an artifact a grader can hold.
-
Write the user, the moment and the decision on one line
The bedside nurse, during the first assessment after transfer from critical care, deciding whether the reassessment criteria have been met. Every later design choice gets tested against that line, and anything that does not serve it comes out.
-
List the components your synthesis actually supported
Go back to the closing paragraphs of your evidence section and extract the ingredients: which elements of an intervention carried the effect. Build from that list. Components you add for completeness are components you cannot defend.
-
Draft the artifact in the users' register, not yours
Short imperative lines, one action per line, no citation numbers on the tool itself, no scholarly hedging. If a step cannot be read and acted on in the time available at the point of use, it will not be, and the design has failed regardless of how well evidenced it is.
-
Cut it to what fits the moment of use
A tool used during deterioration must fit one screen or one side of a page. Length is not thoroughness at the point of care; it is the main reason well-designed tools go unused. Move the depth to the rationale where it is graded anyway.
-
Trace every element back to a source in writing
Take each field, threshold, interval or step and write one sentence naming what supports it. Some will trace to studies, some to guidance documents, some to feasibility in your setting, and stating which is which is exactly what the scholarly rows are scoring.
-
Test it against three cases you actually saw
Walk the tool through three de-identified encounters from your own practicum and write what happened: where it worked, where it stalled, what you changed. That paragraph is the strongest content in the section and almost nobody includes it.
A layout and word budget for the product section
Our frame for the written section that carries the artifact, sized for roughly 1,200 to 1,500 words with the product itself in an appendix. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever the two disagree.
| Section | What belongs in it | Word target |
|---|---|---|
| What the product is | Format, length, where it physically or digitally lives, and the one decision it exists to support. | 120 to 160 |
| User and moment of use | The role that picks it up, the point in the existing workflow, and what it replaces or sits beside. | 160 to 200 |
| Design decisions traced to evidence | Each major element with the source or feasibility reason behind it, including what you deliberately left out. | 350 to 430 |
| Fit with the setting | Staffing model, acuity, existing documentation systems, and the constraints that shaped the format. | 190 to 240 |
| Walkthrough against real cases | Three de-identified encounters run through the tool, with what worked and what you revised as a result. | 220 to 280 |
| Known limits of the artifact | What it does not cover, who it is not for, and the conditions under which it would mislead. | 140 to 180 |
Evidence craft for a product rationale
Every number on the artifact needs a source in the rationale. Intervals, thresholds, cut-offs and score ranges are the elements a reader will interrogate first, because they are the elements that could cause harm if wrong. Name the guidance document or study behind each one, with its year, and say plainly where a value came from local practice rather than published evidence.
Justify omissions as deliberately as inclusions. A rationale that explains why three items were kept and eleven candidate items were dropped demonstrates design judgment. Rubric rows about application and synthesis both reward this, and it is the fastest way to distinguish your product from a checklist assembled by accumulation.
Cite the evidence about use, not only about the clinical content. There is published work on documentation burden, checklist design, alert fatigue and cognitive load during deterioration. A rationale that draws on it is arguing about whether the tool will work, which is a different and higher-scoring claim than arguing that its content is correct.
Name the standards the artifact has to live inside. Professional scope statements, regulatory documentation requirements and accreditation expectations all constrain what a tool may ask a clinician to do. Attribute them with issuing body and edition inside the sentence rather than gesturing at requirements in general.
Keep the walkthrough cases de-identified and clearly labelled as your own observation. Age bands, relative timing, no dates, no unit names, no facility. Mark them as local illustration rather than evidence, and never let a case example sit in the same sentence as a published finding in a way that blurs which is carrying the claim.
Five mistakes that cost points at this stage
- Describing the product instead of producing it. A section explaining what the tool would contain, with no artifact attached, forfeits the application row outright.
- Scholarly register on the tool itself. Citations, hedged phrasing and paragraph prose on a bedside artifact are the clearest sign the designer never pictured it in use.
- An artifact nobody could complete in the available time. Twenty fields at a deteriorating patient's bedside is a design that will be abandoned, and a grader reading your own setting description will see it.
- Elements that trace to nothing. A threshold that appears without a source is the question you will be asked at the intensive, and it is the one that is hardest to answer on your feet.
- No stated limits. A tool presented as universally applicable reads as naive. Naming the populations and situations it excludes is a strength, not a hedge.
Before you submit
- The artifact exists as an attachment or appendix, in final form
- User, moment of use and supported decision are stated in one place
- Every threshold, interval and field traces to a named source or a stated feasibility reason
- The tool fits the time and space available at the point of use
- Deliberate omissions are explained, not silent
- Three de-identified walkthrough cases appear with what they changed
- The limits section names who the product is not for
Building the NR-575 product this week?
Send the rubric and your synthesis out of Canvas. A premium original draft comes back in 24 to 48 hours with the artifact written in its users' register and every design decision traced to a source, and revisions run until the grade lands.