NR-543 · Week 5 of 8 · Design, selection and usability

NR-543 Week 5 Design, Selection and Usability: How to Write It

The short answer

Design is where requirements become a future state that someone could actually build, and NR-543 Week 5 asks you to specify one and defend it. The written work usually carries three strands: a future-state design for your workflow, an evaluation of options against criteria you set rather than criteria a vendor supplied, and a usability argument grounded in how clinicians read screens under interruption. The unit of judgment is fit, not features. Your section may print this as NR 543 or NR543; 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.

NR-543 Week 5 grading scale at Chamberlain, the criterion levels this assessment is scored on, from Chamberlain Tutors
How Chamberlain grades NR-543 Week 5, visualized by Chamberlain Tutors.

What NR-543 Week 5 asks for

Every experienced nurse has met a system that met its specification and was still miserable to use. A telehealth triage screen that requires the nurse to close the call documentation to look up an allergy satisfies both functions and fails the workflow, because the design ignored that the two tasks happen inside one conversation with a patient on the line. That failure has a name in this course. It is a usability failure, and usability is not the same thing as functionality, nor is it a matter of taste.

The concepts a graduate submission is expected to handle here are cognitive load, the cost of interruption, error-provoking design, and the difference between what a system permits and what it makes easy. Clinical work is interrupt-driven, and interruption is the reason default values, screen ordering and click depth matter so much. A field placed three screens from the task that needs it will be skipped by competent people under load, and the informatics answer is to move the field rather than to retrain the people.

The selection strand runs on the same logic. Evaluating options means building a criteria matrix from your own requirements, weighting the criteria before you look at any option, then scoring each candidate against them with a stated basis. Weighting after you have seen the options is how a preference gets dressed up as an analysis, and graders can spot it because the winner always happens to lead on the heaviest criterion. Options do not have to be commercial products. Reconfiguring an existing screen, changing which role enters an element, and adding a report are all options, and in a course paper they are often the honest ones.

Expect a design paper, a comparison table, or a written evaluation with a recommendation. Some sections add a discussion about a usability principle; keep the post specific and final, since posts do not reopen after submission in Canvas.

The NR-543 Week 5 method, step by step

Six moves for designing and defending a future state.

  1. 1. Convert your requirements into design decisions one at a time

    Each requirement should produce a visible choice: what is displayed, where, to whom, triggered by what. A design section that does not trace back to the requirement list will read as invention, because that is what it is.

  2. 2. Draw the future-state flow beside the current one

    Same convention, same boundaries, same lanes. The value of the pairing is that removed steps, removed handoffs and removed waits become countable, and countable differences are what the closing weeks will evaluate.

  3. 3. Specify the screen or artifact at the moment of decision

    Name the elements that must be visible together at the point of action, in what order, and what is deliberately not shown. Describing what you excluded is a stronger signal of design thinking than listing what you included.

  4. 4. Weight your evaluation criteria before you score anything

    Derive the criteria from your requirements, assign weights, and write the weights down with their justification. Then score. Doing it in this order is the difference between an evaluation and a rationalization.

  5. 5. Apply a named usability heuristic set to your own design

    Walk your future state against published usability principles and report where your own proposal is weak. A design paper that finds no fault in its own design is not being read carefully enough by its author.

  6. 6. State the work your design creates and for whom

    Nearly every redesign moves effort rather than deleting it. Say which role absorbs the new burden, how much, and why that placement is defensible. Silence here is the most common reason a strong design section still loses points.

A layout and word budget for a design and evaluation paper

Our frame for a design-phase submission, sized for roughly 1,200 to 1,500 words plus any diagram or matrix. It is our outline rather than anything the university issues, and your week's rubric outranks it wherever they disagree.

SectionWhat belongs in itWord target
Design intentThe one sentence that says what the future state changes, and the requirement it exists to satisfy.90 to 120
Future-state walkthroughThe redesigned sequence from trigger to stop point, with the steps and handoffs that no longer exist called out.280 to 350
The decision surfaceWhat appears at the point of action, in what order, and what was deliberately left off the screen.200 to 250
Options and criteria matrixTwo or three candidate approaches scored against weighted criteria derived from your requirements, with the basis of each score.240 to 300
Usability appraisalYour own design walked against a named heuristic set, including the weaknesses you found in it.200 to 250
Burden and recommendationWho absorbs new work, how much, and the option you recommend with the criterion that decided it.150 to 200

