My work
From urgent requests to a shared decision framework
From urgent requests to a shared decision framework
Overview
We were working across two teams in a scaling SaaS where urgent requests kept coming in, but there was no shared way to assess them, scope them, or turn them into reusable decisions. I created The Blueprint Hub to give those requests a clear starting point: a lightweight framework to align faster, document just enough, and keep moving with clarity under pressure.
1. Challenge
1. Challenge
A fixed request landed: design a date-range selector for a planning module. It had already been sold, approved, and partially defined, even though it was not a standard industry pattern.
The challenge was not whether to build it, but how to solve it without letting urgency turn it into a one-off exception or weaken the standards we were trying to establish.
2. Approach
2. Approach
I started by structuring the request, not by designing:
- capture the request,
- narrow the decision space,
- check what already existed,
- decide what was worth turning into system value.
Step 1 → Trigger
Step 1 → Trigger
Before opening Figma, I turned the incoming ask into a trigger artifact that made the request legible under pressure by surfacing what was fixed, what was being asked, and how far the solution had already been shaped.
Checkpoint → Mapping
Checkpoint → Mapping
Next is not a proper step but a necessary checkpoint. I mapped the ecosystem around the request to remove noise and turn an overwhelming situation into a decision space I could actually work with.
Step 2 → Scan
Step 2 → Scan
With the map clear, I ran a quick inventory check: did anything reusable already exist? The combined component did not, but several of its parts did.
Request breakdown:
- 2 editable date inputs
- 1 two-handle slider
That gave me enough evidence to move into the Gap Map.
Step 3 → Gap Map
Step 3 → Gap Map
With the evidence clear, I built a gap map to decide which parts added value to the Design System and which should remain dedicated to the case. The question was not whether the component had to be built, but where that effort should become system value.
Step 4 → Decision Log
Step 4 → Decision Log
Finally, I documented the final decision in the Decision Log; what each part would become, which states it needed, and where it would live. That turned one urgent request into a repeatable way of working the team could use again.
3. Outcome
3. Outcome
The component shipped, but the bigger result was operational: the method became shared.
- 7 decisions documented and traceable in the first two weeks.
- 13 requests processed by month 1.
- 2 teams working the same way by month 2.
4. Learnings & next
4. Learnings & next
The framework worked, but it exposed a weak point: under real urgency, people tended to skip the questions and jump straight to solutions. The issue was not the method itself. It was the effort required to run step 1 well under pressure.
That insight led to the next iteration: turning step 1 into a focused AI Claude Skill. You give it a request, and it returns a structured brief with the scope already framed. Step 1 is live. Steps 2 to 4 are next.
Fig. 6. Summary view of the Blueprint Hub method, designed to make the logic easier to share and reuse across the team.
Beyond this case: The Blueprint Hub Series
The wider body of writing behind the framework, its context, and what it evolved into.