2016-2017
The Groundwork
responsive web app & marketing site
The Groundwork is a technology platform built to help nonprofits collect supporter data, raise funds, host events, measure progress, and more. Besides being a powerful API, The Groundwork is also a suite of tools that make interacting with the API as seamless as possible.
One such tool is Admin, a frontend application Groundwork users can utilize to view and manage their data. I got to contribute a lot to Admin, working on features such as an activity stream, onboarding flows, report views, a data collection UI, and more.
In addition to working on Admin, I also got to design and build the primary marketing site for The Groundwork. This site included feature descriptions, a pricing page, and a blog. It was also the jumping off point for our signup flow.
gathering thoughts for thegroundwork.com
some imagery sketches
I usually start my design process by writing down my thoughts. I like to wrap by head around a project my asking myself questions and trying to answer them. Here, I was thinking about the goals of the marketing site, what The Groundwork is, and why it's appealing to potential customers.
Also pictured are some imagery brainstorm sketches. Coming up with imagery to advertise tech software is always a challenge, so I just threw a bunch of ideas (good and bad) on paper to get started.
thegroundwork.com homepage
Though I was the primary designer and developer for this project, it was still a hugely collaborative effort. I worked with the marketing team to finalize content and copy. My fellow designers provided priceless feedback. And my fellow developers set up the build and deploy process and lended a hand with the JS. Yay team!
mobile screenshot on a mobile device
tablet screenshot on a tablet device
The screenshots on the page are responsive, corresponding to the device the site is being viewed on.
interactive imagery on thegroundwork.com
Static images weren't enough to do The Groundwork justice, so I decided to bring some interactivity into the mix. I solicited the help of another JS developer on the team, and together we created some interactive graphics to better illustrate the platform's features.
collections feature marketing page snippet
donations feature marketing page snippet
To show off specific features of The Groundwork, we created individual feature pages to highlight each one. I drew custom illustrations for each of these pages.
pricing page snippet
Our pricing model could be a little confusing to grasp at first, so I spent a good deal of time on the pricing page trying to make it as clear as possible. I included graphic breakdowns of the various costs as well as a monthly cost estimator.
Underground: a blog by The Groundwork
We also included a blog on the site to show off new features and talk about our tech. Another developer helped me set up the blog templates, then I added the styles.
the start of the sign up flow
I started the signup flow with an email input instead of just a "sign up" button because it makes our sign up process seem super approachable. Can I really get started for free with just an email?!? And if the user drops off at anytime during signup, an email would have already been captured, so we can reach out to them in the future!
account creation
A little more info is needed to create the new user's account. But since we already collected their email, this form only needs 3 fields instead of 4.
organization creation
In addition to a user account, a user also needs to create an organization (which they can invite other users to later). I broke organization creation out into its own step, again, to avoid having one long signup form. At this point, the user's account has already been created and they can focus on creating their organization.
admin welcome screen
Once the user has created their account and organization, they are welcomed to The Groundwork. I used this opportunity to explain the live and test modes in Admin, ensuring the user that they could explore safely in "Test Mode."
admin zero state
A brand new user's home screen will show an actionable zero state. We ask the user what they'd like to accomplish first, and let them know how much technical experience each task will require to complete.
onboarding payment tutorial: step 1
The user can select what they'd like to accomplish to open the corresponding tutorial.
onboarding payment tutorial: step 2
The tutorials are smart and guide the user through multiple steps required to complete selected task.
For example, in order to start collecting Payments, a user must first integrate with Stripe. You can see here that the user has already integrated with Stripe, and so is ready to move onto creating a Payment Page.
activity stream
Once the user has started collecting data, the initial zero state is replaced by an activity stream. In the right-hand column, all-time metrics are available, and uncompleted tutorials are still accessible.
supporter tutorial
For example, this user hasn't had any supporter signups yet, so they can still find out how to start collecting supporters.
onboarding sketches
Pictured are some sketches from the onboarding design process. I started out by writing down what I thought was wrong with the current onboarding process, then thinking of some solutions. Then, I turned those ideas into sketches.
activity report
I got to do a ton of work with report dashboards in Admin. I worked closeley with a product manager, another JS developer, and the backend developer who built the analytics APIs to bring these dashboards to life. This collaboration was a ton of fun. We utilized the charting library Victory for these charts.
The process went something like this: The PM would create wireframes which I then translated into designs. I'd check with the backend developer while designing to make sure the API provided the information we needed. The PM, the JS developer, and myself would then go over designs together to make sure we were providing the most informative data, that everything was buildable, etc. Then I would start building. I'd create new React components, write markup, style the Victory charts, etc. The other JS developer would then come in and wire everything up to the API Finally, the three of us would test, find problems, fix bugs, and ship! In the end, we were able to produce multiple informative and beautiful (and responsive) report dashboards.
The screenshot above is the activity dashboard. It shows a breakdown of all the different types of data flowing through an organization.
line chart tooltip
key tooltip
Here's a couple details from the chart. Users can hover/click over a point on the line char to see its exact value. We also provided information on what type of data specifically was being counted in each line.
tablet activity report
mobile activity report
Did I mention that all the reports are responsive? Because they totally are!
payment report
We built an in-depth payment report so organizations can get a closer look into the funds they're collecting. The line chart and pie chart compare one-time donations to subscriptions, and the pie chart even shows you a comparison to last period. There's also a payment size histogram, showing the frequency of various payment sizes.
create a collection
I also got to work on the Collection management UI within Admin. The Collections API allows Groundwork users to collect any type of data and validate it against custom schemas. Collections can be used to power things like forms, petitions, quizzes, surveys, directories, and more.
Before users can start collecting data, they need to be able to create custom Collections and schemas. I familiarized myself with our Collections API by reading the docs and sending requests to it via Postman before designing its UI. I designed a schema builder, which allows users to create multiple field types, specify required fields, and more. The Collections themselves also have multiple options. For example, if you set a Collection to "public", you could display its data on a public-facing website—great for a directory!
collection records
Once a Collection has been created, its records are viewable within Admin. We also added approval UI to this view, which is useful for public Collections. For example, if you're allowing the general public to submit a form to a public Collection that powers a public directory, you're going to want to approve those submissions before allowing them to be displayed.
filtering
advanced filtering
We also included UI that enabled users to filter through their records by field. The basic filtering allowed users to select a field, input a search term, and choose whether the field must simply contain or exactly match the search term. This basic UI was perfect for most users' needs.
But because Collection schemas allow field nesting, we wanted our users to be able to search specifically within those nested fields. We created an advanced filtering UI, that allowed more technical users to follow a specified syntax to dig deeper into their records.
collection schemas
A Collection's schemas can not be deleted, because data may already exist for that schema. Instead, if users needed to edit a Collection's schema, they can create a new schema version. All schema versions are viewable in the "Schemas" tab of a Collection.
new schema version
When creating a new schema version, the schema builder automatically loads the fields from the latest schema in, ready to be edited. That way, a user never has to start from scratch.
