Going into what I knew would be a wild year — I just didn’t know how wild — I wanted to do everything I could to stop a second Trump term from happening. Like many Americans, I wasn’t politically involved, or even all that politically literate. All I knew was, I didn’t want to repeat the devastation I felt on Election Night 2016. Working on the 2020 election was my clearest, most concrete chance to do something about this mess. I didn’t want to have any regrets.
So I ended up at Mobilize, a young but quickly-growing political tech startup, making organizing and volunteering software for Democratic campaigns and progressive organizations. When I started working with the team in 2019 (initially as a part-time freelancer), pretty much every Democratic presidential primary campaign used the product, but they didn’t have any designers despite having 7 engineers and 2 PMs. Needless to say, there was a lot to do.
This was Mobilize marketing website at the beginning of 2020.
I was given 3 weeks to:
We were optimizing for 3 things:
Here’s where we ended up:
On a deadline this tight, there’s no time for brand workshops or robust explorations of different design directions — and no need for them. Just know what broad strokes need to be applied, use your experience and intuition to make decisions quickly, and run with it. I used my instincts to figure out an appropriate aesthetic tone that resonated with the team: something bold, optimistic, human. Not just a typical tech startup. Less serious and staid than the rest of progressive politics.
As with most startups, but particularly in this extra-scrappy one, the most important design decisions here were not about creating a single well-crafted artifact, but about picking what tools to use, creating a stable foundation, and setting organic processes.
Colors: A rainbow of simple, safe, bright colors. Sometimes you need blue to represent Democrats. Sometimes you’re sick of blue and want something else. (Honestly, I’m so bad at color theory, I kept changing the exact colors. Whatever! Startups! Yay flexibility!)
Typography: I love my fonts, but this isn’t about me. I kept it simple with straightforward typography, using a robust type family (Tablet Gothic by TypeTogether) that costs no additional money to license with Adobe Fonts. No complex type systems or overly typography-driven design, which can be hard to maintain without a dedicated, skilled designer.
Assets: Use free stock/Creative Commons photos, the occasional emoji, hand-drawn elements that we can make ourselves, and a collage style that can accommodate a mishmash of different things. No custom drawn illustration, which takes time and money, and is hard to get consistent across different illustrators.
CMS: Building on Webflow (as opposed to Wordpress or something) so we don’t have to rely on additional engineers to build or maintain the site.
After setting up a flexible framework that did the job, we bit off some of the other pieces of marketing and brand-building, one at a time…
We shortened the name and cleaned up the logo to be more straightforward, human, and less explicitly related to politics, since nonprofits use the product as well...
We updated sales collateral with a clearer message, created new deck templates, and finally moved everyone from Powerpoint to Google Slides…
Sometimes I designed graphics for the new company blog and social accounts…
More often, I art-directed others to do the same, with simple rules and assets that make it easy for anyone (designer or not) to make something quickly, and a simple definition of the bar for approving an image: “If you saw this on your Instagram feed, would you get it right away?”
All this marketing work took maybe 30% of my time. In many ways, this is the easy stuff — making one-off assets in low-stakes situations. Each piece serves to help the company seem professional, credible, reliable — and hopefully help it live longer, help get more money to build the product, and ultimately lead to stronger tech infrastructure for progressives. It’s fun to make, but at the end of the day, it’s pretty far removed from the business of winning votes.
There’s still a whole product that needs designing.
At its core, Mobilize is a software tool for organizers — campaign field organizers, nonprofit professionals, or just local activists trying help their community. Organizers host events, get people to show up and do things, and then tell people what to do next — usually, attend another event. In the electoral context, this organizing is usually about contacting supporters to make sure they’ll show up and vote. It’s a critical part of campaign strategy in races at every level, and can be the deciding factor in close elections. (If you’re a left-leaning voter, you probably got dozens of texts this year from Democratic volunteers chasing your vote. Yup, that’s campaign organizing! And those people probably signed up to volunteer via a Mobilize link.)
Basically, the product is kind of like Eventbrite, but tailored for managing a volunteer program and getting volunteers more involved over time, moving them up the “ladder of engagement.”
When it comes to designing this product, it’s all pretty straightforward B2B SaaS software stuff — forms, tables, settings, etc. — but the boom-and-bust nature of electoral politics throws a curveball. Political tech is a distinctly different industry from mainstream tech. Everything is scrappy, and usability is an afterthought. Election Day is the ultimate immovable deadline, so timing and execution is everything. Every slip in timeline, or change in campaigns’ strategy, means that we need to cut scope or rearrange the roadmap in juuust the right way so users can get half-baked features just in time, without accruing too much product debt.
All this is to say, there was a lot to get done. We were simultaneously developing long-term product vision, digging out of product debt, creating new surfaces and features, running growth experiments, and ruthlessly scoping and rescoping MVPs to meet deadlines. We were flying the plane while building it… and trying to land on a moving boat…. that we were also building… just in time before the election.
On my end, I used everything in my product design toolbelt in order to:
Most of the product work requires a fair bit of context, so I won’t go into those details. Here are some of the screens that are easier to explain.
As I mentioned before, the core of the product is the events-management dashboard for organizers. It’s all about efficiency and bulk data management, so I worked on identifying and addressing low-hanging fruit like increasing information density, exposing commonly-used filters, and setting general patterns for layouts and editing behavior. (The other features you see here were done by the other designer, Matt Bambach.)
Most volunteers signed up for events on their phones, yet the event signup page hadn’t been optimized for mobile at all. We cleaned up the hierarchy so you can see the date, time, location, and “Sign up” CTA above the fold (among many other changes and experiments to improve conversion).
So much of the volunteer-facing product experience is actually comprised of the emails that volunteers get — so we made the content easier to scan, extended the surface to suggest more events to get volunteers to come back, and made a lot of parts customizable.
Sometimes, I wore my PM hat to get smaller things out the door, like getting rid of the awkward white bars that were automatically added to each event’s social preview image — which required changing the event image dimension requirements, updating documentation, and coordinating the launch.
My biggest focus was always figuring out how to make product behavior consistent and clear. Pixel perfection wasn’t something engineers could afford to spend time on, so I had to loosen up and unlearn years of design industry training. My mockups were usually just chopped-up or annotated screenshots of the existing product. Things changed too often, and mockups quickly got stale. (Components? I don’t know her.)
Sometimes, even designing in Figma was impractical; it took too long, and it was too easy to fall into the trap of designing styling that there was no time to build. For smaller changes, I often designed in the browser inspector and just took a screenshot after some fiddling. And to make things easier for emails, which are notoriously annoying to style, sometimes I just worked straight in Gmail so things would definitely be easy to build:
And for designing text message flows, I just wrote a bunch of docs:
As the election got closer, even designing before building would take too much time. Engineers would just build new features directly, then they’d send me a screenshot, and I’d do quick-turnaround rewrites (in ~20 minutes) to optimize for clarity:
In the weeks right before and after the election, I turned my attention to productizing a previously-manual process: channeling progressive volunteer energy to other organizations after the election, in order to sustain activism across electoral cycles.
Usually, when a campaign is over, staffers shut everything down and lose touch with their volunteers. All that untapped organizing potential, gone! Subsequent campaigns need to rebuild their volunteer base from scratch. The holy grail of building ongoing infrastructure like Mobilize is helping these volunteers continue their work after Election Day, so they can keep advancing progressive causes in the off-cycle too. After all, elections are just one of many different ways to make change happen. (Heh, I’ve internalized my own propaganda.)
We had big ambitions to create new product surfaces for this earlier in the year, but ultimately had to whittle things down to the essentials: sending the right emails, at the right time, to the right audiences.
It feels strange to describe all this work in such a clean and straightforward narrative, though. There was a lot of other stuff going on.