Log the set you did.

The journal flow I reviewed sits in an active workout. A sheet contains exercises, effort, time, reps, weight and access to history. Numeric entry exposes a keyboard and units. That context matters more than how tidy the journal looks on a presentation board.

An empty weight field is not automatically a UX failure. It may simply mean today’s set has not been entered. My narrower hypothesis is that a returning member sometimes needs a previous record while deciding what to enter. I would first compare an inline reference with the existing View History route.

In this revision I made the input interaction the central artifact. I also expanded the illustrated scope explicitly: the proposal includes a focused set editor, not only a new history card above an unchanged table. That is a larger change and must earn its cost.

I considered an automatic suggestion, a copied editable value and a reference kept outside the input. I chose the reference. A record from September 24 describes that day; it does not establish what happened in the current set.

The cost is screen space and another piece of information to interpret. If it distracts experienced members or reads as coaching advice, an on-demand reference may be better. I have not validated that choice in a workout setting.

The proposal labels the previous date, reps and effort, then gives today’s input its own heading. A different weight is ordinary data. Nothing congratulates someone for matching the past or implies that a higher number is required.

I first separate the last set from today’s empty fields. Only a deliberate entry turns those fields into a draft. In the next screen, today’s 22 kg and 10 reps remain unconfirmed while the keyboard is open; the historical 24 kg stays outside the input.

This is a proposed focused editor over the workout context, not simply a history card inserted above an unchanged table. I chose that larger surface to keep the reference, current field and confirmation visible with the keyboard. It must earn that space in a real workout. “Per dumbbell” is an explicit convention for this authored example; Ladder’s actual convention must be confirmed before implementation.

I rejected changing only the unit label. The same draft appears as 22 kg or 48.5 lb at the chosen display precision; the previous 24 kg becomes 52.9 lb. The underlying quantity must survive repeated switches without accumulating rounding error.

The keyboard stays open after the unit switch because editing is still in progress. Only Confirm set closes it and changes the record’s state. I keep Edit this set on the outcome screen rather than forcing someone to rediscover correction through history.

The four images make empty, draft, converted draft and confirmed states inspectable together. They specify behavior; they do not prove native keyboard handling, saved account data or synchronization. No other set is marked complete by this action.

My matching rule starts with movement identity, equipment, side and recording convention. Effort can differ if the difference is visible. An ambiguous convention is a reason to withhold comparison.

Changing equipment should clear an incompatible reference immediately. It should not silently reinterpret a draft. A late history response must not overwrite the member’s input. These are proposed interaction contracts to verify with engineering and coaching owners, not an assertion about Ladder’s architecture.

The production design would distinguish an unsaved draft, a record stored on the device and a server-confirmed record. A failed history lookup should not block any of them. Retry must reconcile one operation rather than manufacture another set.

The screen sequence defines the distinction between a draft and a confirmed entry. Offline persistence, restart recovery and cross-device conflict handling still need implementation and separate tests. A confirmation image is not evidence that those reliability requirements have been solved.

I would run situated prototype sessions with people who already track strength workouts. In a pause between sets, they would inspect history, enter a different load, change units and correct a record. I would observe wrong-unit entries, lost drafts, confusion between past and present, and the need to reopen history. Time is secondary to correctness.

The feature should be reduced or removed if it is interpreted as a recommendation, obstructs the keyboard, or adds work without helping the target scenario. Increased set logging would not compensate for those failures. These sessions are planned. The authored screens make the decisions reviewable, but are not usability evidence.

The reference only helps when compatible history exists. Applying a potential benefit to every subscriber would overstate reach. The recurring cost also includes movement metadata, unit conventions and regression maintenance, not just a few interface components.

I would first validate the need and the input interaction. Only then would I consider a larger behavioral test of useful journal use while protecting workout completion. Retention remains a downstream hypothesis, not a result of this proposal.

My main decision is now visible in the work itself: keep the previous record as evidence, make today’s entry editable, and require an intentional confirmation. The next question is whether that clarity survives the pace and constraints of a real workout.