At a Glance
GivingData's Docket and Portfolio features both let users group grant records together. Neither had the depth to support how foundations actually used them, and nothing distinguished one from the other. Before we could design a better experience, the team needed a shared definition of the problem and a clear reason to prioritize it.
Challenges
- Docket and Portfolio looked like near-duplicates from the outside, but foundations were trying to use them for two very different jobs.
- Neither feature had the depth to support its actual use case, so users were improvising workarounds.
- The team didn't yet share a clear sense of what each feature was actually for, which left us without a path forward until we defined it.
Role
I owned the project end to end: surfacing the problem, defining what each feature should become, and leading design through delivery.
Process
- Discovery: I dug into how foundations were actually using both features and found the real pattern underneath the confusion: two distinct jobs sharing UI that didn't fully serve either one.
- Define the vision: I framed Docket as an operational tool for board meeting prep, and Portfolio as a strategic tool for managing high-level initiatives and rolling up data to present to leadership.
- Build the case: A clearer vision alone wasn't enough to get the work prioritized. I connected each feature to how GivingData packages the product: Docket as a core capability, Portfolio as an enterprise one. I also pulled in long-standing client requests that would make the distinction tangible in the product itself, like acting on many grants at once, managing workflows and tasks inside a docket or portfolio, and logging interactions on a portfolio the way users already could on other records.
- Prototype and validate: I prototyped the new docket and portfolio concepts directly in code using GivingData's recently updated design system components. I gathered user feedback on the prototypes, then revised the designs based on that feedback before development began.
- Deliver in phases: Rather than a single release, I scoped the work into phases. Some work has shipped, some is in active development, and the rest is committed on the roadmap. I was mindful of how each phase would land for clients already using the existing versions.
Impact
- Turned two confusing, overlapping product areas into two clearly differentiated areas, each solving the job it was actually intended to do.
- Secured prioritization by tying the vision to product tiers and outstanding client feedback, not just a cleaner UX.
- Validated the new concepts with users through code prototypes before development started, catching issues while they were still simple to fix.
- Set up a phased delivery plan that let the platform improve incrementally without disrupting foundations mid-workflow.