Project: Tool Librarian

Role: UX & UI Designer 

URL: toollibrarian.com



Context

In 2008, I was living in in NE Portland and a few neighbors and I wanted to create a resource for the diverse community we called home, so we decided to start our own tool lending library. We opened the library with little more than a handful of tools and a ledger we used to track members and the tools they borrowed. 

We eventually upgraded to a Microsoft Access database we had copied from the North Portland tool library. That software was rudimentary and not much effort had been put into the UX. It became clear after the first year that we needed a more sophisticated software program that would allow us to improve our process and workflow. I collaborated with another volunteer Michael Brandt, a software developer with a background in databases and mySQL, and we began to discuss the project.

Observation and problem definition

Over that first year in operation, I started to collect feedback from our volunteers and see opportunities to create a new software application that would improve process and work better for our needs. Building the new software on a server that could be accessed from any computer was essential as was migrating the existing database online so our members could search for a tool before coming into the library.  

I led a few sessions with the board that produced plenty of great ideas ranging from better ways to register new users to enabling us to track late tools - late fees were a major source of our non-profit’s revenue.

From these work sessions, I created a list of objectives that could be used to begin building out use cases and wireframes to share with the developer.

• Simplify and improve the UI to reflect real use cases
• Streamline tasks like adding a new member and tool check-in/check-out management
• Use web technologies that enabled access to the application from any browser
• Integrate tool search capabilities from our website
• Create accurate reports that mattered to our weekly operations

Solving all the things

Cleaning up the data was one of the first things we had to tackle. Data entry had been done by dozens of volunteers and there were inconsistencies in tool names, categories, neighborhoods, phone# formats etc. We had to agree on what form fields we wanted to lock down to create drop down lists. This cleanup was going to greatly improve user input, search capability, and accurate data reports.  

There were several opportunities I saw to simplify the UI and create a more intuitive interface for new volunteers using the software. The original software had separate pages for tool check-in and check-out. In reality, members were often doing both and the software required the user to return to the main screen to initiate the secondary action. 

There were also two ways to initiate a tool return (by memberID or toolID). The old interface treated these as separate actions and check-in by toolID didn’t bring up the member's record to see if they had other tools checked out. Members often forgot how many tools they checked out the previous week. Searching by last name was also cumbersome, so we added that to the search field.

By creating a single smart input field, we could query the database using either a toolID, memberID or lastName. All inputs opened the member’s page complete with their contact information, tool check-out history, any late fines due and the ability to checkout a new tool without leaving the screen.

New member registration was another area we saw an opportunity to streamline the process. This task of manual data entry not only held up the line for existing members that just wanted to return or check out a tool, but it was also an area where data integrity was often compromised. Whenever a volunteer had to read and interpret a hand written member application there was an opportunity for mistakes, creating potential issues in the future. 

We solved the issue by setting up an online form and a public computer in the tool library where new members could sign up online.

There were also tasks we didn’t want volunteers doing, like adding tools.  So we created different tiers; volunteer, tool guru and admin accounts to limit access to tasks that would affect the underlying database. This helped simplify the interface the volunteers used. 

Real world feedback

The success of the project was our ability to iteratively address the issues and concerns of our volunteers. Because we involved our volunteers by soliciting input and feedback, they welcomed new software updates and kept the developer and me engaged in ongoing software updates.

Also using the product over time was essential to the success. Many issues arise infrequently and occur over a longer use cycle, like tools breaking or needing repair.  It was helpful to be able to volunteer and wonder what to do when a member returned a broken tool or feel the pressure of holding up a long checkout line because of the time it took to register a new member or having no way to call members who had not returned tools when they were due.  

Key Takeaways

Data integrity was an important factor to creating and maintaining the software. Limiting the data entry opportunities to select people and allowing for consistent data entry by implementing drop down menus really helped clear up inconsistent reporting queries and helped our members search our growing inventory of tools more easily.