How an Idea Becomes an App

Birth of an Idea

I’m a UX researcher and designer by trade. For my professional development and continuing education, I’ve been taking the Coursera Interaction Design Specialization. When the final capstone course, where we design a mobile web application, started the day before primary elections in California, I knew what I needed to do.

I drafted some questions, jumped in the car and drove around my city, stopping in front of polling places, the library and other public locations. There’s a housing crisis in my city and I had recently signed a petition to get a rental initiative on the ballot, so I knew they would be out there.

I tracked down two volunteers who were standing in the sun collecting signatures. I observed them and asked questions about their experience. I also asked one of the petition signers for his take. I learned that the process was slow — it was taking months; the emotional toll of rejection and hostility even from people who cared about the issues was evident; and reaching people was costly in both time and money. Plus, the sunburn I went away with was very real.

A sketch of a volunteer’s booth from my field notes.

Paper First

With this deeper understanding, I sat down to contemplate their experience and created storyboards as a way to think through the problem space and think about high-level solutions.

A storyboard shows the problem space and how the user is able to solve the problem with the app.

From there I created several paper prototypes. The prototypes incorporated concepts like automating the petition process, helping citizens find the petitions for issues they care about and collecting signatures from people in the comfort of their own home.

With a paper prototype, I could simulate a person signing the petition with their finger.

And the signature would “magically” appear.

Early Feedback

I received expert feedback from another designer who pointed out a few flaws in my design. For example, he noticed I hadn’t given users the option to reject the petition and hadn’t given them an easy way to return to the petition after they had signed it.

From his feedback, I decided to change direction slightly and focus only on the most essential aspects of the app for the initial iterations of the design. So I focused on giving users the information they need to make a decision about whether or not to sign the petition (its description, who is backing it and the deadline). I also focused on allowing them to sign and on giving them the opportunity to share the petition with others. Additionally, I gave them more escape hatches — letting them say they weren’t interested or change their minds after they signed.

HTML, CSS and JS

Then I whipped up an HTML/CSS prototype on top of Twitter’s Bootstrap framework. I got a developer to help me make a canvas for people to sign their names on. At this point, none of the information was stored anywhere, but it gave the illusion of a working prototype.

The finger signature page. It is still a little buggy since it doesn’t expand when users tilt their phone. But focusing on that bug or the visual design at this stage would have given diminishing returns.

User Testing

With this prototype, I conducted user tests. I asked two volunteers to use the app to decide whether or not to sign, to actually sign, to change their minds about signing and then to share the petition with friends.

The gist of the results was that it was “very easy” to use. But one participant was hesitant even to sign a fake petition. He shared a horror story of being spammed by 12 different organizations after signing an actual online petition. This made it clear that privacy was important to people if the app were to be a success.

A/B Testing

Based on that finding, I decided to run an A/B test. This is where I randomly show one of two different versions of the app to people who visit it.

I created two versions of the petition’s landing page — one that included a privacy disclaimer assuring users that their info would only be used for the petition and nothing else, and one without the disclaimer. I wanted to see how many people clicked through from each of those versions to the page where they could start signing the petition.

Version A includes the privacy disclaimer.

I set up the experiment using Google Analytics and shared a link to my app on Facebook, Twitter and through text. After several days I had data from 35 people, a small sample size. 61% who saw the disclaimer started the signature process compared to only 33% who did not see it. I analyzed the results using a chi-square statistical test. I found that the difference, although large, was not statistically significant.

Because I needed to move quickly, I made the practical decision to include the disclaimer for future iterations rather than continue the test.

The Result

Thanks to a user-centered-design process, the HearUS! App prototype demonstrates a way to make it easier for people to:

• Find petitions — all the petition backer needs to do is share the link in the news, by email or on social media
• Decide whether or not to sign, by providing the information they need to know
• Share the petition with their friends and family
• Sign with their finger, wherever they are, whenever they have the time

And, if implemented, it would make collecting signatures easy by checking whether or not signers are registered to vote and tracking how many signatures have been collected so the backers know right away when they have enough signatures.

The Future

But this isn’t the end. I still need to do testing to validate the changes I made. And there is so much more functionality to design, like the back-end, a petition backer’s dashboard and signature functionality for people who don’t have working fingers. Not to mention, I need to conduct research to better understand what else happens behind the scenes, for example, how the government processes the petitions.

Thanks to the user-centered-design approach I took, it is clear that this is a real need.