Making Assistive Technology Search Actionable through a Multi-Source Retrieval Tool for TOM
Written by Shuo Feng
How can assistive technology organizations, like Tikkun Olam Makers, help people find, adapt, or build solutions to the physical challenges they face every day?
Tikkun Olam Makers (TOM) is a nonprofit organization that connects people with disabilities, known as Need-Knowers, with a community of volunteer makers to develop affordable, accessible assistive solutions tailored to their specific needs . The process begins with an intake form, in which Need Knowers describe the challenges they face, followed by a collaborative process that pairs them with Makers who work alongside them to understand the problem, develop ideas, and design, build, and test a solution.
While Need-Knowers are intimately familiar with the challenges they encounter in their daily lives, they aren’t necessarily experts in assistive technology, and they may not know the terminology for the products or devices that could help them. Someone might say “I cannot walk,” and describe difficulty moving safely around their home without knowing what type of mobility device or assistive solution to search for.
Potential solutions, meanwhile, are scattered across disconnected sources: TOM’s own project catalog, open-source platforms such as Thingiverse, Printables, Instructables, and GitHub, and commercial retailers like Amazon, Walmart, and Etsy. Searching across all these is time-consuming, and even when a relevant project exists, it is typically described in product names and technical terminology, as opposed to the everyday language Need-Knowers use.
Finding a relevant project is also part of the challenge. Once a possible solution is identified, TOM staff and makers still need to determine what to do with it: use it as-is, modify it to fit the Need-Knower, or treat the unmet need as a new design challenge.
This summer, as a Siegel PiTech PhD Impact Fellow, I worked with TOM to improve three aspects of their process:
Improving how needs are understood through a conversational intake process that translates everyday descriptions into functional requirements.
Improving how solutions are found by searching across fragmented sources for relevant TOM projects, open-source designs, and commercial products.
Improving how solutions are evaluated and acted upon 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 meaningfully influence the solutions they recommend. This analysis helped shape the tool’s conversational intake. Instead of presenting users with a long static form, the tool builds on information they have already shared and asks targeted follow-up questions to clarify the activity they are trying to perform, their desired outcome, and constraints that may affect a potential solution.
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. Through this exchange, the tool turns a broad description of a physical limitation into a more specific functional need that can guide the search for an appropriate solution. This distinction matters because the same physical limitation can lead to very different assistive solutions depending on the activity and desired outcome. “Cannot walk” alone provides little information about whether someone needs support with transferring, moving between rooms, standing, navigating stairs, or performing another activity.
Working with TOM staff also helped us identify additional details that can influence solution retrieval and evaluation, such as physical constraints, age, geographic location, and whether the requester is the Need-Knower, a caregiver, or a clinician. The goal is to gather the information that can meaningfully change the solutions considered, while avoiding the burden of requiring the user to complete a lengthy intake form before they can begin exploring possible solutions.
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 a single 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 assess 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 illustrates 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 is designed for 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 rather than presenting the walker simply as a successful match.
Figure 1: The assistive technology search tool, showing (left) conversational intake that clarifies a mobility need, (middle) related projects retrieved across sources, and (right) evaluation of a selected project that reveals where the candidate does and does not fit the Need-Knower’s requirements.
The evaluation also considers whether an imperfect match could realistically 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.
Shuo Feng
Ph.D. Student, Information Science, Cornell University
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.