Research project · Siegel PiTech PhD Impact Fellowship · TOM Global · Summer 2026

Making Assistive Technology Search Actionable through a Multi-Source Retrieval Tool for TOM

How can assistive technology organizations help people connect their daily physical challenges to existing solutions, modifiable designs, or new build challenges?

Organizations like TOM (Tikkun Olam Makers) connect people with disabilities, referred to as Need-Knowers, with assistive solutions and volunteer makers. Today, this process often begins with intake forms that ask requesters to describe their needs in detail. But Need-Knowers usually know the challenges they experience in everyday life, not the technical names of products or assistive devices that might address them. A person might say, for example, “I cannot walk” and describe difficulty moving safely around their home, without knowing what type of mobility device or assistive solution to search for.

At the same time, potential solutions are scattered across many disconnected sources. TOM maintains its own catalog of assistive technology projects, while platforms such as Thingiverse, Printables, Instructables, and GitHub host open-source designs, and commercial products are distributed across stores such as Amazon, Walmart, and Etsy. Projects on these platforms are typically described through product names, categories, and technical terminology, while Need-Knowers describe challenges from everyday life.

Finding a relevant project is also only part of the challenge. Once a possible solution is identified, TOM staff and makers still need to determine what to do with it: use an existing solution as-is, modify an existing design to fit the Need-Knower, or identify the unmet need as a new design challenge.

This summer, as a Siegel PiTech PhD Impact Fellow working with TOM, my project focused on three parts of this process:

1. Understanding the need through a conversational intake process that translates everyday descriptions into functional requirements.
2. Searching across fragmented sources to retrieve relevant TOM projects, open-source designs, and commercial products.
3. Making search results actionable by showing why each solution may help, what can be modified, what still needs to be checked, and when a new design challenge may be needed.

Building from Expert Knowledge

First, we worked with TOM staff to understand how experienced assistive technology practitioners conduct intake conversations with Need-Knowers. We examined transcripts from real intake sessions to understand what practitioners ask, when they ask it, and which details actually affect the solutions they recommend.

These conversations shaped the tool’s conversational intake. Instead of presenting a long static form, the interface keeps track of what the user has already shared and asks follow-up questions to clarify the activity, desired outcome, and relevant constraints.

For example, Figure 1A begins with the statement “I cannot walk.” Rather than immediately searching for a wheelchair or walker, the tool first asks which daily activities this limitation affects. The user explains that they have difficulty moving around their home and that their goal is to move more safely. The conversation therefore turns a broad physical limitation into a more specific functional need that can guide the search.

This distinction matters because the same physical limitation may correspond to very different assistive solutions depending on the activity and desired outcome. “Cannot walk” alone provides little information about whether someone needs support for transferring, moving between rooms, standing, navigating stairs, or another activity.

Working with TOM staff also helped us identify which additional details are useful during search, such as the person’s physical constraints, age, geographic location, and whether the requester is the Need-Knower, a caregiver, or a clinician. The goal is to gather information that can change which solutions are retrieved or how they should be evaluated, without requiring the user to complete a long intake form before receiving any help.

A Method for Multi-Source Search and Evaluation

The core technical challenge was connecting a Need-Knower’s everyday description to projects described differently across multiple platforms. I developed a web-based tool that connects conversational intake, multi-source retrieval, and candidate evaluation in one workflow.

The tool searches TOM Global projects alongside open maker repositories such as Thingiverse, Printables, Instructables, and GitHub, as well as commercial sources including Amazon, Walmart, and Etsy. Instead of searching only for the wording of the initial request, the system uses the activity, desired outcome, physical challenge, and relevant constraints gathered during the conversation.

Once related projects are retrieved, the interface helps users understand whether each candidate actually fits the Need-Knower’s situation. Selecting a project opens an inspection panel that explains how well it fits the need, whether it can be adapted, what still needs to be checked, and which user requirements it addresses.

Figure 1 shows this workflow. The user initially reports that they cannot walk, then clarifies that the relevant activity is moving around their home and that their goal is to move more safely (Figure 1, left). The system retrieves several mobility-related TOM projects (Figure 1, middle), including a PVC Pipe Walker for Children with Balance Difficulties.

Importantly, retrieving this project does not mean that the system recommends it. When the user selects the walker, the detailed evaluation identifies a mismatch between the candidate and the Need-Knower’s situation (Figure 1, right). The project supports children with balance difficulties or relatively mild physical limitations, while the current request describes a person who cannot walk. The interface therefore surfaces this limitation instead of presenting the walker simply as a successful match.

The same evaluation also considers whether an imperfect match could be adapted. In this example, the PVC structure may technically be modifiable, but adapting a walker designed for children with balance difficulties to support someone who cannot walk would require substantial changes to its structural integrity, stability, and level of physical support. The interface therefore distinguishes between a project that is merely editable and one that can realistically be adapted to the current need.

This distinction helps users and TOM staff move beyond a list of superficially related search results. A candidate can be (1) appropriate as-is, (2) promising but in need of modification, or (3) unsuitable for the current Need-Knower.

Users can save promising candidates and compare possible solutions. They can also reject candidates that fail important requirements, allowing those constraints to inform subsequent searches.

If no retrieved solution adequately addresses the need, the search is not treated as a dead end. The tool records why the closest candidates do not fit and organizes those unmet requirements into a project brief. TOM can then use this information as the starting point for a new maker project or hackathon challenge.

Impact and Path Forward

By the end of the summer, I had developed a working browser-based tool that connects TOM’s intake process with search across existing assistive technology solutions.

Instead of treating intake, online search, evaluation, and new project creation as separate activities, the tool connects them into one workflow: understand the need, find related solutions, determine what can be used or adapted, and carry unmet requirements forward into a new design challenge.

This connection is particularly important for assistive technology. A project appearing in search results does not necessarily mean that it is appropriate for the person who needs help. As the walker example demonstrates, two projects may address the same broad activity while requiring very different levels of physical ability or support. Making these differences visible helps Need-Knowers and makers understand not only what exists, but also whether and how it can actually help.

The working tool has been delivered to the TOM Global team for continued use and testing. It runs in the browser and stores session information locally, allowing staff to review searches, save candidate projects, and export summaries without requiring additional user accounts or backend infrastructure.

The next step is to test the tool with active TOM maker teams during real intake and hackathon workflows. We are particularly interested in understanding whether it can make it easier to move from an initial Need-Knower request to one of three actionable outcomes: an existing solution, a clearly scoped modification, or a well-defined new project.

We also plan to connect the tool more directly with TOM’s challenge pipeline so that unmet needs identified during search can become structured starting points for future maker projects.

Shuo Feng
Ph.D. Student, Information Science
Cornell Tech