The University of Florida moved its performance review process into Workday, and staff and managers across every UF campus needed to understand how it worked before their first cycle. I designed Managing Performance as a concept course rather than a click-through: it explains what a performance review is for, how the lifecycle works, and why the conversation matters, while the step-by-step Workday tasks live in a separate Instruction Guide. That split was a deliberate call. It kept the course focused on understanding rather than procedure, so the training would still hold up as the interface changed. I worked as the sole instructional designer, building from two subject-matter-expert transcripts and ongoing review from a functional lead.

The course runs across five modules that build toward a single idea: the review record is the byproduct, and the conversation is the point. Each module sets up the next, from what a review is, through the lifecycle and the three review types, to the performance conversation itself, and closes with a summary that ties the thread together. I deferred all procedural content to a companion guide so cognitive load stayed on the concepts, and I wrote every module for a mixed audience of staff and managers rather than defaulting to one. The goal was a learner finishing the course understanding not just what to do, but why the process is shaped the way it is.

The hardest constraint was the audience: staff and managers, across three distinct populations (staff, postdoctoral, and University Police), on multiple campuses. Every "who is this for" decision flowed from that. When early drafts drifted manager-centric, I reworked them so staff were not just watching someone else's masterclass. I also treated review feedback as a design signal rather than a checklist. When a reviewer flagged that a section had been mentioned several times already, or that a preparation tip actually belonged to the self-evaluation step, I traced it back and cut or moved the content instead of patching it. That back-and-forth with SMEs and reviewers shaped the course as much as the initial plan did.

Where a concept was hard to carry in prose, I built a custom interaction to carry it instead. The strongest example is the access-gating simulator: two side-by-side panels show the same review from the manager's view and the employee's view, and the learner steps through the stages to watch the employee's panel stay locked until the conversation happens. The gap between the two panels is the lesson, and no bulleted rule could show it. I also built a six-moment conversation walkthrough that lets learners move through a realistic review discussion one moment at a time, plus a template selector, a comparison table, and scenario-based knowledge checks. Several of these went through real iteration. The conversation, for instance, started as one long dialogue and became six navigable moments after testing showed the single block was too much to take in at once.

To get interactions Rise 360 could not produce natively, I authored self-hosted, accessible HTML components and embedded them as iframes. Every component was built to WCAG 2.1 AA: contrast-audited against the palette, a 15px minimum font size, full keyboard operation with arrow-key and Home/End support, screen-reader semantics with live regions and managed focus, and reduced-motion handling. I audited contrast with luminance calculations and traced the markup by hand, which mattered more than it sounds: hand-tracing caught a lost-focus bug and a heading-level gap that automated checks had passed. I treated accessibility as a design constraint from the first draft of each component rather than a pass at the end.

I held the content to the source material rather than to plausible-sounding filler. Where an early draft explained a design rationale I had invented, I replaced it with the actual data from UF's own program document, including retention and engagement figures I could cite. When two official sources disagreed on review cadence, I flagged the conflict for resolution instead of quietly picking one. And where a subject-matter expert described a process as their best understanding rather than confirmed fact, I kept it marked as open rather than shipping it as certain. That discipline, grounding claims in verifiable sources and being honest about what is not yet confirmed, is the part of this project I would carry into any other build.

• Managing Performance gives UF a concept foundation that a multi-campus, multi-population audience can share, while the procedural guide handles the parts most likely to change. Just as useful, it establishes a reusable standard: a component library and an accessibility baseline that later courses in the catalog can inherit rather than rebuild. The measure I care about is not that learners can complete a Workday task, but that they understand why the conversation comes first, which is the behavior the whole program is trying to support.