NASA 
Brain Bank

interview project proposal

(Client)
NASA
(Timeline)
1 week (ish)
(Team)
Bill Flora (@Blink/NYT/ex-NASA)

BRAIN

Bank

Proposed knowledge management strategy for NASA's HLS initiative.

As part of the interview process, NASA asked me to outline how I would approach designing a Power App for the Human Landing System (HLS) Knowledge Management initiative—called Brain Bank. The goal was to create a system that helps engineers locate, understand, and reuse mission-critical knowledge stored across decades of documentation.

My task was to define a realistic 8–10 week design plan, showing how I would tackle an extremely complex knowledge ecosystem while delivering meaningful progress within the internship timeframe.

The problem space.

HLS knowledge exists across scattered repositories, versions, formats, and teams. Engineers often lose time searching for information, recreating work, or trying to understand the context behind previous decisions.

The challenge wasn’t simply to “build a Power App.”


The real problem was:
How do you create a trustworthy, sustainable way for HLS teams (people of vast specialties) to find and interpret critical knowledge?

My proposed approach. The first half of the
8–10 week plan.

I structured my plan around three pillars: understanding, foundation-building, and validation.

Weeks 1–2 — Understand the System

This means:

  • Map the current knowledge landscape (where documents live, who creates them, where context is lost).
  • Identify essential user groups: engineers, knowledge officers, mission leads.
  • Run rapid interviews and artifact analysis to understand pain points.
  • Define the core information types the Brain Bank must support.

Outcome: A clear picture of how knowledge currently moves, where it breaks, and what the system must prioritize.

Weeks 3–4 — Define the Knowledge Model

Which means:

  • Create an information architecture that links documents, decisions, SMEs, mission phases, risks, and dependencies.
  • Draft the metadata schema that will enable meaningful search (context, provenance, versioning, links).
  • Propose ingestion rules to ensure new information enters the system consistently.

Outcome: The backbone of the Brain Bank — a structure that future tools can build on.

The second half of the plan.

Weeks 5–6 — Power App Structure + Low-Fidelity Prototype

With a quick turnaround we move right into:

  • Outline the three-lens structure of the Power App:
    1. Input → how documentation enters the system
    2. Processing → tagging, context capture, linking
    3. Retrieval → how engineers search and interpret information
  • Build a low-fidelity, clickable Power App prototype showing search flows, document views, and knowledge relationships.

Outcome: A functional concept demonstrating how the system will actually work for real users.

Weeks 7–8 — Validate + Refine the System

This means:

  • Conduct usability walkthroughs with engineers and knowledge officers.
  • Stress-test the metadata model using real or sample documents.
  • Adjust the knowledge model based on edge cases and feedback.
  • Identify technical dependencies and constraints for long-term implementation.

Outcome: A validated design foundation plus a roadmap for engineering partners.

Weeks 9–10 — Deliver the Blueprint

Lastly:

  • Finalize the knowledge model, metadata, workflows, and IA.
  • Deliver a refined Power App prototype.
  • Package all insights into a strategic, implementation-ready plan the team can continue building after the internship.
  • Provide documentation for sustainability and long-term stewardship.

Outcome: A complete 8–10 week deliverable package that gives NASA a scalable foundation for Brain Bank.

Proposed

SOLUTION

I, in fact, could not stop thinking about this project.

Like Silo, this idea pulled me in because it wasn’t just about organizing information — it was about people, memory, and the tiny pieces of experience that never make it into official documents.

My NASA interviewer connected with that immediately. I kept imagining a space where engineers could record what they wish they’d known earlier, lessons they picked up the hard way, and the context that usually disappears when someone leaves a team. A lightweight, human-centered system for sharing lived experience — not another database, but a place to keep the knowledge that actually helps people.