MontyCloud's MSP customers needed to answer WAFR questions at a granular level to claim $5,000 AWS credits — but no interface existed for it. I designed the first question-level tracking interface in a 14-day sprint. The feature made the workflow possible; the UX decisions made it usable.
Outcome: 0 MSPs had successfully claimed credits before. Within 6 months, 16 had.
What Existed Before
MontyCloud had WAFR check execution, but the interface was minimal:
- A basic table view of checks
- Summary stats showing High Risk and Medium Risk counts
- Findings donut charts (Passed/Failed/Error)
- No filtering, no drill-down, no question-level tracking
- No progress visibility ("How far along am I?")
MSPs were manually tracking question status in spreadsheets. It took 8-12 minutes just to identify which issues were high-risk. Zero MSPs had successfully claimed AWS credits through the platform.
How This Started
PM came to me with a straightforward request based on customer feedback: "Customers are asking for a question-level interface. They need to track individual WAFR questions to claim credits."
My first step was competitive research. I looked at:
- nOps (direct competitor) — had a question-level interface
- AWS's native WAFR tool — had its own question tracking
Both validated the pattern. Customers expected question-level granularity because they'd seen it elsewhere. This wasn't about inventing something new — it was about building a missing capability and making it work well within our constraints.
I used both as reference for interaction patterns (segmented navigation, question sidebar, progress tracking). The differentiation would come from usability, not from the concept itself.
Design Decisions
1. Interactive Risk Filtering
The existing summary showed counts like "6 High Risk, 12 Medium Risk" — but they were just labels. Static text.
I made them clickable. Click "6 High Risk" and the question list filters to show only high-risk items.
This reduced time to identify critical issues from 8-12 minutes to roughly 30 seconds.
It wasn't a novel pattern — filter chips are standard. But in this context, connecting the summary directly to the question list removed a step users were doing manually (scanning the full list, counting severity levels, trying to remember which ones mattered).
2. Status Icons vs. Color Dots
PM initially proposed colored dots to indicate question status — green for done, red for high risk, gray for unanswered. This was the pattern nOps used.
I pushed back with a specific argument: colored dots fail for color-blind users. A red dot and a green dot look identical to someone with red-green color blindness. That's roughly 8% of male users.
My alternative: semantic status icons — pending clock for unanswered, x-marks for high risk, exclamation for medium risk, checkmarks for none, dash for not applicable. Each icon communicates status through shape, not just color.
PM agreed immediately when I showed the accessibility argument.
3. Progress Tracking
Added a progress bar showing "6/57 questions answered" at the pillar level.
This was critical for the credit claim workflow. AWS needs evidence of remediation progress. Without visible progress, MSPs couldn't demonstrate to AWS that they were actually working through the framework.
What didn't ship: Historical progress tracking (a timeline view showing WAFR scores improving over time). Scoped out due to the 14-day timeline. The data infrastructure for tracking changes across multiple WAFR runs didn't exist yet.
What We Shipped
- Severity filter bar: Clickable status counts (All, Unanswered, High Risk, Medium Risk, None, Not Applicable)
- Pillar filter bar: Clicable pillers with question count (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability)
- Left sidebar: Question navigation (1-11) with status icons
- Main panel: Question details, best practice checklist, risk exposure, findings counts, notes field
- Side Drawer Info Panel: Open on click of 'i' button for each options, highlights the explanation of that option in the side drawer panel
Plus lens navigation tabs showing progress per AWS pillar (e.g., "Operational Excellence — 0/11").
Impact
Measured outcomes (6 months post-launch):
| Metric | Before | After |
|---|---|---|
| MSPs who claimed AWS credits | 0 | 16 |
| Time to identify high-risk issues | 8-12 min | ~30 sec |
| Assessment completion rate | ~34% | ~87% |
| Support tickets (WAFR confusion) | 23/month avg | 3/month avg |
Attribution honesty:
The jump from 0 to 16 credit claims wasn't because of good UX polish — it was because the feature made the workflow possible at all. Before this, MSPs literally could not track questions through MontyCloud. They had to use spreadsheets or AWS's native tool.
The UX decisions (filtering, icons, navigation) made the tool usable and efficient. But the feature itself made credits claimable. I want to be clear about that distinction because it's easy to overattribute business outcomes to design work.
The completion rate increase (34% to 87%) is a clearer signal of UX impact — that's people finishing a process they previously abandoned, not a new capability.
Process
14-day sprint:
- Days 1-2: Competitive research, PM alignment, initial wireframes
- Days 3-5: Design iteration, engineering feasibility check
- Days 6-10: Detailed design, daily PM syncs, developer handoff
- Days 11-14: Implementation support, edge case handling, QA
What the daily PM syncs looked like:
Short (15-20 min). Mostly about scope management. "Can we add X?" followed by "What do we cut to fit?" The 14-day constraint was real — no one pretended otherwise.
What I'd Do Differently
Test with actual MSP customers, not just PM feedback. We validated through PM's understanding of customer needs, which was generally accurate but filtered. Direct usability testing with even 2-3 MSPs would have caught edge cases earlier.
Push for analytics instrumentation from day one. The "30 seconds" metric came from observing 3 users post-launch, not from proper instrumentation. I should have scoped analytics tracking into the initial sprint.
What I Learned
Competitive research isn't admitting defeat. Looking at nOps and AWS's native tool gave us validated patterns and saved days of exploration. The value wasn't in inventing a new paradigm — it was in executing well within proven patterns.
Constraints force honesty. 14 days meant we couldn't hide behind complexity. Every decision had to justify itself immediately: "Does this help MSPs claim credits faster?" If no, it's out.
The PM relationship matters more than the PM disagreement. The status icons conversation is a good example. PM had a reasonable idea (colored dots work for most people). I had a better argument (accessibility). It resolved in 5 minutes because we had a working relationship, not because I "won" a debate.
