Launch quickly
It can be anxiety-inducing to release something into the world when you know it could be better if only given a little more time, but there were two big beliefs that led us to a fast launch for Vox.
1. Fail fast and iterate
Like many product teams, we operate iteratively by default, shipping the simplest possible version of the thing we’re making, observing the results, and adapting. But we’ve always taken our time with new brand launches, because they require the creation and coordination of so many interdependent things: editorial vision and team; name, logo, and look-and-feel; advertising and revenue plan; product vision, design, and development; and so on. We also want to make a compelling first impression — even if the site is not everything we want it to be at launch, we want to realize enough of the editorial and product vision to make readers understand why the site exists and give them reason to come back.
For Vox, founders Ezra Klein, Melissa Bell, and Matt Yglesias had been thinking about the news-explaining problem for a long time. They came to Vox Media with big ideas that were ready to be fleshed out and put to the test, and were open to taking a chance with a new approach. And we felt ready to challenge the assumptions baked into our usual new brand design and development process.
Just a few days after Project X was announced, we proposed an idea to Ezra, Melissa, and Matt, and the senior leadership individuals in the company, including Jim Bankoff, our CEO: launch a minimum viable site quickly and iterate in public. Everyone got excited, got behind the idea, and got to work — in some cases substantially disrupting their existing plans (editorial had to radically accelerate hiring, for instance). The entire organization supported the project, not just at the start, but all the way through launch.
2. Trust in a minimum viable product
Before we started planning a fast launch, we knew we had to solve one problem: enable the editorial team to quickly start publishing content somehow.
Before we launched The Verge, we set up This Is My Next, a temporary Wordpress blog where the writers could hone their editorial process and stay engaged in the public conversation. Likewise, with Vox, we had to decide how the editorial team could start writing while we made the site.
Initially, we intended to set up a throwaway site for Vox, and build up to a big launch in late 2014, or possibly early 2015. But we’ve done a lot of work on our platform since The Verge launched in 2011. Chorus is now a platform with enough built-in functionality that a feature-rich site can be set up quickly, and it enables us to rapidly design, build, ship, and iterate on new ideas.
So when we started thinking through what it would take to set up a throwaway site, we asked ourselves, how much extra effort would it be to just build the real site instead?
In order to meet our expectations for what a new Vox Media site must be, we would focus on two big things: the important early and foundational branding and visual design work; and a new, still-to-be-figured-out product feature for helping readers understand the news. By limiting the new big things to only those two, we could free ourselves to throw all of our creative energy into them, and do them well, and rely on the work done by our past selves to carry the rest of the site.
Once everyone agreed to this plan, in every conversation about scope and the prioritization of site features, we were able to stay grounded by our shared sense of what was important to get right for launch, and what could wait for now.
Anchor the project on a hackweek
We scheduled a hackweek for mid-February and organized the rest of the project around it.
Why was the hackweek important? Because it anchored the project, keeping us focused during planning and design, and by setting a timebox only a week long, it enabled us to work around the reality that most product team members were already engaged with other project work. We couldn’t afford to borrow people from other projects for the entire Vox project, but we could afford to borrow them for a week — because, hey, it’s just a week — and thus we assembled a relatively large team of makers.
The bulk of the site development occurred during the hackweek. We gathered relevant product and editorial team members together in one place and cleared our plates so that we could focus our attention and make decisions quickly.
Once the hackweek was scheduled, it was an immovable object
To be productive, the hackweek required certain inputs: branding and visual design, a basic site map and wireframes of key screens, high level direction on the important things, and a clean foundation in Chorus that everyone could start hacking on in hour one. If we spent the first part of the hackweek sorting through ambiguities or trying to get time on a stakeholder’s calendar, instead of actually making the site, we knew we would be doomed. We had to enter the hackweek organized and with as few open questions as possible.
To launch the site quickly post-hackweek, the hackweek’s output needed to be a feature-complete site. The site would be buggy and require polish, but all the big pieces would be in place, all the hard problems would be figured out, and all the known issues would be logged, such that it would be feasible to scale back to a smaller team, estimate the remaining work, and launch the site a few weeks later.
Once the hackweek was scheduled, it was an immovable object. Flights and hotels were booked for out-of-towners and the company was made aware of the unavailability of certain team members for that week. The act of scheduling it put pressure on ourselves to keep the scope of the site reined-in during early product design sessions. We had to move quickly on branding, visual direction, and defining the version one product.
As front-end engineer Scott Kellum put it after launch, from the hackweek through launch it felt like we were going downhill instead of up. We got our arms around the project and defined our mission early. Every day, the site was more complete and our task list shorter than the day before.
Phase 1: branding and visual design, solution design, and technical exploration
We pulled together a small team for this first phase of the project, and spent the three weeks between February 3 and February 22 focused on the following tracks of work:
a. Visual design
From my perspective as an engineer, the most astonishing aspect of this project was that a name was selected (it was not a given that we would name this new site after our company) and a logo and overall look-and-feel were created in this short timeframe.
"The design process for Vox was both daunting and exhilarating," designer Warren Schultheis said. "Initially, it was just Trei, Melissa, Ted, and me locked in a smallish conference room working non-stop for 2 weeks. Let’s just say there was a lot of trail mix, whiteboarding, and whiskey."
Warren and senior design director Ted Irvine passed early visual direction mocks back and forth as they dug deeper into potential design vocabularies. In parallel to the visual language conversations, Warren reached out to several other (mostly contract) designers for branding explorations, including our own Dylan Lathrop, who wound up designing the final Vox mark. This work was followed by formal design/branding presentations to stakeholders.
"One of the best things about the process was the level of open-mindedness and trust from Ezra, Melissa, and Matt," Ted said. "We had the freedom to take some risks and produce some relatively ambitious ideas within very tight time constraints."
Once the initial design language was established (and the branding decided upon), Ted and Warren looped in designers Uy Tieu and Georgia Cowley to help deliver all the key screens that were needed. Without their fresh eyes and hard work, the site you see today would not exist.
b. Solution design
Another big thing to figure out pre-hackweek was how to use Chorus to support the editorial vision of explaining the news. Would we provide a means for editors to annotate news articles? Would every news article include a full relevant contextual explainer at the bottom? Would we need to create a wiki? How would we go about converting our big ideas into working software?
Melissa, Trei, and director of user experience Ryan Gantz paced around a conference room and scribbled on a whiteboard for several hours attempting to answer these questions. As they zeroed in on an approach, Ryan built a simple clickable HTML prototype to articulate their ideas. It succeeded in rapidly helping all team members grok the core concept of what would become Card Stacks, and convince us that it could actually work. When Ryan walked me through his prototype, I remember thinking, "OK, now I know what we need to do."
As we approached the hackweek and started looping in more designers and engineers, the prototype beat the pants off of any comp or wireframe at efficiently communicating what we were setting out to accomplish.
c. Technical exploration
As part of our attempt to do as little new work as possible, Trei proposed that we use the SB Nation layout as a starting point for Vox.
If you are a person who makes websites, you are aware that designing and building a responsive, performant, cross-browser, cross-device layout that gracefully supports whatever content a writer might drop into it is hard work that takes time. Since our goal was not to take time, we wondered: can we create a unique and compelling site by layering distinct type, color, etc., on top of the proven responsive SB Nation piers and beams? And will doing so save us time not just during the design phase, but during development as well?
So we had our third pre-hackweek goal: in addition to laying the foundation for the development of a new site in Chorus, we would determine whether it was possible to cleanly re-use existing front-end code from SB Nation.
Some quick context: though our properties are powered by a common platform, we invest a great deal of energy in the public-facing presentation layer of each site. As a user, when you move between SB Nation, The Verge, and Polygon, we want you to find that certain things — like our commenting system — function consistently, but we also want you to feel that when you visit each one of those sites you are someplace special.
All of that is to say that the SB Nation public-facing front-end HTML and SASS was built to work on SB Nation only. It was unclear how much we would be able to leverage, or whether it would be faster and more straightforward, code-wise, to start from scratch.
I sat down with senior front-end engineer Dan Chilton, who led a refactoring project last year to deal with some broken windows left behind after our SB Nation United redesign in 2012. One goal of that refactoring project was to restructure the SB Nation SASS code into small, reusable modules. Dan told me that the styles that define the fundamental structure of the page — that is, the way the basic content rectangles that make up the page are laid out at each browser width breakpoint — were already well-separated from the more SB Nation-specific styles for things like type and color. So, for Vox, we were able to easily pluck out and re-use only the specific, structural front-end code that we needed, leaving behind all the rest.
By the start of the hackweek, we had a Git branch set up in Chorus with a working-in-a-basic-way Vox home page powered by the structural front-end code repurpoused from SB Nation.
Phase 2: Hack, hack, hack
The hackweek started on Saturday, February 22 and ended on Friday, February 28. We piled into the big conference room at the back of our DC headquarters, adjacent to the new Vox editorial benches.
Mind the risk of burnout
At one point in the planning process, VP of technology Pablo Mercado asked, "Is this going to be a bonkers hackweek?"
The answer was yes. By bonkers hackweek, Pablo meant that we weren’t just going to work together on a project for a week; we would work long hours, focusing all of our attention and energy on this one project, essentially tossing work/life balance out the window for those seven days.
Channeling a team’s passion in this way is like playing with plutonium: an incredible amount of energy can be created, but it’s also easy to explode things
Channeling a team’s passion in this way is like playing with plutonium: an incredible amount of energy can be created, but it’s also easy to explode things. Applying one’s complete focus to a single problem for most of one’s waking hours can be incredibly productive and satisfying in infrequently-occurring short bursts, but taken too far, it can burn a person out and ruin a team.
Ed Catmull, co-founder of Pixar, writes about this danger in "Creativity, Inc." addressing the nine-month-long death-march that was Toy Story 2: "Asking this much of our people, even when they wanted to give it, was not acceptable."
In the past, we have made the mistake of driving our team — or letting our team drive itself — too hard. Over the last couple of years, we’ve tried to be more mindful and not let our projects get away from us.
In this case, since the hackweek had a short, fixed timeframe (i.e., built-in bright light at the end of the tunnel) and we had a clear mission, we felt the experience would be positive. We would all work hard together for seven days to make something great, and then we would go back to our normal lives. But we talked with each team member beforehand to ensure that everyone understood and approved of what they were getting into.
Divide and conquer
We divided up the work into roughly two chunks: the Card Stacks news-explaining product, informed by the solution design and prototyping work done by Melissa, Ryan, and Trei; and everything else.
For the everything else — home, article, stream, and all the other site pages — there were few unknowns. We had comps and wireframes, and repurposed structural SASS from SB Nation, and the existing product functionality provided by Chorus. The work was primarily to tie all of those things together and do the front-end engineering to implement the Vox-specific elements of the design. This work was substantial and important — much of a site’s final design and user experience is determined in the details of implementation — but it was work that was well understood.
For Card Stacks, we had an initial huddle at the start of the hackweek to review Ryan’s prototype and make a plan. Engineers Jake Lear and Blake Thomson focused on building a responsive Backbone-powered front-end application, with Jesse Young stubbing out a fake server-side JSON API. Meanwhile, Pablo and I debated and settled on an approach to the Chorus server-side architecture and a minimum viable editorial workflow.
For the server-side architecture, we had to balance our desire not to introduce too many unwieldy hacks into the system that would fill us with self-loathing and cause our engineering team to roll their eyes at us later, with the requirement that we actually get something working by the end of the week. We arrived at a good-enough approach, repurposing and subclassing some existing Chorus models. We reminded ourselves that we would be able to revisit once this version of the site had launched and we could see that Card Stacks was going to be a successful and long-lived product.
For the minimum viable editorial workflow tools used to create and manage Card Stacks — we set up a rudimentary system in the Chorus back-end editorial app. We worked with Melissa to ensure that it would be good enough for launch, again keeping in mind that we would be able to revisit later. (And we did, a few weeks following launch, making incremental updates to address the pain points reported by editorial during the first few weeks of real-world usage.)
Stay organized while moving fast
To keep everything on track, we managed tasks in Fogbugz, our issue tracking system. We entered the hackweek with cases logged for the known work. They started off as all-encompassing tasks like, "Stand up article page," and we made them more granular as we got pages working in a basic way and started to focus on details. Though we were all sitting in the same room and it was easy to talk, we were a large group simultaneously building a single site, so the extra overhead of managing our tasks in a tool was worth it. We avoided stepping on each other’s toes and always had a clear sense of our progress.
We also entered the hackweek with day-by-day goals set for ourselves like, Day 1: Stand up Article Page and comments, and Day 5: Stream Page, Video Page, User/Author Profile Pages feature-complete with high-fidelity styling. Honestly, after the first day, we all pretty much ignored the schedule, but along with the associated cases logged in Fogbugz, the schedule provided the team with an initial birds-eye view of all the things that needed to get done and a sense of the pace we would need to maintain.
Phase 3: Demo, QA, polish, and launch
On Friday, the last day of the hackweek, we did a short, informal demo for the editorial team. I asked Melissa to bring Ezra and Matt into the room with set expectations that the site was not ready for primetime. She ended up inviting all of the editorial staff that had come aboard thus far. They were sitting just outside the conference room we were working in and she wanted them to feel a part of the hackweek. It was an unexpectedly large group, and the presentation was much more casual than any of our previous stakeholder meetings.
"The editorial team was so excited to see the end result of all the hard work that had been going on behind them all week long," Melissa said. "It also served as motivation for them to double down on their own preparatory work. They saw we would be launching very, very soon."
Then we all went to Lucky Bar and enjoyed some beverages together.
After the hackweek, with nearly every aspect of the site working in a basic way, we scaled back to a much smaller team. The next five weeks were spent focusing on quality assurance testing and bug-fixing, and polishing the site’s rough edges.
Jon Douglas, our QA manager, had his work cut out for him.
"Testing an entirely new website — as opposed to a single new feature — was daunting, especially with our aggressive schedule," Jon said. "In retrospect, the main reason we had a successful launch in terms of quality assurance was the regular feedback loop between me and other team members, both during and after the hackweek. As the site started to take shape, I created a comprehensive test plan to ensure that each component was thoroughly tested and that all elements not only functioned correctly but also displayed properly across various browsers and devices."
On the evening of Sunday, April 6, we reassembled the team in the same room we sat in during the hackweek and pressed a button that launched Vox into the world.
Now what?
With the initial version of the site launched, we are just getting started. Melissa announced in a discussion at the end of April that we are no longer referring to what happened on April 6 as a "launch," but instead as a "deploy," the first of many. We have transitioned out of post-release bug-fixing mode and into product design and development sprints, and we are releasing new iterations of our work almost every day.
The ultimate success of this approach and of Vox will depend on whether our team and organization are able to maintain momentum and iteratively evolve the site.
We'll keep writing about what we learned across an array of topics, from branding and visual design to the technology behind Card Stacks, and what we're still learning now.
And in a year, we’ll check back in and see how we did.