In order for a Forms instance to show variable values, there needs to be a submission event to record those variable values.  Submission events are typically the submission of a form (Message Start Events or User Tasks), but can also be things like a Workflow Service Task, or an administrator manually changing variable values from the Monitor page.

So you are not going to be able to have variable values saved without one or more of those submission events happening.

We have several processes that include an employee working on a task for an extended period of time, and often needing to make iterative changes.  So on those, I have buttons for "Complete" (usually the Submit button) and for "Save Changes" (usually the Reject button).  When they hit the "Save Changes" button, it does submit the task, but the process routes right back to the task to assign to them again.  It only routes to the next part of the process when they hit the "Complete" button.  They can hit "Save Changes" as many times as they need with their iterative changes.  I'm not using the Save Draft functionality here, because I need the values actually updated to the process each time they Save Changes - for reporting reasons, similar to what you have listed.  This has worked very well on multiple processes for us.

Note that if an instance gets to have a LOT of submissions (many dozens or even hundreds), it does start to slow down when opening forms, as the system reviews all that submission history to determine what changes to display.  This isn't usually a problem with a staff member doing "Save Changes" like I mentioned above, as it would require a lot of those saved changes, but I have had some that did a lot of iterative submissions from Workflow until it started to have a noticeable impact.  That's just something to be aware of.