Equality Fund Impact Library

The Equality Fund Impact Library is an internal data portal built on Power BI. It centralises impact data, stories, and visualisations for EF staff, giving the team a single source of truth for reporting, grantmaking insights, and strategic communications.

The Equality Fund Impact Library took six days of design work across a four weeks. That is roughly two to three times faster than I would have managed on my own. What follows is how that actually happened, and what it says about where AI fits inside a real design process.

Every complex project carries a hidden cost, and it is the documentation loop. The first brief arrives, then a revised brief, then a data mapping, then a messaging draft that partly contradicts the first one, then a roadmap update. Each cycle costs hours of reading, comparing, and working out what changed and what that means for the screens. On a short engagement the loop complicates the design work itself.

The Equality Fund project ran on eight living documents, all of them updated during a four-week window.

I stopped treating Claude as a generator and started treating it as a collaborator that holds the entire document corpus in context at once. When a new version landed, I gave it to Claude and asked one question: what changed, and what does that mean for the screens?

That question ran ten times across the project.

The Equality Fund is a global feminist fund. The Impact Library is an internal tool for their staff, one place to find impact data, stories, visualisations and reporting frameworks. It runs on Power BI dashboards embedded in Google Sites.

The team was four people and the engagement was four weeks. I worked one to two days a week on the design, with weekly client calls and live Figma comments in between. The original scope covered five pages: Dashboard, Grantmaking, Investment, Impact Stories and Philanthropy. Mid-project the client reduced it to three. Stories and Philanthropy were deferred because the data behind them was not ready yet, and the client decided to reduce the scope.

The set ran to eight documents: brand guidelines, a master project roadmap, a data mapping, five versions of a messaging copy document, a concept note, a dummy dataset, an endline report template, and a capital continuum deck. PDFs, Excel files, Word documents and PowerPoint decks all sat in the same pile.

None of it held still. The client team kept updating throughout, and every new version meant working out what had changed and how it should affect the design. Sensitive data has been removed for this case study, so what remains here is the volume and the variety. Claude could compare any version against any other without losing track of the first document by the time it reached the eighth.

“AI helped me design” does not tell reflect the reality. Here is the specific version.

Claude took five roles on this project. As document analyst it read and compared all eight documents at once and tracked what changed between versions. As information architect it built the portal’s content structure out of raw source material. As copy collaborator it tracked draft versions and flagged where new messaging contradicted old messaging. As design executor it applied changes directly in Figma through MCP, with no manual copying between tools. As iteration tracker it generated numbered edit lists with source citations before every session.

It also spawned sub-agents: an Explore agent for deep document reading, a Plan agent for structuring each edit session, and general-purpose agents for document comparison.

The workflow ran as a loop, and every turn of it started with the documents. Claude read and synthesised the full corpus, then produced a structured edit plan: numbered changes, each one citing its source document. Those changes went straight into Figma through MCP. The result was a design iteration. A new document version would then arrive, Claude re-analysed, and the loop ran again.

That loop ran 10 times. Every iteration was document-driven, and nothing changed in the design without a source to justify it.

I used three different Claude interfaces across the project, and the order matters. I started with Figma Make for early wireframing, which generates layout quickly and was enough while the document complexity stayed low. By step four I moved to Claude Code. The corpus had grown to the point where I needed all of it in context during every session, and I needed changes applied in Figma without a handoff step. Claude Code with MCP gave me both, and it stayed the primary tool from step four through step ten.

At step eight I used Claude Cowork for a section that needed thinking through before executing. Working section by section in conversation made more sense there than jumping straight into changes. The tool shifted as the complexity grew, which is the honest answer.

The design is accurate to the content, and from step two onward it is also aligned to the Equality Fund brand. Claude was given the brand guidelines PDF and the description of elements document. It pulled out the palette: veridian teal, dark forest green, cream, warm peach. Those colours held across all ten iterations. Typography for the portal itself is Helvetica Neue.

This is the full picture. The tool progression is visible in the color coding: Figma Make for Steps Initial through 03, Claude Code most of the project, the Cowork session at Step 08. Wireframes on the left, hi-fi screens on the right. Each step represents at least one new document added to the context. The design evolved because the documents evolved, not because of a separate creative sprint. The three slides together show the complete arc: from a blank-slate wireframe at Step 01 with placeholder text only, to fully branded hi-fi with real data visualisations and complete copy at Step 10.

Before every design session Claude generated an edit list. It named the section to update, the exact change to make, and the source document that triggered the change. The largest single plan held sixteen items.

All sixteen went through in one session. Claude proposed a structured plan, I reviewed and approved it, and only then did the changes happen. That is what accountability looks like in practice, and it is a long way from letting AI run loose on a live file.

Three pages shipped: Dashboard, Grantmaking and Investment.

The Dashboard carries the Equality Fund’s overview and value proposition, the global-to-local grantmaking model, the multiplier effect, and a country-level breakdown of partners and funding. Grantmaking is the most content-heavy of the three, holding the rationale for investing in feminist movements, a regional funding map, goal-tracking charts and reach data. The Investment page covers gender-lens investing strategy, impact metrics, the Continuum of Capital model, and a set of frequently asked questions.

The Grantmaking page traces back to five separate sources. Program introduction copy came from the concept note in the original brief. “Why Invest in Feminist Movements?” came from the fifth draft of the messaging copy. The money-by-region map came from the data mapping document. “Progress Against Our Grantmaking Goals” came from the FRF 4W sample dataset. “1 Million+ People Reached” came from the endline report.

Three things I’d take from this project to any similar brief. AI is good at synthesis. Reading, comparing and connecting eight evolving documents is exactly the work it handles well, and it is also where designers burn the most time on complex projects. The speed on this project came from removing the re-synthesis loop entirely.

MCP removes the handoff gap. Nothing sat between Claude’s decisions and the Figma canvas. Claude did not describe a change and then wait for me to apply it. Claude made the change itself.

The human stays in control. Every edit was proposed, reviewed and approved before anything moved on the canvas. I saw every change before it happened. Claude accelerated the execution, and my judgment shaped every outcome.