Designing an electromechanical device with blind and low-vision users
A user-led electromechanical design project translating interviews with blind and low-vision participants into requirements and prototype tests.
To design around the real routines and priorities of blind and low-vision users, then test whether the device supports the task they identified.
From the initial question to a tested result
The timeline traces how the project moved through problem definition, design, prototyping, integration, and validation.
Start with the person, task, and environment - not a predetermined device.
The project begins with interviews and observation to understand current strategies, frustrations, workarounds, and priorities. The goal is to identify the underlying need before choosing a mechanism or interface.
Translate qualitative insight into something the team can design and test.
Interview findings become prioritized user needs, then measurable engineering requirements and constraints. This creates a traceable line from what matters to the participant to the specifications used during concept selection.
Mechanical, electronic, and interaction decisions have to work together.
The team will develop an integrated electromechanical device, prototype the highest-risk interactions early, and refine the system through fabrication, bench testing, and feedback with the project partner.
Three decisions that shaped the project
Each decision connects a technical constraint to the choice I made, the analysis behind it, and the tradeoff that followed.
Problem definition
User-led requirements
The partner's lived workflow defines whether a device is useful. Translating interviews into requirements prevents the team from optimizing an elegant solution to the wrong problem.
Kept the solution grounded in the partner's routines rather than committing early to a preferred technology.
Start with the person, task, and environment - not a predetermined device.
The project begins with interviews and observation to understand current strategies, frustrations, workarounds, and priorities. The goal is to identify the underlying need before choosing a mechanism or interface.
- Use open-ended questions before proposing solutions.
- Document context, actions, breakdowns, and existing adaptations.
- Separate what a participant says, what the team observes, and what the team infers.
Validation
Task-based testing
Accessibility is demonstrated through successful real tasks, not through the presence of features. Task-based criteria connect testing to the original user need.
Requires repeated access and consent, but produces stronger evidence than feature checklists.
Translate qualitative insight into something the team can design and test.
Interview findings become prioritized user needs, then measurable engineering requirements and constraints. This creates a traceable line from what matters to the participant to the specifications used during concept selection.
Prototype scope
Highest-risk interactions first
Interaction and mechanical feasibility can invalidate a concept early. Testing those risks first protects time that would otherwise be spent refining an unusable enclosure.
Leaves cosmetic refinement later so feasibility and accessibility failures surface early.
Mechanical, electronic, and interaction decisions have to work together.
The team will develop an integrated electromechanical device, prototype the highest-risk interactions early, and refine the system through fabrication, bench testing, and feedback with the project partner.