Challenge
Account and product journeys crossed multiple states and surfaces. As GivingData expanded, feature placement and navigation needed a more coherent structure.
Rolled out to clients
app.givingdata.com
Payment approval
Amount requested
$42,500
68% of budget allocated
Approve
Request edits
Re-architecting navigation for a platform
outgrowing its structure
Product Design
Information Architecture
I identified that GivingData’s growing product surface had outgrown its navigation, then led the redesign end-to-end, from journey mapping to a shipped, client-facing redesign.
At a glance
- Company
- GivingData
- Role
- Product Designer · second designer
- Focus
- Information architecture and cross-platform navigation
- Scope
- Grants-management platform and related product ecosystem
- Collaborators
- Executives, development, and marketing
- Related work
- Mobile navigation and design-system development
My Role
- Identified the opportunity and proposed the initiative
- Resolved journey friction and explored navigation layouts
- Refined feature placement and built a testable high-fidelity prototype
Methods
Journey Mapping
Information Architecture
Wireframing
Interactive Prototyping
Design Systems
// executive summary
Executive summary
My contribution
I identified the opportunity, proposed the initiative, mapped journey friction, explored navigation layouts, refined feature placement, and built a testable high-fidelity prototype.
Outcome
The redesigned navigation was implemented and rolled out to clients. I also initiated mobile navigation work and created a documented design system spanning foundations and reusable components.
// result
The navigation was implemented and rolled out to clients.
// context
A product ecosystem outgrowing its structure
GivingData builds grants-management software for grantmakers and grant applicants. I joined as the company’s second designer and worked across its core platform, grantee portal, public website, e-commerce and event pages, marketing, and advertising.
During my tenure, the company expanded internationally and grew from roughly 15 to more than 40 employees. That growth is context, not an outcome I attribute to this project. It increased the importance of creating a structure that could work across a broader product ecosystem.
// research
The navigation problem showed up across journeys
I began by documenting points of friction across user journeys. This map traces account activation as a sequence of screens, system actions, and decision points: the kind of structural complexity that makes navigation decisions hard.
Web-native interpretation
One activation journey, three system states
The reconstruction separates the dense source map into identity checks, activation actions, and destination states so the handoffs are easier to inspect.
Identity stateDoes an account already exist?
ScreenEdit username
DecisionUsername exists?Existing or new identity record
Activation stateCan the person establish access?
System actionSet pending activation
ScreenEmail → password setupLinks the identity and product states
Destination stateWhere does the person land?
DecisionLogin successful?Success and recovery paths diverge
DestinationGivingData or portal home
- Question
- Where did a core journey branch or hand off between systems?
- Decision
- Use the journey structure to identify where navigation and feature placement needed clarification.
- Tradeoff
- The map surfaces where the system itself gets complicated, not which of those moments actually frustrated people; pairing it with usability testing would show which steps felt hardest.
// information architecture
From journeys to information architecture
Wireframes made the hierarchy concrete. I explored navigation layouts, then refined where features lived and how global destinations related to page-level navigation.
Illustrative reconstruction
Comparing navigation arrangements
Two directions I tested for the same question: which destinations stay persistent, and where does contextual navigation take over.
- Question
- Which destinations should remain persistent, and where should product features live?
- Decision
- Surface key destinations by name while retaining context-specific navigation inside the product.
- Tradeoff
- More explicit labels use additional screen space, but they reduce reliance on interpreting icons alone.
// prototype
A testable model of the system
I translated the direction into an interactive high-fidelity prototype in Sketch and InVision, prepared for user evaluation and implementation discussion. Connecting many product states made the proposal concrete.
Interactive workflow reconstruction
Following a request through the product
This representative workflow shows how the navigation model connects dashboard context, cross-product search, request review, and payment approval.
Orient to assigned work and pending decisions.
Move across product objects without losing global context.
Review context, requirements, and related records together.
Complete a focused decision within the same system.
- Question
- Could the proposed navigation hold together beyond one screen?
- Decision
- Connect representative states in a high-fidelity interaction model.
- Tradeoff
- High fidelity made the proposal concrete enough to greenlight, but concreteness isn't validation; that came later, through implementation.
// mobile
Extending the information architecture to mobile
I initiated mobile navigation exploration, translating core destinations into a drawer and dedicated search entry points for smaller screens. This was an initial direction I scoped and designed, not a shipped mobile release.
Illustrative reconstruction
Three states of the mobile navigation model
These screens walk through the drawer, selected-navigation, and search concepts as a single sequence.
Workflow reconstruction
From an organization record to cross-product search
The sequence makes the proposed relationship between global navigation and a task-oriented destination grid easier to inspect.
- 02Choose Search & ReportsUse a named destination and selected state rather than an icon-only shortcut.
- 03Scan the destination gridMove directly to an object type such as Organizations, Requests, or Payments.
Swipe to compare screens.
-
01 Organization overview
9:41● ●Animal FriendsOrganization overviewOverviewAboutGrantee 360RequestsActive grant requestRecent activityProgress report scheduledSite visit completedRequest approvedCore content remains available beneath a compact global app bar and page-level tabs.
-
02 Selected navigation state
My workspaceNavigation⌂ Home◌ Notifications⚙ Settings⌕ Search & Reports▥ Payments & Approvals▣ Requirements☷ Workflows⇄ Grantee Portal▱ Portfolios＋ Quick AddLog outThe drawer keeps destinations named and makes the current location visible without relying on icons alone.
-
03 Dedicated search entry
9:41● ●Super SearchChoose a destinationSuper SearchQuick Search▦Organizations▱Requests$Payments✓Requirements□Documents▤Portfolios◎Contacts☷TasksA task-oriented grid provides direct access to core objects and workflows on a narrow screen.
Extending the pattern to a grant lifecycle
A speculative sketch, not GivingData product: fictional organizations and amounts, used to test whether the navigation pattern could scale from search to a full grant workflow.
Scroll horizontally to follow the grant process.
Prioritize incoming work
Surface requests that need review, deadlines, and approvals before opening an individual record.
Resolve due-diligence gaps
Separate completed checks from open questions and preserve the context needed for a defensible recommendation.
Control fund release
Show installment timing, approval state, and release conditions without losing the connection to the award.
// design system
One navigation fix exposed a bigger problem
The GivingData product had originally been designed about nine years earlier. Codebase modernization had not been matched by an equally systematic design update, and the navigation and product-redesign work exposed longstanding visual discrepancies and design/code debt. I recognized the need extended beyond one navigation component and initiated a comprehensive design system from the ground up.
Navigation redesignReworking global and local navigation made cross-product differences visible.
Inconsistency auditSimilar actions and interface patterns were represented in different ways.
Reusable systemFoundations and components created a shared structure for the wider product.
The audit: similar actions, different patterns
The audit captured visible mismatches between the portal and GivingData product. The examples show that this was not one isolated button problem: the differences reached action hierarchy, icon treatment, navigation, status indicators, cards, and dropdowns.
From isolated discrepancies to shared rules
Organizing the comparisons by the decision each pattern must support made the fixes clearer.
PatternObserved variationSystem response
Add action＋ Add Another⊕ Add New ItemDefine one action hierarchy and label pattern.
Edit control✎✎Specify icon, container, size, and state behavior.
ProgressConnect color and position to consistent status meaning.
NavigationPAYMENTS & APPROVALSActive GrantsSeparate global destinations from contextual navigation.
Delete action⌫⌫ DeletePair destructive color with a consistent label and confirmation pattern.
DropdownSelect initiative⌄All
Arts
Foster CareDefine trigger, selected value, menu width, and keyboard behavior together.
Arts
Foster CareDefine trigger, selected value, menu width, and keyboard behavior together.
- Question
- Which repeated patterns made equivalent actions and states look different across product surfaces?
- Decision
- Treat the discrepancies as a system problem rather than a series of isolated screen cleanups.
- Boundary
- These are representative examples from the audit, not a full inventory of every component reviewed.
The system: foundations and components
I organized the documented system into two layers. Design foundations captured shared brand and interface guidance; component documentation tracked reusable product patterns and their documentation status.
DesignLogos & iconsColorsDark modeTypographyLayoutIllustrationsComponentsNavigationButtonsData displayFeedback indicators
Foundation
DocumentedColor and interface foundations
Primary, accent, status, and neutral roles
Grantmaking, structured clearly.
Hierarchy and usage guidanceComponentStatusDocumentation
BreadcrumbReadyDocumented pattern
PaginationReadyInitial documentation
Sortable tabsReadyDocumented pattern
- Question
- How should shared visual rules and reusable interface patterns be organized so teams can find and discuss them?
- Decision
- Separate foundations from components and make documentation status visible inside the library.
- Boundary
- The structure was documented consistently; not every category reached the same level of maturity or adoption.
Governance: an ongoing product responsibility
The system was not a one-time library handoff. Managing and refining it became part of my ongoing responsibilities, paired with biweekly synchronization sessions with the development team to coordinate component integration.
Initiated
I identified the systemic gap during product redesign and developed the design system from the ground up.
Maintained
I managed and refined the system as the product continued to evolve.
Coordinated
Biweekly development sessions kept design decisions and component integration in regular conversation.
Verified outcome
A documented design system existed across foundations and components. Maintaining it became an ongoing responsibility, and development coordination happened on a biweekly cadence, supporting more consistent implementation across the product.
What I would measure today
To strengthen the story, I would track component adoption, engineering usage, duplicated implementations, accessibility coverage, and release velocity.
// website
The same systems thinking, applied to the public site
The same systems thinking carried into GivingData’s public website. I conducted competitive analysis, created an audience model, developed a messaging framework, shaped content direction, and created a website information architecture.
Strategy synthesis
From market context to a public-site structure
The documented work follows one sequence: understand the landscape, frame the audience, define a messaging position, then organize the website around customer value.
GM
Grants managerCoordinates relationships, reviews, decisions, and reporting across a portfolio.
- Needs a coherent view across grant stages
- Balances diligence with relationship context
- Explains decisions to internal stakeholders
Why GivingDataMission
Customer benefitsProduct overview
Proof and learningStories · articles · webinars
- Question
- How should GivingData connect its market position, audience needs, and product story?
- Decision
- Translate competitive and audience framing into messaging pillars, content direction, and a public-site hierarchy.
- Tradeoff
- The working persona focused the narrative, but I'd want to validate it against primary research before leaning on it further.
// demonstrates
What this project demonstrates
- Spotting a systemic product problem before being asked to fix it
- Turning ambiguous cross-platform journeys into a defensible information architecture
- Getting executive buy-in for a scope larger than the original ask
- Carrying a proposal from structure through prototype to a shipped release
- Owning a design system end-to-end: audit, structure, and ongoing governance
- Coordinating regularly with development to keep design decisions and implementation in sync
// evaluation
How I would evaluate the system today
Formal usability testing, behavioral metrics, and post-launch analytics weren't part of my role on this initiative. I built the prototype to be test-ready; implementation and client rollout are the outcome I can speak to directly. Here's what I'd add if I were running this today.
The lasting lesson was that information architecture becomes organizational infrastructure during growth. A navigation decision affects more than one menu: it shapes feature ownership, cross-platform consistency, component governance, and how teams explain the product.
// end of case study