The old petition creation flow
Explore the old petition flow in this Figma prototype
Change had a top-level company goal of increasing quality petitions on their platform over 2022. They were blocked by an old petition creation flow that was difficult, frustrating, and costly to develop in. There were also loads of validated opportunities, relevant to our goals, that we could pursue if we had a petition creation flow that was easier to make additions, modifications, and experiments with.
I worked independently as the design lead for the work in partnership with a product manager lead and an engineering manager lead, as well as a team of engineers on the product delivery cycle.
I led the team through a rigorous research and design process and successfully launched a new, refactored, accessible petition creation flow that resulted in a 22% increase in quality petitions, 32% reduction in errors preventing publishing, as well as an estimated $100k additional weekly revenue. I also doubled the rate of optional phone number opt-ins and increased the petition creation CSAT from 63.5% to 90%
To see the full case study in all it's glory, check it out on your desktop or a tablet. In the meantime, you can still explore a prototype of the new petition creation flow!
Change had a top-level company goal of increasing quality petitions and victories. We had uncovered a lot of exciting opportunities around petition creation and petition management that we were eager to go after, but we found ourselves frequently blocked by our petition creation flow. It was over 6 years old and both the design and code base made it difficult to make changes to.
My team was tasked with improving petition creation and building a new product surface area for handoff to a new team that was being hired. I worked independently as the design lead on this project in partnership with a product manager lead and an engineering manager lead, as well as a team of engineers who developed and delivered the final designs.
The design process included:
My product team had been focused on petition starters for a few years and I had conducted hundreds of user interviews and had a good idea of how the petition flow was working for those users. For this work, it was important to hear from people that might publish a petition, but hadn't. I surveyed users who had visited the flow, but had not published a petition and recruited users from the petition creation flow to participate in interviews. I also created a customer satisfaction (CSAT) poll for the flow to establish our baseline metric and start getting qualitative commentary. Lastly, I assessed the flow from a general design and heuristic perspective to round out our initial research and assessment and my product partner gathered relevant data via historic data and experimentation to inform our decision making.
Heuristics are design principles that experts use as guides in our design decision making. Nielsen Norman Group are the creators of 10 usability heuristics that have been the industry standard for decades.
Based on the research, metrics, and common best practices, there were several key opportunities that we could have high confidence in.
Once we had sufficiently explored and mapped the opportunity space I shared our findings with our stakeholders and our broader team began our initial scoping and solution exploration. To achieve that, we used a process called storyboarding from product strategy expert Teresa Torres’ and her book: Continuous Discovery Habits.
How storyboarding works: The goal is to map out a journey as exhaustively as you can. For example, if you were storyboarding "Getting ready in the morning" you might add things like: brush your teeth, drink coffee, feed the cat, pack lunches, and so on. Different people bring different routines! Once you have exhaustively captured all of the possible "Getting ready" steps, you then narrow them down. What if you woke up late and had 5 minutes to get out the door? What steps would you have to take?
By the end of our team discussions, we’d settled on a storyboard that looked something like the image shown here. Each green sticky note in the top row describes a general step, and the pink stickies stacked below describe activities that users complete during that step. We prioritized activities collectively and aligned on priority zero, one, and two releases.
I gathered a variety of possible high level solutions for petition creation and asked my product and engineering teammates to do the same. We considered a robust WYSIWYG editing tool, like Medium, or a longer form flow, like Patreon. We considered breaking the flow down even more and creating a wizard-style experience, and of course we considered something similar to our existing question and answer flow.
Our team evaluated each solution idea against our goals and criteria, and we scored them on a matrix to review and discuss. We aligned on using a single question and answer flow, similar to current petition creation flow. Some of the reasons and benefits for choosing this solution included:
With the broad solution agreed upon, I was able to begin the delivery phase of design work, and began to iterate with wireframing, prototyping, and usability testing. Myself and the product and engineering leads formulated assumptions and hypotheses to test and inform our work.
I also created prototypes, wrote scripts, and assembled user tests to validate some of our other hypotheses and assumptions. Through testing I could see that without the decision maker step, users were still mentioning their DM in their petition stories, they understood and anticipated the way the navigation behaved, and overall I had gathered enough signal that I was confident our UX was improved. After a handful of product experiments, engineering spikes, usability tests, and prototypes, the design solution was complete.
The new flow is accessible, performant, and heuristically sound. It is completely modular and can be easily added to. The leaky log in funnel has been fixed, and the most important features made their way to the first release and additional features had been prioritized, sequenced, and in some cases even designed. We also improved the user experience and added additional value by supporting multiple image upload in the first release.
For more highlights and changes, keep swiping!
Where the old flow was rigid and difficult to develop, the new flow was completely modular. Pages could be rearranged, edited, removed, added, and even forked with ease.
This would supercharge future experimentation, and I left behind loads of validated opportunities and wireframes for the next team to utilize.
We didn't rebuild the decision maker and topic pages for the first release. Both required substantial discovery and delivery work, and so were prioritized for future quarters.
The new log in and sign up flow was broken into steps in order to intelligently route users. We could detect whether an email address was a new user or a returning user, and whether that returning user had set their own password.
This allowed us to automatically trigger a verification email to returning users with no password and route them through the password reset flow and back to publishing. The result is that we minimized the number of steps users had to get through and we made sure that no users were left behind or lost during this step.
The new flow was performant, accessible, and not only modular at a high level, but had been designed modularly at a page level. Various input types had been accounted for and commonly requested features were mocked up at a mid-fidelity level as an additional handoff present for the new growth team.