KAYLA MCCARTHY

Work

About

Contact

KAYLA MCCARTHY

Work

About

Contact

KAYLA MCCARTHY

U.S. DIGITAL RESPONSE

U.S. DIGITAL RESPONSE

Community-Centered Research

Co-researching community members' relationships to seeking, sharing, and preserving cultural heritage to inform a community-owned digital respository

ROLE

Community research support

Desk Research

Synthesis

Information Architecture

Content Strategy

CLIENT

U.S. Digital Response

TOOLS

Dovetail

Figma

Zoom

Overview

As a volunteer with US Digital Response, I joined a multidisciplinary team of researchers and a project manager to help an Indigenous tribal community evaluate whether and how to build a digital repository for cultural heritage sharing and preservation. The project spanned discovery research, platform evaluation, and information architecture — and led to a finding that reframed the design question entirely.

Overview

As a volunteer with US Digital Response, I joined a multidisciplinary team of researchers and a project manager to help an Indigenous tribal community evaluate whether and how to build a digital repository for cultural heritage sharing and preservation. The project spanned discovery research, platform evaluation, and information architecture — and led to a finding that reframed the design question entirely.

Challenge

Tribal members wanted to explore building a community-owned digital repository where cultural knowledge, stories, and heritage materials could be stored and shared. Members of the Tribe are increasingly dispersed from their tribal lands, complicating connection to cultural heritage. Furthermore, as elders get older, there's a sense of urgency to preserve their knowledge and stories for younger and future generations.


The core questions were practical: Is a digital repository something community members actually want? What platform could support it? What would it need to do? Some complexities has already emerged: not all knowledge or materials are meant for everyone, even within the community. How could the repository honor these tiers of access?


But beneath those questions was one we didn't fully surface until we listened closely to the community: How do you build a digital tool that serves cultural preservation without flattening or replacing the relational ways that knowledge has always been passed down?

Challenge

Tribal members wanted to explore building a community-owned digital repository where cultural knowledge, stories, and heritage materials could be stored and shared. Members of the Tribe are increasingly dispersed from their tribal lands, complicating connection to cultural heritage. Furthermore, as elders get older, there's a sense of urgency to preserve their knowledge and stories for younger and future generations.


The core questions were practical: Is a digital repository something community members actually want? What platform could support it? What would it need to do? Some complexities has already emerged: not all knowledge or materials are meant for everyone, even within the community. How could the repository honor these tiers of access?


But beneath those questions was one we didn't fully surface until we listened closely to the community: How do you build a digital tool that serves cultural preservation without flattening or replacing the relational ways that knowledge has always been passed down?

My Role

My Role

My contributions spanned two tracks: supporting the research process, and leading the platform evaluation and information architecture work.

Research support

  • Contributed to recruitment planning, including eligibility parameters and screening questionnaire design

  • Took notes during 7 community interviews with both elders and younger community members

  • Synthesized interview data alongside the broader team


Platform evaluation

  • Conducted desk research across 6–7 CMS and digital repository platforms, evaluating each against criteria shaped by community needs and values

  • Built a feature comparison across all platforms, then narrowed to 3 finalists using findings from interviews and 29 survey responses as the filtering lens

  • Grounded the evaluation not just in technical capability, but in whether each platform could support the community's specific cultural and relational values


Information architecture

  • Created two versions of a sitemap: an MVP and an enhanced version, reflecting different levels of investment and rollout

  • The sitemaps were designed alongside recommendations on process, governance, and tiered access — reflecting the community's need for control over who can access what, and under what conditions

Process

Process

Build relationship → Create research plan → Invite → Talk with community → Design survey → Synthesize → Desk research → Recommendations

  1. Discovery

  2. Define

  3. Ideate

  4. Prototype & Test

  5. Design

  6. Implement

Starting with relationship, not assumption

In the kickoff meeting, we opened with a conversation about how we would work together — sharing a few guiding principles drawn from our prep research, and inviting the community partners to respond: What resonated? What created tension? What did we miss? This produced a real conversation rather than a nod of agreement or silently kept assumptions.


As a white settler supporting a community that isn't my own, I was conscious of the assumptions I might carry about process, expertise, and what "good collaboration" looks like. Starting from explicit conversation rather than unspoken defaults was one way of keeping those assumptions visible and negotiable throughout the work.


  1. Discovery

  2. Define

  3. Ideate

  4. Prototype & Test

  5. Design

  6. Implement

Staying accountable throughout


We worked directly with community partners in weekly meetings — not just as research subjects, but as collaborators who sense-checked our direction, reviewed artifacts, and pushed back when findings didn't ring true. This kept the work accountable to lived experience rather than our own interpretations of it.


We presented our findings by situating them within the Digital Stewardship Lifecycle developed by the Sustainable Heritage Network — a framework that gave the community a shared vocabulary for thinking about long-term care, access, and responsibility for their materials, beyond just the question of which platform to pick.

  1. Discovery

  2. Define

  3. Ideate

  4. Prototype & Test

  5. Design

  6. Implement

Digital Stewardship Lifecycle by the Sustainable Heritage Network

The pivot

Interviews and survey data confirmed that a majority of community members would use a digital repository — a meaningful green light. But the research also surfaced something more important: a strong concern that a digital repository not replace or dilute the relational quality of how cultural heritage is shared and learned. Knowledge isn't just content to be stored and retrieved. It lives in relationship between elders and younger members, between stories and the people who carry them.


This reframed the design question. Instead of "What platform can hold this content?" it became: "How can a digital repository actively foster relational knowledge sharing?"


This is a meaningful departure from how most digital archives are designed — as endpoints, where the tool itself becomes the source and the relationship stops there. Our recommendations pointed toward a different model that reflected the community's worldview: one where the repository is a doorway into relationship, not a substitute for it. This shaped our thinking on governance, tiered access, and the community involvement process we recommended going forward.


Some ways this shaped our recommendations:

  • Keeping the knowledge keepers' name associated with the story or material added to the repository

  • Including a directory of knowledge keepers in the repository for members only

  • Using stories not only as a category of type of material, but as an organizing principle: on material pages, adding contextualizing stories; on story pages, weaving materials into the flow of the story

  1. Discovery

  2. Define

  3. Ideate

  4. Prototype & Test

  5. Design

  6. Implement

Outcomes

  • The team delivered a platform recommendation the partners could act on, grounded in both technical fit and community values

  • The feature comparison and sitemap gave the community concrete artifacts to react to and build from

  • Research surfaced the relational concern as a central design constraint — reorienting the project's direction in a way that a purely technical evaluation would have missed

  • Recommendations on governance and tiered access pointed toward continued, structured community involvement rather than a one-time hand-off

From 40% of benchmark tree test participants failing common navigation tasks


to

87.7% of AP and college instructors rated overall experience excellent or good


90% rated experience of moving around the site as very easy or easy


87% rated finding what they were looking for as very easy or easy


Staff have also shared feedback on the ease and intuitiveness of the admin interface now that fields and posts are consolidated and organized.

What I learned

The most important design move on this project wasn't choosing a platform or drawing a sitemap. It was staying open enough during research to hear something that complicated the original brief.


I'm also still thinking about the question the project left open. Most digital tools are designed as destinations. The idea that a repository could be designed to send people back to each other — to be generative of relationship rather than a replacement for it — has implications well beyond this project. We didn't fully solve it, but I think we asked the right question.


Next: Community Engagement >

Next >

© 2025 Kayla’s Portfolio. All Rights Reserved.

Create a free website with Framer, the website builder loved by startups, designers and agencies.