Lesson 7 - Polish With Real Feedback

This lesson is where Maya puts the HarborFlow tool in front of real teammates and learns what still feels rough.

That matters because many internal tools fail for boring reasons:

• labels are unclear
• statuses mean different things to different people
• forms ask for the wrong information
• the app technically works, but no one wants to use it

The Goal

By the end of this lesson, the HarborFlow tool should feel narrower, clearer, and easier to trust.

This is not feature expansion. It is product refinement.

What Maya Hears From The Team

Once HarborFlow account managers and ops reviewers try the tool, Maya starts hearing comments like:

• “I do not know what counts as high priority.”
• “I need to know who is reviewing this.”
• “The status names are close, but not quite how we talk about the process.”
• “I need to know what happens after I submit.”

These are not bugs. They are product signals.

What To Tighten

Look for improvements like:

• better field labels
• clearer help text
• fewer optional fields
• more precise status values
• stronger default values
• more useful success messages

For HarborFlow, that might mean:

• changing priority labels from generic terms to the language ops actually uses
• renaming justification to Business Justification
• clarifying who owns review after submission
• simplifying any field that people misunderstand on first read

This is a good point to make tiny, testable edits instead of broad redesigns. For example:

• rename a label from Priority to Ops Priority
• change the success message so it says who reviews the request next
• remove a field that reviewers never use
• tighten status names if teammates keep interpreting them differently

After each change, run the app again and check the same core flow:

1. create a new request
2. review the request detail page
3. trigger the approval workflow
4. confirm the status and success messaging still make sense

Cut Before You Add

The default instinct after feedback is to add more functionality.

Resist that.

For this lesson, the better question is:

• what can we remove or simplify so the current flow is easier to use?

This is how the app starts feeling intentional instead of improvised.

HarborFlow Outcome

By the end of this lesson, Maya is not trying to satisfy every possible exception case. She is trying to make the core exception path obvious enough that the ops team will actually move work through the tool.

That is what makes the next step, deployment, worth doing.

Lesson Output

By the end of this lesson, you should have:

• clearer field names and labels
• simpler statuses
• better defaults and success messaging
• a release candidate blueprint that feels usable to someone other than the author

If you are not sure whether a change belongs here or in a bigger redesign, bias toward the smaller change and ship another review round.

What Changes In blueprint.toml

This lesson usually produces small edits across sections you already have:

• labels or help text in form fields
• status values or defaults in the entity
• success messages in forms
• wording on page titles or workflow actions

The point is not to add whole new systems. It is to make the current blueprint easier to trust and easier to use.

Zebric Concepts In This Lesson

• Blueprints: iterative refinement instead of first-draft generation
• Entities: statuses and defaults often get clarified here
• Forms: labels, help text, and required fields become more precise
• Pages: titles, actions, and reviewer context get cleaner
• Workflows: confirm that the existing workflow still makes sense after copy and status changes

Next Lesson

Continue to Lesson 8 - Deploy and Roll Out the Tool.