ECO is a mobile-friendly web application consisting of integrated business and project management tools built specifically for the purpose of Land Conservation. Think of it as a modular, templatized workspace and database, like combining JIRA, Mailchimp, Asana, data visualization, and specialized GIS mapping tools.
Myself and a business partner are being commissioned to build it, with the goal of creating an open-source system that any non-profit may access. We're building a co-op around the product, offering customization, data import and infrastructure maintenance and custom integrations offered in fee-based packages to any agency that needs it.
Columbia Land Trust
Our core client is a large land trust in charge of stewardship of over 29,000 acres of uninhabited land in the Columbia River Gorge and surrounding areas.
The plan is to keep the project open source so that access is cheap and easy for any sized organization. By offering robust tools to manage their complex workflows, we have the opportunity to centralize and standardize data streams from land trusts worldwide, enabling greater insights, trend mapping and custom reporting across organizations, ultimately benefiting the entire scientific community.
Kick off meetings
We kicked off the project in October 2016 with a half day exploratory workshop at CLT's headquarters in Vancouver, WA.
We organized breakout sessions by department, asking any employee in each department to join their respective sessions. From there, we led structured conversations to try to understand each job function, their objectives, and workflows, identifying pain points that a specialized software product could alleviate or solve.
Here's one of my initial sketches of a land management template page, noting the most important use cases and functions it will need to incorporate.
Our platform would use a configurable project template system to handle many of the disperate responsibilites of the staff. These include land aquisitions, stewardship plans, assigning work tasks, managing teams, contacts, volunteering efforts, mailing lists, and communications, logging property infractions, grants and budgets, inventory, and tying actions to their business strategy (GOSA - Goals, Objectives, Strategies, Actions).
By keeping it low fidelity, I was able to see the key components that all of the projects would share, informing the first stages of the Atomic Design framework which would allow us to re-use components in different contexts across the platform.
Project template layouts (lo-fi)
Another look at some of the different project templates in low fidelity.
Bird's eye view
I got to work building a low fidelity overview of the platform, describing the different core templates, deeper functionality, and the vision for how the platform would be built to integrate all of them.
This was partially for my own understanding of its inherent complexity, but mainly to show the Land Trust how extensive the undertaking would be, and get a gut check on our understanding of the scope.
This diagram proved to be a great starting point to help us all communicate about the platform, and guided our development strategy by key workflows.
Up to this point, CLT and other land trusts hand the complex process of non-profit land acquisition through excel spreadsheets!
We got to work building this into flow charts, IA schematics and logic paths to help us understand what steps a project template would need to guide a user through and allow us to think about what type of interface capabilities would be sufficient as an employee created and ultimately completed a land acquisition.
Creating an acquisition project
An early wireframe of the flow for creating a new acquisition project.
The ecosystem takes shape
With so much complexity and capabilities needed, we soon realized that we needed to create a high-level platform design system that would be able to handle everything, while maintaining flexibility, so I designed a 3-panel modular, mobile friendly "ecosystem."
The biggest wins here:
1. With development happening in parallel, we could lump functions into specific panels, saving countless hours down the road refactoring as the interface would begin to take shape.
2. Myself, my business partner and our client now had a shared vocabulary! Now we could reference vastly different levels of the hierarchical system in a few words without getting lost in endless tidal pools of "wait, what?"
UX is spreadsheets!
It would be unsustainable and time/resource draining to design interfaces at this point without a deep understanding of what needed to be present in each piece of the experience. Here's where we embraced Atomic Design.
I built out a library of every component (down to the icon, button and label level) that would be present on each screen. From this, I was able to see how the hierarchical design system would work and identify where we could eliminate redundancies and ensure consistency by reusing components across various workflows and pages.
Note: at this point, I still haven't made a single high-fidelity mock up! The time spent up front ensures a robust and cohesive system without the need to continually redesign everything as new use cases and issues popped up.
Navigation framework (lo fi)
To cut down on icon overload and disparate navigation terminals, I decided to keep all system-level navigation in the left panel. These can be accessed by unauthenticated user.
Everything user-specific would be found beneath an avatar that can have a notification badge. I'm calling this the Account Panel (right).
Referencing the component library spreadsheet as I went, I didn't miss any key functionality, and I filled in the pattern Library with the components I designed here in tandem.
Component library wires
Starting with the global navigation, I started the first entries into a component library. Here you can see the beginning organization of atoms, molecules and organisms.
Global navigation wireframes (med fidelity)
A later rendition of the global navigation. Note how the atomic system plugs into the page template.
Within the account panel, you can access notifications, a To-Do list (very handy), your bookmarks and account settings.
Note the common patterns being used across the 4 sections of the panel.
To Do List
At this point I could begin designing some workflows. As things changed in one panel, the other panels that used the same components would need to be updated as well. I was able to quickly get a sense of what the interfece would need to look like, and things started snapping into place.
Here you'll see headers, content cells, dropdowns, hover states and drag interactions. All of these systems need only be defined once and can then be used throughout the system.
Adding a task
Here's an interaction flow for adding a task to your To Do List. Similarly, the complete components being used here (like scheduling, form fields, and date pickers) can be re-used throughout the platform.
These wireframes demonstrate similar pattern and interaction models being used on the adjacent tab. The hover state, headers and general cell layout is basically the same, as is its behavior.
Account panel system
The account panel's core functions have all been fleshed out here, and a product requirements document is being crafted from these workflows.
Filtering a search by date range
Note the date picker is reused from the To Do workflow. Here, I added the ability to specify a date range to it, as well as a tool tip concept.
Homepage (med-hi fi)
Wanting to show off, obviously, and see how the platform can be "themed" according to any client's brand, I plugged Columbia Land Trust's style guide into the ecosystem.
In April 2017, we presented our platform at a Land Trust Alliance Conference. We've already been contacted by nearly 50 different land trusts interested in becoming paid clients!