Brad Frost

Launching a Campaign Website...Quickly

I had the opportunity to make a website for Brian Forde, who is running for Congress in Orange County, California. Brian got in touch after reading my Designing an Effective Donation Form blog post, and wanted to bring that thinking to his campaign website. So on July 7th we hopped on a call, where I learned that Brian worked as a Senior Tech Advisor in the Obama White House and is running for office so he can improve peoples’ lives, use technology to make government more capable & efficient, and combat the toxic, xenophobic views & policies coming from the other side. All this very much aligned with my own values, so while I typically shy away from political stuff, I decided to take on the project. Then came the big question: when does the site need to be live? “July 17th,” he said. Of course, that meant the site would need done in a little more than a week.

I signed on to build a website in a week the way that some people drunk-buy stuff off of QVC. — Brad Frost ? (@brad_frost) July 7, 2017

Normally building a site in such a short window of time isn’t a great idea, but I took it on for a few reasons:

So challenge accepted. This post will talk about how we built Brian’s campaign website in a little over a week. The Process Step 1: Gathering and Setting Up Once the contract was signed on July 8th, we dove right in. Unlike an established brand or company, the campaign was in the early stages of putting their identity and operation together. I asked them to pass along any materials they had, and they sent through a work-in-progress logo, a link to a logo design they ended up not using, some copy for campaign principles, some inspiration sites, and some wireframes and a comp a friend had done: Initial comp for Brian Forde website Brian explained which aspects of the inspiration sites he gravitated towards, and talked about what he liked and disliked about the comp and wireframes. This was enough fodder to get to work. Getting Pattern Lab up and running Knowing this would be a tight turnaround, we knew we’d be designing this project entirely in the browser, reducing the amount of wasted energy going towards artifacts that weren’t an actual website. Using Pattern Lab Node, we were able to spin up an empty project and we quickly imported our vanilla CSS architecture, common Gulp tasks from other projects, and default starter patterns. (I’m hoping to share this whole setup soon, as it’s basically how I start almost every new project). With Pattern Lab set up, we were ready to get to work. Step 2: Establishing design direction Decoupling design conversations It’s amazing how certain design artifacts muddy the waters and inhibit good conversation from happening. When static comps are presented, conversations about look and feel get distracted by content, information architecture, and layout. I felt that Brian and the team were already having a hard time reacting to everything locked up in the initial comp and wireframes. One thing I’ve learned (and written about in my book) is to decouple conversations about IA and visual design early in a project so as to have productive conversations about each topic without getting tripped up or distracted. Isolated IA For conversations around IA, we’ve found a simple spreadsheet cuts through a lot of the noise that formal wireframes tend to create. From chapter 4 of Atomic Design:

With a few simple spreadsheet columns, we can articulate which display patterns should be included in a given template, and what content patterns they’ll contain. More importantly, we’re able to articulate each pattern’s relative hierarchy and the role it plays on the screen. If you read the leftmost column vertically, you’re effectively looking at the mobile-first view of what the UI could be.

So we created a spreadsheet that stubbed out the IA for each page, defining components, the jobs they need to do, and their order on the page. This allowed the campaign to work through what they wanted the site to accomplish without worrying about layout, color, functionality, etc. Parallel to this process, Ian was working in Pattern Lab to stub out all the pages and linking them together. And just like that, in a few minutes we had a basic bones of a website that would evolve into the final product. Quick & dirty visual direction For visual design direction, I was initially toying with the idea of putting together some style tiles (or rather, their in-browser style prototypes) to talk about color, typography, and texture. But even that felt wasteful. So instead I opted to conduct a 20-second gut test exercise. I rounded up a handful of inspiration sites (including the ones provided by Brian) and used the web inspector to swap in the campaign’s work-in-progress logo, some images I found of Brian from a Google image search, some nav, and hypothetical headlines. I then presented each site to the campaign for 20 seconds, and had everyone vote on how happy they’d be if this was the site that we ended up with. [](ut test) This was the first time I’ve ever conducted this exercise remotely, and unfortunately Google Forms was acting up so I couldn’t see the vote tallies to formally rank each site. But we were able to walk through the designs and discuss what each person liked and didn’t like about each one. With a little time in the web inspector, I was able to “design” and present over a dozen directions for the site. Keep in mind that this exercise was not an attempt to copy any of these site designs, but rather an attempt to extract general themes that could help guide the visual direction of our custom design. Typography One of those themes was around typography. A few of the sites that scored well in the 20-second gut test all had bold, pronounced typography. I put together a Typecast project that stitched together different Google Font pairings (I used this site for help). Typecast I showed this to the campaign, but we didn’t have to go through it in any depth. I ended up solving this in a different way, which I’ll describe later. Frontend Prep Chef Work While we were talking about design direction, Ian was working behind the scenes to create a lot of the patterns we knew we’d be implementing. Things like headers, footers, hero blocks, form fields, text passages, and so on were all safe patterns to start building out. Other things, like the donate form, needed wired up with third-party tools, so we prioritized building those components out. This frontend prep chef work allowed us to put the structural foundation of the design in place, which wasn’t likely to radically change even as the visual design was established. Theme Switcher Ian and I were thinking about how to start weaving color, typography, and texture into the codebase without committing to one direction. What we decided on was to build a theme switcher. We threw a bunch of Google Fonts from the Typecast exploration into the `