Background

TactileView is a software program utilized by the Heiskell Library to assist the visually impaired view digital images by embossing paper. The goal of this three-week volunteer project was to identify strengths and weaknesses of the TactileView manual and then provide feedback on potential opportunities for improvement.

My Role

In my group of five designers, I was appointed team leader for this project given my background as a UX designer. Two of my most important responsibilities included being in constant communication with the director of the library (our client) to provide updates on the status of the project and answer any questions or concerns as well as guiding my team throughout the design process to ensure that we reverted on deliverables to the client in a timely manner.

Challenges

From the outset, there were a number of limitations that my team had to overcome:

• Lack of Experience Designing For Accessibility: Prior to this project, no one on my team had a background in designing for people with disabilities. This lack of experience resulted in a steep learning curve for us and often required that we return to our design iterations and make needed changes to account for the elements we missed the mark on.
  

• Timing: Given my team’s collective lack of experience designing for accessibility, it became abundantly clear that three weeks would not be a sufficient amount of time to identify the strengths and weaknesses of the current manual and also propose a solution to replace the current manual. Still, our team worked diligently and expeditiously over the course of those three weeks in order to provide the library with a solid foundation to improve their accessibility platforms. 
  

• Limited Access to User Testers: Another unanticipated limitation was not being allowed to interview any of the library patrons at the Heiskell Library, which made the process of identifying strengths and weaknesses of the manual that much more challenging.

Concluding Thoughts

• Prepare for the Worst: In addition to the limited time frame we were given to execute this project, our team also experienced challenges in meeting with our client. We should have planned for alternatives in the event our client would be unavailable to meet, and going forward I would set a timetable for work deliverables as well as check ins with clientele.
  

• Never Assume: Despite having limited data to back up this decision, my team created a braille booklet to teach library patrons how to use TactileView under the assumption that users could read braille. It was only after presenting the final product to the director that we realized how hasty we had been with our assumptions. We discovered that less than 10% of the visually imparied community knows how to read braille, which rendered our proposal practically useless. The experience was a lesson in just how critical user testing is and how assumptions alone should never constitute the foundation of the design process. 
  

• Don’t Overcomplicate: Our client tasked us with creating a user friendly guide for library patrons. In striving to be ambitious and impress our client, we overcomplicated an otherwise simple and straightforward project thereby inefficiently expending more time and resources than needed. More importantly, we understood that our job is to primarily listen to the client’s needs and deliver a design based on those collaborative discussions, rather than operate in a silo of our own assumptions for what the client needs.