How casual user interviews affected our petition creation design concept
In the past year, I have been designing a new petition creation and management experience on Change.org. For a site that specializes in viral world-changing petitions, this is an important process to perfect. Our previous petition creation experience consisted of three inputs and a giant red button (Fig. 1) While the design optimized the quantity of petitions created, it hardly addressed quality. Our product team was willing to compromise a portion of our creation rates in exchange for better-written content, thereby leading to more petition victories. Our specific metrics to gauge this project’s success include petition author sharing rates and the percent of petitions that reach five or more signatures.
Fig. 1: Previous petition creation page Our previous petition creation concept optimized for quantity of petitions over quality. We had lots of room for improvement.
Designing the concepts
After far-reaching research and generative design exploration, our design team narrowed our ideas down to three concepts for the new creation process. ‘Alpha,’ the most forward-looking design, was a blank worksheet with subtle placeholder text. The minimal template featured in-line editing and sleek interactions (Fig. 2). Alpha was fast and innovative, but we questioned whether our less tech-savvy users would agree.
Fig. 2: Alpha concept This Balsamiq mock-up of Alpha shows interaction details like tips that appear upon input focus, hover states, and exclusively in-line editing.
Our second concept, ‘Bravo,’ expanded on Alpha. The initial page used in-line editing, but subsequent steps offered more guidance. A wizard walked users through four steps, a quality indicator measured petition completeness, and a preview button showed the content exactly as it would appear on the site. Bravo was bulkier than Alpha, but we hoped its thoroughness would translate into high-quality petitions.
‘Charlie’ borrowed the same comprehensive steps from Bravo, but the initial view was more similar to our preexisting petition creation page. In lieu of Alpha and Bravo’s in-line editing, Charlie used standard inputs, allowing the help text to show permanently (Fig. 3). As a creator filled out the fields, a miniature petition preview built in real-time in the right column. Even so, our design team considered Charlie a fall-back concept because it was the most traditional.
Fig. 3: Charlie concept Charlie focuses attention on one field at a time. A miniature petition preview builds in real time as the creator fills out the fields.
Product Developer Alexander McCormmach and our engineers built these three concepts as interactive prototypes using meteor.js. They weren’t connected to any backend, but they offered an easy way to user-test the products. Armed with laptops, we were ready to hit the streets.
Conducting the interviews
Alexander and I, along with a rotating group of engineers, walked to coffee shops near our Potrero Hill office to conduct the user interviews. We offered each participant a gift certificate to the coffee shop and promised to take less than an hour of their time.
Since most creators have an issue in mind before composing a petition, we started by helping our interviewees brainstorm an appropriate issue. Their ideas ranged from expanding late-night MUNI service to abolishing San Francisco’s open container law. We used the screen recording app Silverback to record each interview. We initially only tested Alpha and Bravo, confident we’d have success with one or the other. After only three tests with Alpha, it was obvious that new petition creators needed more guidance. Bravo’s results were a bit more promising, but some people didn’t click into the fields until they had fully formed their phrasing, eliminating the value of the tips on focus. We decided to cut Alpha from the tests and concentrate exclusively on Bravo and Charlie. With Charlie, our testers wrote significantly higher quality petitions and better understood the process as a whole. The highlighted inputs eliminated confusion of where to focus. Interviewees were more likely to read the help text and frequently delighted in the real-time preview on the right. Charlie was our clear winner—an outcome we might not have chosen without user interviews.
Parsing the results
Excited by our research findings, our design team was confident enough to move forward with Charlie. We scaled the design to accommodate the MVP, and our team, the Candy Rats*, built the page on our new node.js platform (Fig. 4). The first Charlie creation page is now part of an experiment on Change.org, and we are collecting initial data. Both qualitative user-interviews and quantitative experiment data will inform the next design iteration. Our trek isn’t over, but feels good to have found the candy mountain.
* If you don’t understand this name, rewatch this video.
Fig. 4: New Charlie petition creation This page is part of an experiment to see how the new design performs. We’re currently building the next steps of the creation flow, including editing and previewing the petition before sharing it with friends.
Lauren P. Adams
lauren at change dot org
Project contributors: Luke Arduino, Alain Bloch, José Capó, Warren Colbert, Dustin Diaz, Ali Faiz, Nate Kerksick, Alexander McCormmach, Jon Merrifield, Mike Nothum, and Jeremy Thibeaux