Product Owner Case Study #2: Iterative Editing

This post is about my software product Hyperion. You can read more about it here.

The Original Design

A Hyperion administrator is able to edit the PIT count survey: adding, deleting, and editing questions.

Edit Survey

My expectation was that the workflow would look like this:

  1. Edit the survey as needed.

  2. Create a new PIT count in the software, and use it for that year.

Create PIT Count

  1. Many months later, tweak the survey to reflect changes for the new year.

  2. Create another PIT count for that year.

I architected the software with that use case in mind.

  1. The survey structure is attached to the organization.

  2. When an admin edits the survey (and saves it) the updated survey is saved to the organization.

  3. When an admin creates a new PIT count, the structure attached to the organization is copied into the PIT count. Then, when a volunteer accesses the PIT count, they receive that version. When an admin makes a change to the survey, it doesn’t affect an ongoing PIT count.

The Emergent Behavior and Misunderstanding

In reality, the survey-editing process was iterative. Administrators would make a couple changes to the survey, create a PIT count, go through the volunteer portal to see what that was like, and then realize that they needed to make more changes to the survey. They could always create a new PIT count that would reflect the new changes but:

  1. That’s annoying.

  2. Administrators rarely realized this on their own. They would edit the survey in the admin portal and then expect that change to be immediately propagated to the existing PIT count. Then, they would reach out to me about a “bug.”

The Solution

I want/need to have a revision system for the survey editing anyway. I’m planning on leveraging that to reduce confusion around the behavior and support the emergent behavior of iterative survey editing.

When administrators edit the survey and save, they’ll be prompted to give that survey revision a name:

Choose version when saving survey

When they create a new PIT count, they’ll choose which survey revision they want to use for that PIT count:

Pick revision when creating PIT count

This alone should clear up the confusion around the survey editing behavior.

While I’m at it, I’ll add the ability to change the survey version currently available for a particular PIT count. This will allow their iterative editing and serve as yet another reminder that if they edit the survey it won’t automatically be applied to all existing PIT counts (behavior I don’t want for many reasons).

comments powered by Disqus