Prioritizing Recommendations by Technical Effort

1. The Language of Effort: T-Shirts and Time-Boxes

To align with a development roadmap, you must speak the language of developers. Vague terms like "easy" or "hard" are not enough. You need a system for estimating effort that your client's technical team will recognize and respect.

T-Shirt Sizing

This is a common agile estimation technique used to assign a relative size to a task, not a specific number of hours. It’s fast, collaborative, and avoids the trap of promising exact timelines.

Your role isn't to be a perfect estimator, but to facilitate the estimation. During your audit, you can make a preliminary guess, which you will then validate with the client's engineering team.

Time-Boxing (Dev Days & Sprints)

This is a more concrete form of estimation. While you won't be committing the client's team, using these terms demonstrates that you understand their workflow.

• Dev Day: One developer's work for one day.
• Sprint: A fixed period (usually 1-2 weeks) in which a team completes a set amount of work.

To see how this looks in a professional deliverable, let's examine an example from a real agency.

As the article states, knowing whether a change is a "2-hour task or a 2-day refactor" is what makes your recommendations credible and actionable.

2. The Calibration Conversation with Engineering

You are not expected to be a software architect. Your power comes from asking the right questions. The "Finding Classification Matrix" you built in the last lesson is your guide for this conversation.

Schedule a 30-minute call with a product manager or a lead engineer from the client's team. Present your initial findings and ask them to help you calibrate the effort.

Your Script:

• "I've identified this issue with inconsistent filtering. In my experience, this is usually a front-end cleanup. I've classified it as Safe to Fix and estimated it as an S or M t-shirt size, maybe a few dev days. Does that sound right based on your codebase?"
• "This navigation flow is confusing, but I suspect it's tied to the way user permissions are structured. I've flagged this as Tied to Architecture and a potential XL task. Am I correct in assuming this is a major piece of work?"

This approach positions you as a collaborative partner, not an outsider making demands. Watch the following video to see this dynamic in action.

The key takeaway is that you present your priorities, but the final plan is a collaboration based on technical reality and business needs.

3. Assembling the Prioritized Roadmap

Now you will create the final deliverable. This roadmap combines everything: the UX problem, its business impact, and its technical effort. The goal is to create a simple prioritization matrix.

Your roadmap will formalize this into a table that a product manager can directly use for sprint planning.

Task (30 minutes): Build the "Prioritized Audit Roadmap" in Figma

1. Open your Figma Project: Return to your Sales Assets page.
2. Create a New Frame: Title it Prioritized Audit Roadmap. This will be a key page in your final audit report.
3. Build the Roadmap Table: Create a table with the following columns. This structure is based on the professional examples you've reviewed and is designed for maximum clarity.

4. Populate with Placeholder Examples: Fill in 2-3 rows to demonstrate how the table works. Use the classifications from the Startup House example and your previous lesson's matrix.

   Example Row 1 (Quick Win):

   • ID: F-01
   • Recommendation: Merge duplicate filters on the search results page into a single, consolidated panel to reduce user confusion.
   • Impact: High (Reduces friction in core product discovery flow, likely to improve conversion).
   • Effort (T-Shirt): S
   • Effort (Est. Time): 2-3 Dev Days
   • Priority: Quick Win

   Example Row 2 (Strategic Initiative):

   • ID: N-03
   • Recommendation: Redesign the core navigation to be role-based, showing relevant items to Admins vs. Viewers.
   • Impact: High (Significantly improves efficiency for power users, reduces clutter for new users).
   • Effort (T-Shirt): XL
   • Effort (Est. Time): 2-3 Sprints
   • Priority: Strategic

5. Add a Key: Below the table, add a small key defining the Priority levels:

   • Quick Win: High-impact, low-effort fixes. Recommend for the next 1-2 sprints.
   • Medium-Term: Significant improvements that require planning. Recommend for the next quarter.
   • Strategic: Large initiatives requiring architectural changes. Recommend for the 6-12 month roadmap.

This component is now the centerpiece of your audit's "next steps" section. It's a powerful tool that demonstrates you've thought through not just the problems, but the practical path to solving them.

Conclusion

In this lesson, you have moved beyond simply finding problems to creating a strategic, technically-grounded plan. This elevates your work from a simple critique to a valuable consulting deliverable.

Key Takeaways:

• Speak the Language: Use developer-friendly estimation terms like T-Shirt Sizes and Dev Days/Sprints to build credibility.
• Calibrate with Experts: You don't guess the effort; you facilitate a conversation with the client's technical team to get a realistic estimate.
• Prioritize with a Matrix: The goal is always to identify the "Quick Wins"—high-impact, low-effort fixes that deliver immediate value and build client trust.
• The Roadmap is Your Product: The Prioritized Audit Roadmap is a tangible asset that product managers can use directly, making your audit incredibly actionable and justifying your fee.

Next Steps:

You now have a complete process for delivering a high-value audit. The final piece of the puzzle is converting this one-off project into a long-term relationship. In the next lesson, we will focus on tactics for proposing a recurring "performance review" or design retainer, ensuring you create a sustainable revenue stream from each client you win.