Evidence craft for design and usability writing

Use a published heuristic set and name it. Usability principles for health systems exist in the literature, and applying a named set gives a grader something to check your appraisal against. Invented headings turn an evaluation into an opinion with subheadings.

Do not quote vendor marketing as evidence of capability. Product pages describe intent. Where you rely on one, say that the claim is the vendor's own and attribute it, then note what independent evidence would confirm it. Graders read uncritical vendor citation as an evaluation failure.

Support design choices with human factors research, not preference. Click depth, default values, alert placement and information grouping have been studied. One well-chosen source converts a sentence about what nurses like into a claim about what error data shows.

Cost your claims in units. Removes two handoffs and one duplicate entry per encounter is checkable. Streamlines the process is not. Where you estimate rather than measure, say the number is an estimate and give the basis in the same sentence.

Keep safety design language accurate. Forcing functions, constraints, defaults and alerts are distinct mechanisms with different failure modes, and using them interchangeably is directly visible to a grader teaching this material.

Five mistakes that cost points in this week's territory

  • Feature lists in place of design. Naming capabilities the system would have is a catalog. Showing where information appears, to whom and at which moment is a design.
  • Criteria weighted after the options were compared. The evaluation stops being an analysis the moment the weights are chosen to produce the answer you already had.
  • A single option presented as a comparison. One candidate with two obviously weak alternatives beside it is a rationalization, and the pattern is easy to see from outside.
  • Usability treated as appearance. Clean, modern and user-friendly describe a look. Time to complete, steps required, error rate and interruption recovery describe usability.
  • No account of new burden. Every redesign moves work somewhere. A paper that claims a change with no cost has not examined its own proposal.

Before you submit

  • Every design decision traces back to a numbered requirement from the analysis stage
  • The future-state flow uses the same boundaries and conventions as the current-state map
  • Removed steps, handoffs and waits are counted rather than asserted
  • Evaluation criteria are derived from requirements and weighted before scoring
  • A named usability heuristic set is applied, including to your own proposal
  • The paper states who absorbs new work and how much
  • Every vendor claim is marked as the vendor's own

Designing the future state for NR-543?

Send the rubric and your requirements list out of Canvas. A premium original draft comes back in 24 to 48 hours with criteria weighted before scoring and the new burden named, and revisions run until the grade lands.

Questions students ask about this stage

I am not a designer. How detailed does the design section have to be?
Detailed enough that a reader could tell whether your future state had been built. That is a lower bar than it sounds, and it does not require any technical drawing skill. The elements a grader is looking for are specific: which information appears together, at what moment in the task, to which role, triggered by what, and what happens when the expected information is missing. You can express all of that in prose and a simple flow, and a plain sketch of the decision surface with labelled boxes is more than enough visual material. What does not clear the bar is a paragraph describing how the redesigned process would feel to use. Feelings are the outcome of design decisions, and the decisions are what the rubric is scoring.
Am I allowed to recommend a process change rather than a technology?
Yes, and it is frequently the stronger paper. Information workflow problems are often solved by changing who enters an element, when it is entered, where it is displayed, or which existing report is routed to which role, and none of that requires procurement. What matters is that you reach the recommendation through the same disciplined route: criteria derived from requirements, weighted in advance, options scored on a stated basis. A process-only recommendation can look thin if you present it casually, so give it the same rigor a technology recommendation would get, including its risks and the burden it shifts. Add one sentence saying explicitly that you evaluated configuration and process options against acquisition, since demonstrating that you considered the cheaper route is itself a mark of informatics judgment.
Can I use screenshots of our actual system?
Generally no, and the safer path costs you nothing analytically. Screenshots of a production clinical system risk exposing patient information even after cropping, they may breach your employer's policies on system images regardless of content, and vendor interfaces are often protected material. The alternative that carries the same argument is a labelled sketch or wireframe of your own making, described as a representation rather than a capture. Draw the layout as boxes with field names, mark what is above the fold and what requires scrolling or a second screen, and annotate the click path. That version is arguably better evidence for a design paper because it isolates exactly the structural features you are analyzing instead of burying them in interface decoration a reader has to look past.

Keep going

Online now