Project 3 Retrospective

Kickstarter: Recurring payment feature addition

The Brief

This was our first group project. My group, UXtravaganza Think Tank, consisted of Elana Nachshin, James Lam, and me, and we crushed this project. We were tasked with designing for a recurring payment feature for popular crowdsourcing site, Kickstarter.

In the current Kickstarter platform, people can back different projects by pledging a certain amount of money to a project. Projects are only funded if they reach their funding goal by a predetermined date. For this project, Kickstarter wanted to expand to allow projects that will be funded on a repeated schedule instead of only backing a project once.

The two most critical features we had to address were that creators should be able to launch projects that require recurring payments, and backers should be able to discover and fund these projects.

Before I do a deep dive into my process of conquering this project, I’d like to share the best part: the end. After we were finished our project presentation, our three instructors told us that in their combined years of 12 cohorts of giving this specific project brief, our group did the best they had seen in addressing the brief from both the creator and the backer in a way that satisfied their needs as users. I was overjoyed. Now…back to the brief.

My Role

In this project I was unanimously selected by my peers to be the project manager, in addition to our expected roles of UX designers. We all played a hand in a good portion of this project, however, there were several instances where I had to delegate responsibilities.

  • UX Designer, Project Manager
  • Sketched paper wireframes
  • Created digital wireframes, in both medium fidelity and medium-high fidelity
  • Created interactive prototype
  • Conducted usability testing for interactive prototype
  • Led and collaborated in affinity mapping exercises and persona creation
  • Collaborated in feature analysis exercise
  • Collaborated in user stories
  • Created style guide

Trello: As project manager, I used Trello as a means of collaboratively keep tracking of our daily tasks we’ve done, daily tasks we’ve yet to complete and our end deliverables.

Google Drive: We used this as a file repository from which we shared and edited all of our deliverables and presentation documents.

Process

For this project I followed the Double Diamond model developed by the UK Design Council.

Discover

The first phase our our process was researching our brand, its business and monetization techniques and its competitive and comparative landscape.

In this deliverable we also broke down the terminology we’d be using throughout this project internally and for the sake of our audience we’d be presenting to.

We performed a competitive analysis comparing everything from the modes of interface to the tax implications with crowdfunding campaigns.

We also created a style guide to refer to in our designs going forward. This made it much easier to save styles in Sketch and keep our designs in check withe the current Kickstarter brand.

Style Guide

From our competitive and comparative research, we decided to direct our further research toward three different user groups: Creators, Backers and Subscribers. The Subscribers were people who subscribed to services such as Birchbox, Dollar Shave Club, or more niche services like Local Roots CSA. Although Subscribers was not a group of people already identified by Kickstarter, we found it important to learn about the habits and behaviors of this group of people who subscribe (aka pay on a recurring schedule) to products to design for the addition of a recurring payments feature.

From here we created a survey screener using Google Forms to reach out to as many people as possible who were either a Creator, Backer, or Subscriber, or a combination of two or more. Through this approach we cast a wide net to reach as many people as possible, then funnel down into a smaller and smaller group of eligible people until we finally had a select few qualified candidates to interview. We interviews five Creators, five Backers and five Subscribers.

These interviews provided us with some deep insights into the four list (pleasures, pains, contexts and behaviors) surrounding crowdfunding campaigns as well as an assortment of pains and pleasures to focus on surrounding subscription-based services.

We had multiple affinity mapping sessions and categorized the data we collected from user interviews into behaviors, motivations, pleasures and pains.

From left: burning the midnight oil, affinity mapping whiteboard sesh

From our results we distilled our researched user base into two categories of people toward whom we catered our designs. We developed two primary personas: one Creator named Maki and one Backer named Pat. We also included a supplementary persona named Kathryn, a Subscriber whom we used as a reference for feature design.

From left: Creator, Backer, Subscriber

Define

Using our personas as reference, we conducted a feature prioritization exercise to identify which features we needed to design in our to meet the needs of our two distinct personas. The subscriber persona was a crucial part of this exercise as well.

We first created a Cartesian coordinate system to map out features on continuums of feasibility and importance. Then we utilized the Moscow Method to organize and prioritize the features we were to design.

From left: Feature prioritization with corresponding pain/pleasure point, Moscow Method
Moscow Method

From our feature prioritization exercises we arrived at our MVP aka minimum viable product aka the most necessary features to test with our users and avoid development of products users don’t want.

