Habitat Network (formerly known as YardMap) was a grant-based Citizen Science web application run by a small team within the Cornell Lab of Ornithology. I joined the team in an effort to revamp a challenging interface to increase overall usability and the social impact it had on its user base.
The initial version of YardMap was created between 2008 and 2010, with a robust data collection workflow. The map-based application was a complex tool built to collect behavioral data around land management of individuals, at scale. Data collected included: habitat zone types, management strategies, plant data, habitat variation data, as well as non-living objects such as hibernaculums and apiaries.
Behind the data collection were two main motives. First, to understand how management is applied within suburban, rural, and urban landscapes at a level that would allow for actual scientific research. Second, to eventually have the ability to impact user behavior through education and personalization of content provided at a user level. There are many Citizen Science projects that have seen immense success, including a sister project of Habitat Network's: eBird.
Audits were conducted to ascertain how the application performed at the onset of the project. Concerns brought to me by the team early on was that the onboarding process was very confusing and that users did not know how to successfully complete a map. For that matter, what was a complete map? My findings aligned with this concern. The existing onboarding process, theoretically that of a hub & spoke concept, did not clearly define how to use the tool.
An additional issue was user falloff rates (typical to complex applications) that the platform suffered. While there was a core group of returning users who passionately loved the platform, this was naturally not enough to sustain.
Our sample of users was created by looking at habitat maps in Northern California and Ithaca regions. The maps were in various stages of completion. It was vital that stages of completeness were represented in our sample, as we were looking to receive feedback from users that both enjoyed and had few issues with the application as well as those that struggled or abandoned. This provided us with a wider range of user types and scenarios from which we were able to draw thematic ideas and see if they resonated across the different user types.
The users who created these maps were emailed and asked to participate in one-on-one interview sessions. We requested that interviews take place in user’s homes, but some (mostly non-users) were interviewed at the Cornell Lab of Ornithology by their choice. The interviews were semi-structured, with established points of reference used as touchstones to ensure the interviewer covered all relevant discussion points.
A total of nine current mappers agreed to participate in our interview process, with seven completing the interviews.
These interviews have provided us with a foundation for future avenues to improve the application – both in terms of overall application usability and with retaining the participation of Mappers by increasing the relevance of content individuals were seeing on a regular basis. By taking steps to provide new Mappers with expanded information that addresses both the project expectations and their own as they entered the process, we could begin shaping how the Mappers interacted with the content. Simplifying the mapping process and clarifying the verbiage used to define various elements had the potential to increase completion and retention. Providing a space where individualized content is introduced to Mappers without having to self-discover would give our team the avenue to increase the education potential of the application while simultaneously contextualizing efforts for the individual. The application steps into a world of very real and very strong emotions that individuals within the target audience carried – and this was evident through the interviews. Every person and a close connection to the spaces they work with and existed within and strove to create a more radiant environment for their ‘people’.
Over the course of the project, I created various user flows from a variety of perspectives and stages. Below, you can see examples of the more robust initial journey of a new user (Sally) and a more micro-flow of interactions with a single toolbar element that appears as part of the overall mapping process.
While we did follow an Agile workflow during the course of the project, I did start with a robust set of wireframes to represent the individual pieces. We began prototyping, first within UXPin and later using a lightweight Angular build, based on the original wireframes and continuous updates made over the course of the project. Our goals were: to find more natural points to capture the data that was critical to the scientific endeavor, while staying out of the way of the user; and to provide personalized, relevant information to an audience that considered the creatures that inhabited their space to be 'people' and worthy of being cared for.
In the following images, you can see an example of a selection of screens created to represent various stages of the mapping journey.
As a team we considered the different options for bringing the application to a more user-friendly status and decided that, while all the lessons learned from the original build were valuable, we could not continue scaffolding off the old technology and decided to migrate to Angular as the foundation of the updates.
Below, you can view an example of an early run through of the Angular-based application. This was before all data was connected, and the remaining copy was integrated.
Throughout development, we released staged versions for testing to a beta group who opted into our process. We captured feedback using AirTable to gauge the overall reaction to any changes made and categorized them into topic groups and on a positive-negative scale. We brought the feedback from this testing group back into the updates we were making, as well as planned for future additions to the platform.
The overall reactions were extremely positive, and we were thrilled to be making rapid progress to our eventual full release. One challenge we faced during this process was the scale of the data in relation to the size of our development team. We were working with a very rigid database structure, and we realized at this time we would ultimately aim to move the entirety of that database to allow for future enhancements, more regularly. The rigidity of the database ultimately slowed our overall release as we ran into significant bugs while connecting various elements to their data pair.
Below are selected quotes from the beta testing:
It was easy to follow, and if every level has the new level of complexity, this will truly become an essential resource for many branches of science as well as the property owners participating. Good work!
WOW! WOW! WOW! I am So impressed, I love it! I like the animated demo before the outline mapping especially since using the current version, I kept messing up in the beginning and not knowing how to undo my mistakes. For new users, I'm sure it will help if each step was animated like that. I know I initially was confused in the beginning and I am NOT a 'computer-person.' Never was and don't plan to be. No offense. I'm just glad that there are folks like you who do understand and hopefully enjoy it!
Unfortunately, as often happens in academia, the project itself ran out of funding about two months before we could launch the new version of the application. We could, however, say that there was an extremely positive reaction during the testing period of the beta releases and a positive trend on completion rates and understanding of what the full process was. This project has been, to this point in my career, a highlight and I hope to one day find a project that pushes for the empowerment of individuals and the betterment of society similarly.