At NewFounders, I lead design, development, and product management efforts. I also oversee internal office functions (payroll, legal, etc).

Pictured: NewFounders logo

As the director of product and design at NewFounders, I have merged my knowledge of product, design, development, and law to lead the charge in the world of political technology. At NewFounders, we work with partners around the country to build tools that have the opportunity to revolutionize civic data and community projects in the US. More than anywhere else, NewFounders taught me the indispensability of collaboration, patience and diplomacy. was a custom website built on top of a Nationbuilder template. Although the design is custom, we took advantage of Nationbuilder’s robust liquid template technology, which allowed us to integrate with their CMS. 

Designing around Nationbuilder’s CMS provided a unique challenge. Certain user experience components that we wanted to implement (and even certain design aesthetics) were impossible or impractical. Most of the challenges, however, were offset by the strength of Nationbuilder’s administrative components (which included lead management, e-mail management, and community management).

Design of the website (previously named RISE)Early

Pictured: screenshot of websitecurrent


The EveryElection app was born out of the realization that American elections––the bedrock of our republic––are being hindered by misinformation, disinformation, and general ignorance. It's common knowledge that a voter cannot wisely select a representative without being well informed, but the information needed by the voter is simply too difficult to find. When voters cannot find clearly reliable sources of information, they turn to what they have around them. This opens the door to nefarious sources who seek to manipulate the ballot in favor of self-serving interests.

EveryElection seeks to change this. By partnering with various data suppliers (with our primary partner being BallotReady), we were able to compile a database of information on 300,000 of the 519,000 rolling elections in the United States). That equates approximately 60% of all elections. While that number may sound small, it's important to remember that U.S. elections are managed locally. This means that there is no central source of election information. To collect information on each local election, our suppliers need to manually call the city that manages the election. If the city doesn't have the information (this happens more often than it should), we can (in some circumstances) call the county and get the data from them. And if the county doesn't have it, we may be able to call the state. For particularly small or poorly managed cities, however, the data simply isn't available. Either nobody answers the phone, responds to emails, or simply knows where to find the information. To say the least, it's pretty clear why voters often don't even know when a local election is upcoming.

My role in this process was threefold: (1) to design mobile and web applications that would be appealing to voters; (2) product and project manage the implementation of my designs; and (3) to build the front-end frameworks for the web application.

Design Phase

I think best when I work at my computer, so my first step is always to roughly sketch out a user flow in Balsamiq, Illustrator, or Sketch.

‍First version of user flow

Throughout the ideation/design phase, this user flow is simplified and streamlined until it is as intuitive as possible without sacrificing necessary functionality.

After finalizing the user flow, I move on to the user interface. I begin roughly wireframing the layout of each element, paying minimal attention to aesthetic.

‍Early wireframes of iOS appEveryElection

In the user flow above, you can see that I mapped out various paths (including basic error handling) that asked each user to register through Facebook, Gmail, or email, import their contacts from various sources, and provide their personal address before gaining access to the app's services. We wanted access to each user's contacts so that we could map elections around them, allowing the tool to be used for GOTV (get out the vote) efforts. We also wanted access to each user's residential address so that we could map elections that they were personally eligible to vote in (which was the core functionality of the app).

Although not yet featured in the above user flow, and although critical to the app's core features, every step after registration was optional. This approach was taken to increase early user trial and conversion rates.

While we didn't have the resources to conduct extensive user research, we were able to interview dozens of people within our target demographic. In talking with various activists looking for a tool to help them get out the vote, and with various voters who just wanted a way to enhance their own political participation, we found the number one concern was security. Most people did not want to share any information with us if it was stored remotely (which is one reason we, at first, stored all personal information locally). People were concerned with Russian and Republican hackers, corporate advertisers, and any ulterior motives we may secretly possess.

We considered making registration entirely optional, but that would have severely limited lead gen options. Instead, we provided limited access primary features before suggesting that users register in order to unlock additional functionality. This approach, combined with storing data locally on a user's phone or computer (instead of on our servers), seemed to adequately address our user's concerns.

Once features, flow, and layout were prepared, I moved onto designing high fidelity mockups. This step is occasionally unnecessary, as hi-fi mockups can be as time-consuming as actual development. If possible, I prefer to have an actual framework built in place of hi-fi mockups. These frameworks are often just as easy to iterate on, draw attention to design limitations, allow stakeholders to preview the final product, and build towards the end product (killing several birds with one stone).