We prioritized the ‘Musts’ and deprioritized down to ‘Won’ts’.

Once we reached our MVP, we created user stories to showcase sample scenarios in which people would use our new feature. These also served as great tasks to assign people during our subsequent user testing of our wires.

User Stories

In addition to user stories, we created two user journeys: one for the current model of backing and creating a project on Kickstarter and one for our suggested model of recurring payments.

These user journeys show different activities of creators and backers and where they meet through touchpoints as the project progresses from creation to end of funding duration. The middle area shows the range of emotions creators and backers experience through this process.

User Journeys

The green and red areas indicate a positive and negative experience, respectively, and their height indicates severity.

The current model has multiple periods of negative emotion from the creators’ embarrassment of soliciting funds directly and the backers’ frustration by constant solicitation.

Our model has only one period of negative emotion at the onset of the project where the creator must set up a page and initially ask for donations.

In effect, we have designed in attempt to reduce the feeling of embarrassment associated with asking others for money. We truly are designing for emotion.

Our designs seamlessly integrate into Kickstarter’s current IA and we illustrated that into our sitemap and into our designs in the My Profile dropdown

From left: sitemap and My Profile dropdown

Develop

This stage consisted of ideation in the form of sketching. We took to pen and paper and began our development process. We used design charrettes where we timeboxed alternating periods of divergent and convergent sketching to get maximum and equal input from each of us.

Our end result looked something like this.

They may look beautiful, but this is why form follows function and not the other way around.

The Backer flow (left) shows the process of donating to a project on a recurring basis. The Creator flow (right) shows the creation of customized templates to ease the negative emotions experienced with directly soliciting others.

We decided to test these paper wireframes to see if users could understand where to go and how to navigate the features we integrated. This proved to be a nightmare and the impetus for why I’m now extremely hesitant to test with paper prototypes again. My problem with paper prototyping was that we tried to remain as minimal as possible — using lines for text and boxes for buttons, input fields and images. However, a lot of content and meaning gets lost in translation when you do this. Without clear labeling of each element on the page and coupled with the fact that it doesn’t feel like a real site made it hard for users to understand what they were looking at. Nontheless, I learned from this experience and we moved forward as a group to digital design.

We needed to make up for lost time so we used Sketch to digitize our wires and proceeded to test with users. (This was the fastest I have ever digitally designed wireframes in my life. My concentration at this point was impenetrable.)

Wireframes

Testing with digital wires made it 10x easier for users to understand the context and content we were showing them. Thus, we got some great feedback from them and corrected our designs accordingly.

Project page

Case in point. This wire show the project page and the option to subscribe to a project aka donate to a project on a monthly basis. In our testing, users were confused by the callout shape being used to group the subscription options. I don’t blame them. For some reason, when we transferred our designs from paper to digital we all missed this subtle but important distinction.

Making mistakes :( but learning from them :)

The ‘Subscribe…’ should have been outside the callout. Anyway, we iterated on our wires and came up with a blatantly obvious solution that would be crystal clear for users.

This elucidated any confusion and proved to be a fantastic feature integration. Now, users can either select to ‘Back this project once’ or ‘Subscribe to this project’ by choosing a fixed dollar amount per month.

After confirming our designs with a pool of users, we prototyped our medium fidelity designs into InVision. From there, we testing our prototype with incredible results! Users only had a few pain points and identified where and even how their experience could be improved.

After making these last, minuscule changes, we created medium-high fidelity versions of the wires which we then plugged into InVision by swapping with each medium fidelity screen.

Project page in medium-high fidelity

Deliver

In the last phase we created our final interactive prototype and delivered a 15-minute presentation to our cohort and three instructors.

Our deck can be viewed via my LinkedIn profile under projects completed while in General Assembly.

This prototype covers both flows of the creator of a project posting or emailing updates to her current project via the Updates Manager and the backer being able to select to donate to a project on a recurring basis. I left hotspot hinting ON so you can see which areas are clickable.

Next steps:

Had we had more resources (mainly time) these are some things we would have done differently or added to our scope.

Short Term

  • Further flesh out the process of creating a project that accepts recuring donations.
  • User test the wires for the flow of the creator creating a project that accepts recurring donations.

Long Term

  • Design for mobile
  • Allow creators to change the funding duration of a project after a project has launched

Granular

  • Create a breadcrumb system so users can easily have a sense of where they are in the site and where they came from

Conceptual

  • experiment with designing in high fidelity first AND THEN testing prototypes using hifi mockups