Lesson 7 - Polish With Real Feedback

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

That matters because many internal tools fail for straight forward 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.

We’d consider this to be product refinement, especially once end users have tried it out.

What Taylor Hears From The Team

Once HarborFlow account managers and ops reviewers try the tool, Taylor 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.”

This is all actionable feedback.

What To Refine in the Blueprint

Look for improvements such as:

• 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 operations 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

HarborFlow Outcome

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

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.

Checkpoint Blueprint

Use lesson-7-blueprint.toml if you want a complete, working file after a small polish pass on labels, priority vocabulary, success messages, and the approval action.

The checkpoint should validate cleanly:

zebric validate --blueprint lesson-7-blueprint.toml

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.