First
Service
A power-user production tool, run by a volunteer covering Sunday at the last minute. This project redesigns the first hour at the controls so a first-timer can run a live service without fear of breaking it.
A self-initiated concept project redesigning the volunteer onboarding experience for ProPresenter's live production interface.
Everything a reviewer needs, at a glance
Renewed Vision
UX Researcher + Product Designer
Last-minute or unexperienced users of Pro Presenter
Three weeks
Self
Figma · VS Code · Claude
Low confidence with first-time users
ProPresenter is professional-grade live production software trusted in major venues, yet most of the people running it on a given Sunday are volunteers with minutes of preparation. The recurring complaint in public reviews is not that the tool lacks power. It is that a first-timer cannot reach that power safely while a room watches.
Understanding where the learning gap is.
The same software is praised and resented for the same reason. Across public reviews one contradiction repeats: the depth people love is the depth that strands a first-timer. Capability is not the problem. The climb to use it under pressure is.
Goals
- Locate the specific moments where a first-time operator loses confidence.
- Separate genuine learning gaps from interface defects that can be designed out.
- Identify the single highest-leverage change rather than a longer list of fixes.
Assumptions to test
- Volunteers are motivated to serve; motivation is not the bottleneck.
- Most distress clusters around going live and recovering from a mistake.
- The full power-user surface is overwhelming as a first surface, not as a tool.
A corpus of verified public reviews on Capterra and GetApp, plus Renewed Vision's own Volunteer Operator's Guide. Reviews were coded for the moment of failure and the emotional language used. This grounds the project in real operator voices rather than assumption.
A planned interview study across four groups: volunteer operators, worship leaders, church media directors, and experienced operators. Five to eight participants per round, semi-structured, focused on the first-service narrative. Designed and ready to run; results would replace the projected baselines below.
“it can be very daunting to know where to start”
“give a crash course before service to fill in”
“WAY to complicated for the average person”
Five tools operators encounter in live-production and worship settings, rated qualitatively against the dimensions that matter for a nervous first-timer. Ratings are a heuristic assessment, not benchmarked scores.
| Tool | Learnability | Discoverability | Onboarding | Error prevention | Recovery |
|---|---|---|---|---|---|
| ProPresenter | Low | Medium | Video only | Weak | Unclear |
| OBS Studio | Low | Low | Community | Weak | Scene reset |
| vMix | Low | Medium | Docs | Medium | Medium |
| EasyWorship | High | High | Guided | Medium | Medium |
| Stream Deck workflows | High | High | Physical | Strong | Strong |
Read across: EasyWorship trades power for approachability, and Stream Deck succeeds by reducing a service to a few large, labeled, unmistakable buttons. The opportunity is to keep ProPresenter's depth while borrowing that approachable, recoverable first surface.
The person at the controls is not the person who bought the software.
ProPresenter is purchased by a media director or pastor, configured by a technical lead, and then operated week to week by whoever is available. That gap between buyer, configurer, and operator is where onboarding either holds or fails. Mapping it first keeps the rest of the work honest about who actually feels the problem.
Red = highest exposure to the problem. The volunteer carries the most exposure and the least control, and sits furthest from the people who could fix the setup. Onboarding is the only lever that reaches them directly.
A single Sunday touches every role on the map. The operator’s confidence is shaped upstream by how the technical lead configured the file, and it is felt downstream by everyone watching the main screen. Onboarding is not a private tutorial. It is the seam that holds a volunteer-run production together.
Churches keep the tool they can staff
A product a volunteer cannot run on week one is a renewal risk for the whole organization, not one user.
Volunteers return when they did not fail in public
The cost of a lost volunteer is recruiting and training the next one, every few weeks.
Fewer panicked Saturday-night tickets
First-run confusion and live-mistake recovery are predictable, repeatable support themes that onboarding can absorb.
Reliability is visible to the whole room
A mistake on the main screen is seen by hundreds. Confidence at the controls is a brand surface, not a private setting.
These links are a working model of how onboarding connects to outcomes, drawn from the support and review themes below, not measured revenue figures.
One sentence the rest of the project answers.
A volunteer operator with minutes of preparation must run a live service inside a power-user interface, where the controls that advance the service sit beside the controls that can break it on the main screen, and where no obvious path returns the output to a safe state.
Overwhelm at launch, fear of a visible mistake, no rehearsal, no calm way back when something goes wrong.
Dark booth, live audience, last-minute hand-off, no expert present to ask.
Dense default surface, destructive controls near navigation, system vocabulary, no recovery affordance.
Lost volunteers, higher support load, and reliability concerns visible to the whole room.
The instruments, so the findings can be trusted or challenged.
Secondary research across public reviews and Renewed Vision’s own Volunteer Operator’s Guide is complete and quoted earlier. The primary study below is a designed protocol, ready to run with a church partner. Showing the instrument matters as much as showing a result: a reviewer can judge whether the questions would surface real behavior rather than opinions.
Warm-up & context
- Walk me through the last service you ran. Where were you standing, who handed it to you, how much notice did you get?
- How did you learn the software? Listen for: nobody taught me, I watched once, I just clicked.
The first hour
- What was the first thing you weren’t sure about?
- Was there a moment you were afraid to click something? What was it, and what did you think would happen?
- Show me what you do to get a service ready. Observe rather than ask. Note hesitation, backtracking, mouse hovering.
Going live & recovery
- What goes through your mind right before the first slide goes on the main screen?
- Tell me about a time something went wrong live. What did you do? How did you get back? Listen for: I froze, I asked someone, I restarted.
- If you could undo one thing instantly during a service, what would it be?
Practice & close
- Do you ever practice before a service? What stops you, or what would make it easy?
- If you were training the next volunteer, what is the one thing you’d warn them about?
- Anything I should have asked but didn’t?
Open, non-leading, weighted toward observed behavior over stated preference. Questions map directly to the two anxiety peaks the peak-end model predicts: going live and recovering.
| Segment | Target | Recruit criteria | What they tell us that others can’t |
|---|---|---|---|
| Volunteer operators primary | 6–8 | Ran < 10 services, no AV background, recruited by their church | The first-hour confidence drop while it is still fresh, before it normalizes. |
| Worship leaders | 2–3 | Direct a live service that depends on the operator | The cost of an operator mistake to the room and the service flow. |
| Media directors | 2–3 | Own the ProPresenter setup, recruit and schedule operators | Why volunteers drop, and what they configure to protect the screen. |
| Technical directors | 2 | Configure files and displays, present pre-service | Backstage constraints and what a safe default would have to respect. |
| Experienced operators contrast | 2–3 | 50+ services, fluent in the full surface | Which early fears were real defects versus a learning curve that fades. |
Recruitment plan, not a roster of completed sessions. The experienced-operator contrast group exists to separate genuine interface defects from a curve that simply takes time.
What a first-timer expects
There is a clear “start the service” path; the rest can wait.
Clicking a slide previews it before anyone sees it.
A visible way exists to take the screen back to safe.
The thing I touch most is the biggest thing on screen.
What the default surface does
Every capability is present at once, with no first path marked.
Clicking a slide can send it live immediately.
Recovery is possible but unlabeled and discovered under stress.
Navigation sits beside destructive controls at equal weight.
Every gap between the columns is a confidence cost. The redesign closes the four that cluster around going live and recovery, the highest-anxiety moments.
Projected confidence index, modeled from review themes and the peak-end framework, to be calibrated by the study above. The two troughs, going live and recovering, are exactly where the redesign concentrates.
Discoverability can a new user find it?
Learnability confident in one sitting?
Recovery graceful when it breaks?
Heuristic scores (0–5) from a structured expert evaluation of each tool’s first-run experience, not user-test data. “First Service” is the proposed design scored against the same rubric to show the target, not a shipped result.
Who is at the controls.
Three evidence-based personas drawn from the review corpus. They are provisional until validated by the planned interviews, but each is anchored to language operators actually used. The design is built for the least confident of them.
Maria, the Sunday fill-in
Open this week's service, advance cues in order, return to the welcome loop at the end.
Doug, the greeter who said yes
Advance to the next slide on cue and clear to logo between segments. Nothing more.
The regular operator
Fluent, fast, and protective of the keyboard accelerators and deep show controls. Any simplification must not slow this person down or hide what they rely on.
The media director
Owns the system, trains the team, fields the support calls. Wants volunteers who can run a service unsupervised and a clear path from beginner to confident.
The bilingual operator
Runs a Spanish-language service. The interface and the flow cannot assume English. A first-class bilingual path, not an afterthought.
The first service, drawn as an anxiety curve.
Mapping the experience stage by stage exposes where confidence is lost. By the Peak-End rule, people remember an experience by its most intense moment and its ending. Today both are negative: the service breaks, then the operator is left wondering whether they did okay. Hover any stage to trace it.
| Stage | Actions | Thoughts | Emotion | Pain point | Opportunity |
|---|---|---|---|---|---|
| Launch | Opens the app, sees the full editor. | “Where do I even start?” | Overwhelm | Eight layers of controls greet a beginner. | Volunteer View as the default surface. |
| Prep | Hunts for this week's content. | “Is this the library or the playlist?” | Confusion | Library, playlist, and presentation blur together. | Plain labels and a guided load step. |
| Rehearse | Has nowhere safe to practice. | “I guess I'll just figure it out live.” | Unease | The first real run is the live run. | Practice Mode with no live output. |
| Go live | Advances cues as the service runs. | “Please don't let me click the wrong thing.” | Tension | Risky controls sit next to navigation. | Live/Next tally; destructive controls hidden. |
| It breaks | Wrong slide or black screen appears. | “How do I undo this? Everyone can see.” | Panic (peak) | No obvious path back to a known-good state. | One persistent “Back to safe” tap. |
| After | Service ends, hands back the booth. | “Did I do okay?” | Doubt (end) | The lasting memory is uncertainty. | A calm confirmation engineered to land positive. |
Three diagnostics that point at the same lever.
A heuristic audit names the defects. The journey curve shows what they cost emotionally. The Fogg model says which lever actually moves the behavior. They converge on one conclusion: raise ability, not motivation.
Severity = Nielsen's scale: 0 not a problem · 1 cosmetic · 2 minor · 3 major · 4 catastrophe. The two catastrophes both live in the same moment — going live.
High motivation can't rescue low ability. The confident run doesn't happen.
The insight: the volunteer's motivation is already maxed — they showed up to serve. Ability is the bottleneck. So every concept raises ability (drag the dot right), not motivation. That's why "more training" fails.
When I am pulled in last minute to run Sunday's service, I want to get through it without anything visibly going wrong, so I can feel I served rather than embarrassed myself in front of everyone.
Opening surface. A first-time operator overwhelmed at launch needs a focused starting view, so that the depth of the tool never becomes the first impression. HMW open to a calm, capable surface rather than the full editor?
Live safety. An operator advancing cues under pressure needs the safe action to be the obvious one, so that the most reachable control is never the most destructive. HMW make the safe path the obvious path, live?
Pre-service confidence. A nervous volunteer needs a real run before the real run, so that their first success happens off-air. HMW build confidence before Sunday, not during it?
Recovery wins on both axes and ships first. Volunteer View and Practice Mode carry the most impact and form the core of the redesign. Labels and a guided tour are valuable but secondary.
A redesign that ignores the power user is a redesign that ships broken.
ProPresenter is mature software with paying professionals who depend on its depth. Any onboarding change has to earn its place against backward compatibility, support cost, and the people who already know every shortcut. This section is the constraint layer that kept the design buildable rather than aspirational.
Fixed
- The professional surface cannot be removed or hidden behind a wall; pros pay for that depth.
- Existing libraries, playlists, and files must open unchanged. No migration step.
- Output behavior to live displays cannot regress; the screen is sacred.
- The app runs natively on macOS and Windows and must feel native on both.
Flexible
- Which surface a brand-new file opens into, and what is emphasized first.
- Whether a safe, reversible “go live” path can sit on top of the existing one.
- Labeling, grouping, and the presence of a visible recovery affordance.
- An opt-in simplified view that is a lens on the same data, not a separate product.
| Risk | Severity | Mitigation built into the design |
|---|---|---|
| Power users feel dumbed down | High | Volunteer View is opt-in and reversible in one click. The default for existing files is unchanged. Nothing is taken away; a calmer entry point is added. |
| A safe “go live” path adds a click for pros | Medium | The reversible step is the default only in Volunteer View. Pro View keeps direct-to-live behavior and existing shortcuts intact. |
| Two views drift apart over releases | Medium | Volunteer View renders the same underlying data and components with different density, not a forked codebase. One source of truth. |
| Recovery button is mistaken for an undo of content | Low | It is scoped and labeled to output state only (“Clear screen” / “Back to safe”), visually separated from slide editing. |
| Volunteers never discover the safe view | High | First launch of a new file routes into it by default; the toggle to Pro is always visible, so discovery is the easy path, not a hidden setting. |
| Area | Consideration to resolve with engineering |
|---|---|
| View as a lens, not a fork | Confirm the existing component model can render a reduced-density layout from the same state without a parallel UI tree. |
| Output state machine | Define a clean “safe / cued / live” state the recovery control can target, distinct from slide selection. |
| Per-file vs. per-user preference | Decide whether view choice is remembered per file, per machine, or per operator profile. Affects the shared-booth case. |
| Cross-platform shortcut layer | Map a single intent table to platform-native chords so parity does not mean identical keys. Detailed in the platform section. |
| Telemetry for validation | Instrument time-to-first-live, recovery use, and view switches so the pilot can measure the outcomes claimed below. |
Power-user impact
- Default workflow for existing files is byte-for-byte unchanged on first run.
- Every current shortcut and panel remains in Pro View.
- Net effect on a fluent operator: one ignorable toggle they will never open.
Support-burden assessment
- Targets the two highest-volume first-run themes: “how do I start” and “I sent the wrong thing live.”
- A visible recovery path turns a panicked call into a self-served click.
- Onboarding routed into the product reduces dependence on a single church expert being reachable on Sunday.
These are the design’s own risk and impact analysis. Severity ratings are judgment calls to be pressure-tested with engineering and the pilot, not measured incident rates.
The decisions worth defending are the ones I argued myself out of.
Every tempting solution to this problem fails a constraint the product cannot break. Walking through the rejected directions shows the reasoning, not just the result, which is what separates a redesign from a redesign that could ship.
| Direction | First-timer relief | Power-user cost | Build & maintenance | Verdict |
|---|---|---|---|---|
| Separate Volunteer app | High | None directly | Very high · second product, drift, two codebases | Rejected |
| Force a Volunteer Mode on everyone | High | Severe · breaks pro trust | Medium | Rejected |
| Full ground-up redesign | High | Severe · relearning, migration | Very high · multi-year | Rejected |
| Opt-in Volunteer View as a lens | High | Near zero · reversible, ignorable | Moderate · one source of truth | Chosen |
Why not a separate Volunteer app?
It would relieve first-timers, but it forks the product. Two surfaces drift, files risk incompatibility, and the volunteer never grows into the tool the church actually bought.
Instead: one app, one file, a calmer lens the same operator can graduate out of.
Why not force Volunteer Mode for all?
It would guarantee discovery, but it punishes the paying professional who depends on density and speed. Trust with the core user is the thing the redesign cannot spend.
Instead: default the new file into it, keep it one visible click from Pro, never trap anyone.
Why not redesign all of ProPresenter?
The problem is the first hour, not the whole tool. A ground-up rebuild risks the depth pros pay for and a migration nobody asked for, to solve a problem scoped to onboarding.
Instead: a focused intervention at the moment the evidence points to.
Why not just remove advanced features?
The depth is the value. Reviews resent the climb, never the capability. Removing power solves the symptom by destroying the product.
Instead: defer the depth on first run, never delete it. Progressive disclosure, not subtraction.
Six rules every later decision answers to.
Principles derived directly from the research, used to keep the design honest. Each solution downstream maps back to one or more of them.
Safety before power
The default surface protects the least confident operator. Power is available, never imposed.
Progressive disclosure
Show only what this moment needs. Depth is one deliberate toggle away.
Confidence through feedback
Make state legible. The operator should always see what is live and what is next.
Recovery over prevention
Assume mistakes will happen live. Make the way back instant and obvious.
Cross-platform consistency
One experience on macOS and Windows. Only the window chrome and modifier key change.
Accessibility by default
Legible in a dark booth, operable without a mouse, and not English-only.
Three answers to three peaks.
Each concept targets one spike on the anxiety curve and one mechanism from the research. Divergence came first; convergence followed a scored decision, not a preference.
Eight fast passes, about forty seconds each. Most exist to be thrown away. Three earned a circle: the view toggle, a practice sandbox, and one-tap recovery.
Volunteer View by default
Open to a focused surface, not the eight-layer editor. The same file, fewer controls in view.
Practice Mode
A safe dry run mirroring the service with zero live output. A guaranteed early win.
“Back to safe” recovery
One always-visible tap to a known-good state, and the positive ending the memory keeps.
| Concept | Impact on confidence | Effort to build | Reuse across product | Risk | Total |
|---|---|---|---|---|---|
| Back to safe | 5 | 5 | 4 | 5 | 19 |
| Volunteer View | 5 | 3 | 4 | 3 | 15 |
| Practice Mode | 4 | 3 | 3 | 4 | 14 |
| Guided first-run tour | 3 | 3 | 3 | 4 | 13 |
| Big physical remote | 3 | 1 | 2 | 2 | 8 |
Scored 1 to 5, higher is better, including for effort and risk where 5 means lowest. The top three address all three peaks while staying buildable and reusable across the product family.
Tested poorly against the research: a wall of steps repeats the overwhelm it was meant to solve, and experienced operators resent gates. Kept as an optional first-run tour instead.
Splitting the product fragments the team and blocks the volunteer's path to growth. Two views over one file preserves a single source of truth.
High confidence value but out of scope for a software redesign and a barrier for churches without budget. The on-screen safe button captures most of the benefit.
Prevention by interruption slows the live run and trains operators to click through warnings. Recovery after the fact respects the pace of a service.
Same content, a quieter structure.
The redesign does not remove capability. It changes what the first surface presents and defers the rest behind a deliberate toggle. Current state on the left, proposed on the right.
Four flows that carry the whole service.
Each flow is designed around the least confident operator, with the rationale tied back to a design principle.
First launch
Practice mode
Running a service
Recovery
The recovery loop, drawn. A mis-click is expected and absorbed rather than prevented.
From paper to a working surface.
The chosen direction traveled a fidelity ladder. Each step earned the next by resolving a specific question.
Before pixels: a hand sketch of Volunteer View, annotated with the reasoning behind each region.
What changed
The crazy-eight scribbles became a single three-region layout: run order, live output, and a confidence panel. The decision here was spatial, giving the safe button a permanent home rather than burying it in a menu.
What changed
Mid-fidelity set the real grid, type scale, and the Live/Next state language. Hi-fidelity, the working prototype below, added platform-correct chrome and the confidence monitor, and surfaced the contrast failure that drove the accessibility pass.
A system an engineering team could build from.
The redesign is documented as a small, reusable system: foundations, tokens, components, accessibility rules, and cross-platform conventions. Color is borrowed from broadcast convention, where red means on-air and green means cued and safe, so the interface speaks a language operators already trust.
Three roles, each doing one job: a characteristic display face used sparingly, a neutral body face for reading, and a monospace face for state, timing, and keys, where alignment carries meaning.
| Token | Value | Applied to |
|---|---|---|
| color.live | #FF4B4F | Program output, destructive actions |
| color.safe | #37D27F | Next cue, recovery, success |
| color.action | #FFA23E | Selection, primary control, focus ring |
| color.surface | #11141B | App base |
| color.panel | #181C25 | Raised panels |
| text.primary | #EEF1F6 | Headings, live values |
| text.muted | #AFB8C4 | Secondary copy, labels |
| radius / space | 6 to 14px / 4 8 12 16 24 32 | Corners and rhythm |
Tokens are named for meaning. A component asks for color.safe, never #37D27F, so a theme or a high-contrast mode can be retargeted in one place.
Everything between the window chrome is shared. The same components, tokens, and layout drive both platforms, so a volunteer trained on one is immediately at home on the other and the team maintains a single source of truth. Toggle the OS in the prototype below to see only the chrome and the modifier key change.
A volunteer booth is dark, time-pressured, and rarely staffed by one body type.
Accessibility here is not a compliance footnote; it is operating conditions. Low light, stress, color-blind operators, and keyboard-only workflows are the normal case, not the edge. The design is audited against WCAG 2.2 AA, and the broadcast palette was chosen to survive a red-green color deficiency.
Contrast (minimum)
Body text and controls clear 4.5:1 on the booth-dark surfaces; large display text and state chips clear 3:1. Verified in the matrix below.
Use of color
Live, cued, and safe states never rely on color alone. Each carries a label and a shape so a color-blind operator reads state correctly.
Keyboard
Advance, recover, go live, and view switch are all reachable and operable without a mouse, mapped to platform-native chords.
Focus visible
A 2px amber focus ring with offset is present on every interactive element, tuned to read in low light without bleeding into live red.
Target size
Primary transport and recovery controls meet a 44px minimum so a tense, fast tap lands, even on a trackpad in the dark.
Motion from interactions
Transitions are short and functional. The scroll reveals and state changes respect prefers-reduced-motion and degrade to instant.
Consistent identification
The same control means the same thing in both views and on both platforms. Recovery is always recovery, never relabeled.
Name, role, value
Transport and state controls expose role and current state to assistive tech, so “live” is announced, not just shown.
| Foreground on background | Ratio | Use | Result |
|---|---|---|---|
| Ink on panel #181C25 | 13.6:1 | Body, headings | AAA |
| Muted on panel | 7.2:1 | Secondary text | AAA |
| Program red on void #0C0E13 | 4.9:1 | Live state text | AA |
| Preview green on void | 8.1:1 | Safe / cued state | AAA |
| Amber on void | 7.6:1 | Focus, active control | AAA |
Screen reader strategy
- Output state is a live region: going live announces “Now live: [slide]”, recovery announces “Screen cleared, safe.”
- Transport controls expose role and state, not just an icon.
- View switch announces which surface is active so a non-visual operator is never lost.
Cognitive accessibility
- One primary action visible at a time on first run; depth is deferred, not hidden forever.
- Plain-language labels over system vocabulary (“Back to safe,” not “Clear output layer”).
- Recovery is always available, so a mistake never requires recalling a procedure under stress.
Consistency of meaning, not consistency of keys.
ProPresenter runs on macOS and Windows, and the same volunteer may sit at either depending on the church. Parity does not mean identical; it means a Mac operator and a Windows operator both reach the same intent through the convention their hands already expect. The redesign maps one intent table to each platform’s native chords and controls.
| Intent | macOS | Windows | Principle |
|---|---|---|---|
| Search library | ⌘ F | Ctrl F | Follow the universal find convention on each OS. |
| Enter Practice Mode | ⌘ ⇧ P | Ctrl ⇧ P | Modifier swap only; the letter and meaning stay constant. |
| Go live | Enter | Enter | Platform-neutral keys stay identical to protect muscle memory. |
| Back to safe | Esc | Esc | Recovery uses the same key both places, by design. |
| Switch view | ⌘ ⇧ V | Ctrl ⇧ V | Consistent chord shape, native modifier. |
Proposed mappings that follow each platform’s established conventions, presented as the parity framework, not a claim about current ProPresenter defaults.
| Area | macOS | Windows |
|---|---|---|
| Menu bar | Global top menu; app preferences under the app name. | In-window menu; settings under Edit or a gear. |
| Window management | Full-screen spaces; traffic-light controls top-left. | Maximize/snap; min-max-close top-right. |
| Primary modifier | Command for app actions. | Control for app actions. |
| Native controls | System toggle and segmented controls, SF-style. | Fluent-style toggles and segmented controls. |
| Output display | Separate space / display for live output. | Secondary monitor for live output. |
The interactive prototype demonstrates this directly: the OS toggle reskins chrome, controls, and modifier hints to match the platform while every label, state, and recovery path keeps the same meaning.
Interactive prototype: ProPresenter's real layout, on macOS & Windows.
A faithful slice of the real three-column app, built to test the riskiest assumptions: that a focused view reduces load, that a visible safe action absorbs a mistake, and that the experience can hold across platforms. Click a slide to take it live, use the clear buttons, fumble a control, then recover. Switch the OS to see the cross-platform chrome, and flip Volunteer to Pro to feel the redesign.
The two core surfaces and the recovery path, because they carry the confidence thesis. Editing tools were left out on purpose; they are not where the first hour fails.
Confidence rises with each landed cue, a mis-click drops it and exposes the safe button, and one tap restores known-good output, making the principle of recovery over prevention tangible.
A usability test designed to prove or kill the thesis.
A redesign is not finished when it ships.
Objectives
- Can a first-time operator complete a basic service unsupervised?
- Does the safe action get used, and does it resolve a live mistake?
- Does confidence rise from before to after a run?
Methodology
- Moderated, task-based usability test, remote or in a simulated booth.
- Think-aloud during tasks, short interview after.
- SUS and a 1 to 7 confidence self-report, pre and post.
Participants
- 5 to 8 per round, recruited as true first-time operators.
- Mix of proficiency, including a low-confidence profile like Doug.
- One bilingual operator to exercise the Spanish path.
Tasks
- Load this week's service and take the first cue live.
- Run the service in order to the closing slide.
- Recover after an induced wrong-slide moment.
- Find the full controls from Volunteer View.
Three cycles of refinement.
Iterations that ran during design, driven by the heuristic findings and a small round of informal walkthroughs. Impact is expressed as the expected effect on the target metrics, to be confirmed by the full test.
How Renewed Vision could actually pilot this, and know whether it worked.
A concept earns trust by being testable. This is the plan to move the design from proposal to evidence in three phases, each with an exit metric that has to be met before the next begins. The metrics are the same ones the design claims to move, instrumented so the claim can be confirmed or killed.
Internal validation
- Moderated usability sessions with recruited first-time operators on the prototype.
- Run the task list: launch, practice, run a service, recover a mistake.
- Measure SUS, task success, and time-to-first-live against the baseline.
- Exit: task success and confidence clear target before any church sees it.
Church pilot program
- Real volunteers, real services, Volunteer View on by default for new files.
- Telemetry on recovery use, view switches, and completed services.
- Weekly check-ins with media directors on support load.
- Exit: measured drop in first-run support tickets and no power-user regression.
Production rollout
- Ship behind a default for new files, with the toggle always visible.
- Monitor the same metrics at scale; watch power-user sentiment closely.
- Roll the view-as-a-lens pattern toward the rest of the suite.
- Exit: sustained metric gains hold past the novelty window.
| Metric | How it’s measured | Baseline | Target |
|---|---|---|---|
| Time to first confident live | Telemetry, file open → first deliberate go-live | unknown / high | −50% |
| Live error frequency | Accidental output events per service | baseline | −60% |
| First-run support tickets | “how do I start / I sent wrong thing” themes | baseline | −40% |
| Volunteer confidence (SUS-style) | Post-service self-report | baseline | ≥ 80 |
| Service completion without help | Services finished with no expert intervention | baseline | ≥ 90% |
Targets are the design’s hypotheses, the bar it sets for itself, to be confirmed or rejected by the pilot. They are not measured production results.
What this would change, for whom.
Projected outcomes, organized by who benefits. They become measured results once the usability test runs.
- A first-timer completes a service unsupervised.
- A live mistake is recovered in one tap, not a crisis.
- Confidence rises measurably from before to after.
- A focused default surface with a visible path to full power.
- One shared experience across macOS and Windows.
- A reusable system of tokens and components.
- Higher volunteer retention, the people churches most need.
- Lower support burden on staff directors.
- Fewer visible mistakes, protecting brand reliability.
What worked, and what I would do next.
Naming the problem correctly did more than any single screen. Reframing the gap as confidence rather than knowledge decided everything downstream, and the Fogg lens carried the argument.
The strongest moves were subtractive. Hiding controls and adding one safe button mattered more than any new feature, which is the opposite of where I expected to spend effort.
The bilingual path is designed but under-explored. A dedicated round with Spanish-service operators would likely reshape the labels and the first-run tour.
Whether hiding controls frustrates volunteers who have started to level up. First task: can a returning operator find the full controls in under ten seconds?
The Volunteer/Pro pattern, recovery affordance, and token system are the foundation, proven on the highest-stakes surface first.
The same on-air/safe color language and one-tap recovery translate directly to playback, where a wrong clip live is the same kind of failure.
A focused operator view and visible state map cleanly to a scoreboard run by rotating volunteers under the same live pressure.
Built for the rooms Renewed Vision ships into.
This project was chosen because it sits exactly where Renewed Vision's products live: volunteer-first environments, high-pressure live production, and software that has to be reliable in front of a room.
The redesign is built for the least confident operator in the booth, the person Renewed Vision's own Volunteer Guide is written for.
Every decision assumes a real audience and no expert on hand, which is the actual condition the software runs under.
One experience on macOS and Windows, matching how the product family is built and maintained.
Legible in a dark booth, keyboard operable, and bilingual by design rather than as an afterthought.
Documented tokens and components ready to scale across ProPresenter, ProVideoPlayer, and ProScoreboard.
The work reduces the onboarding burden that quietly limits adoption, retention, and trust in the product.