Lessons from The Verge Hack Week 2014

Normally, I work quietly at a desk in Vox Media’s DC office where I’ve been interning for the summer. Even though I sit out on Vox.com’s editorial floor, I usually only talk with fellow product people or specific writers and editors I’m collaborating with on a story.

Last week was a change of pace. I was sitting in the middle of The Verge’s newsroom with product team members, reporters, and writers, brainstorming possible storytelling tools in the name of Hack Week. It wasn’t the traditional sleepless, Social Network pounding-shots-while-coding kind of hackathon. Rather, it aimed to bring editorial and product closer together and have Verge reporters and editors "play with new tools and experiment with new storytelling ideas" but do so "out in the open."

The Verge’s Hack Week was an opportunity to embrace mistakes. With this kind of atmosphere that afforded experimentation and innovation, it was my initial goal to pitch and launch something independently. I quickly learned that part of experimenting out in the open was preparing for equal parts success and failure — and ultimately learning from those experiences. Here were my takeaways:

Authoring tools vs. editorial choices

It’s one thing to build an authoring tool, but another to use it in the wild. Although we pushed out 1383420 quizzes/flowcharts/timelines, it was helpful for the product team to see the ways in which reporters and editors used the tools to refine the UI and UX design. Likewise, it was important for editorial to understand the choices involved in creating a useful quiz or an awesome image slider.

While it’s important to make sure authoring tools work and are designed properly, it’s just as important for editorial to understand best practices when it comes to using them. In an interview with Poynter, The Verge editor-in-chief Nilay Patel noted that "maybe we shouldn’t have a site full of quizzes" but "now we have a staff that is much better at deciding what a quiz is good for."

Test early and break things

For most of the week, I was building a user submission version of The Verge’s "What’s in Your Bag" series. Even though we were going to seed the feature with a few submissions from the product team and Verge staff, I held off on sending out the email that would invite testers to participate. I had it in my head that things had to be (close to) perfect before I even sent it around for internal testing.

Within ten minutes of sending that email, the artfully arranged "what’s in your bag" photos were replaced with broken images and Unicode characters, and I saw scary lines of JavaScript appear in a few of the responses. Yuri Victor had just taught me an important security lesson about cross site scripting. It exposed security vulnerabilities in the form validation and submission process that was a major oversight on my end because it was crucial to its functionality. As someone who didn’t even know what XSS looked like until a week ago, it was also great to have a few other developers offer their help in writing regular expressions and sanitizing input fields.

The earlier you can get a working prototype in front of people the better. It’s better to discover bugs and potential security risks early, so you can fix them before launch.

Start building tools by building for specific use cases

While reflecting a bit on Hack Week, Rebecca Lai (who also helped build the quiz generator) said that the best way to begin building useful tools is to design for one or two initial use cases, then make it scalable. Once people see something built, they can start to imagine other ways it can be applied.

For example, the same template that The Verge used in their compilation of the best Ice Bucket Challenge videos was reused during Hack Week for a listenable history of Kanye West samples.

Building for use cases also requires more conversation between members of the product team and editorial staff. Rather than having people pitch a solution (i.e. "I want a searchable database."), they can have a conversation about an underlying problem (i.e. "How can I allow readers to explore the raw data?"). Those more open-ended discussions tackle concrete pain points and make product people less of the traditional service desk and more genuine problem solvers.