‍A couple more mockups depicting how the app would acquire a user's location (we intentionally avoided using geolocation services)

On the topic of design limitations, notice also that my designs do not completely adhere to either Apple's Human Interface Guidelines nor Android's Material Design guidelines. Though I'm sure this is a controversial decision, my intention was to preserve our resources by designing once and implementing twice (on both Android and iOS). This approach also lowers maintenance costs going forward.

Additionally, the modular design, which separates each election into self-contained "cards", also caters to a mobile-first, responsive web design strategy. I was able to easily apply the core of the mobile styles to the web application.

Product and Project Management

My philosophy on practical execution lends itself well to my product management style. Rapid, agile, and decisive action is crticial to an early stage startup. Sometimes that means making a mistake–but if done right, an agile team should be able to quickly remedy the error and correct course.

Another key element of my product management philosophy is direct communication. As the product manager, I am responsible for ensuring that all parties (1) know what they are supposed to do; (2) have the resources to do it; and (3) have all roadblocks cleared. I have seen several product managers interpret this role as a sort of interpreter: they would meet with a coworker, discuss any roadblocks or other issues, and then communicate on their behalf to other relevant parties. This is like a game of telephone, and it can cause severe inefficiencies. Instead of speaking on behalf of each party, I prefer to connect them directly when possible. I see myself as responsible for keeping track of all moving parts and ensuring that each part is in regular communication. If I know that a developer and designer disagree on the implementation of a feature, I connect the two to discuss rather than discussing on their behalf. If necessary, I step in as a thought-translator when necessary. This approach allows my team to work rapidly through complex issues.

This ability to rapidly develop made it a little easier when dealing with several different data vendors and third-party partners. Development occurred on top of a constantly changing landscape, so it was not uncommon for critical requirements to come to light on a moments notice. Since we could work quickly, we were able to keep sprints as small as one week, limiting the risk of mid-sprint disruption.

As we approached the final release deadline, we needed to ensure that we could deliver on what we promised to stakeholders and to the public. To do this, we kept a releasable iteration ready at all times. If we had to, we could release a stripped down version of the application reminiscent of an MVP.

Finally, for those interested, my go-to product management tool for this project, though slightly controversial, was Trello. While Trello doesn't scale well, it mimics a scrum board very well for small teams. Our development team consisted of two senior iOS developers who worked on contract, plus a senior backend developer who was doubling as our CTO. I used Trello to set up a standard scrum board that consisted of eight lanes: backlog, current sprint, in development, dev complete, in test, bugged, ready for release, and released. I also created a board that stored all released cards from previous sprints (each sprint had its own lane).

Framework Development

I built all the HTML/CSS frameworks for NewFounders, including our marketing websiteconference website, and unreleased EveryElection web application. For the EveryElection application, I used the Jekyll static site generator and the flexboxgrid grid framework.

I definitely stretched the usefulness of Jekyll in this context, but it's basic use of partials and liquid templating made it extremely simple for me to implement my web design framework (seen above). The flexboxgrid was perfect for implementing a grid without all of the bloated design and extra functionality that goes with larger, more common frameworks like Foundation (my usual go-to) and Bootstrap. I also appreciated its use of flexbox's in place of inline-block elements.


ChangeMaker was the start of an ambitious project dedicated to making community projects more affordable, effective, and easy to execute. 

As we announced in an e-mail blast just before it’s launch: 

“Think about Kickstarter. What’s great about the concept is that users can back projects they care about in the early stages by crowdsourcing the capital necessary to execute it. At NewFounders, we were inspired by Kickstarter to create a tool focused on building communities, rather than just funds, around projects that matter…With Changemaker, organizations can specify which skillsets they need, and individuals can specify which skill they can provide. Then, individuals can join the projects they care about as volunteers specifically focused on work that utilizes their skills. Prospective volunteers can even find projects that suit them best by filtering out projects that don’t require their skillsets.”

I played a substantial role in every element of Changemaker’s product lifecycle. We began with basic surveys that we provided to prospective organizers to understand how we can both fit into and improve on their current routines. We then moved onto rough mockups and graduated to pixel perfect high-fidelity designs. We hired 20Spokes, a local development shop, to create the final mockups and develop the front-end and back-end components of the product.

Very early mockups of Changemaker

20Spokes polished design

I also went on to design and produce a promotional video for the product. The video never ended up being released publicly, but I am happy to share it upon request.


Latets Works