The Client

Ripple is an SMS rapid-response tool developed by Strive Digital to help grassroots organizers mobilize their communities. Users can send survey-style text blasts to their members and view the responses. Ripple’s monthly prices are significantly less than larger competitors. This was done intentionally because their target users are members of grassroots organizations who may have limited funding and resources.

 The Project

Myself and three other UX Designers (Dov Albert, Angelina Lin, and Elizabeth Bartels) were brought in during the development process to help create a dashboard that would enable campaign organizers to organize, review, analyze, and take action regarding responses that were collected from an SMS blast. When we joined the project, the client was still developing the product with a plan for a public launch in one month’s time. New features and tools were being added as we were designing, so we had to communicate often and be ready to pivot quickly and grow with the product.

When designing, we had to be aware of the constraints of the client’s small dev team, the intentionally simple aesthetic and style of the site, and the logistical and technical limitations of SMS texting.

Methods Used: Competitive analysis, user research, ideation, sketches, wireframing, mockups, prototyping, and usability testing.

Tools Used: Sketch, InVision, InDesign, OmniGraffle, JIRA

Original Product 

When we joined the project, Ripple was in use by 12 beta partners and the interface looked like this:

There were only 4 main features offered from the service at this time: Sending a blast text, editing the auto-response that new members receive when they text-in to the join the list, a way to view members (phone numbers only, but a name could be manually assigned) and responses, and the capability to export the list to a CSV file that could be manipulated in Excel or different database program.

The user flow of the product looked as follows:


How might we present the collected results in a clean and delightful way that enables users to effectively gain useful insights for their organization?

User Interviews

We conducted interviews with 2 of Ripple’s beta partners and 7 campaign organizers who use other SMS or e-mail blast services. We also consulted 2 dashboard developers to advise us on best practices when designing dashboards for analytic purposes.

We learned that users like to use these blast services because of the ability to reach a wide audience quickly. Their goals in sending out messages include raising awareness of causes and events and inciting immediate action.

Behaviors: The user uses SMS rapid response tools to send announcements, yes/no surveys, and monitor interest, RSVPs, or attendance for events

Needs: An easy-to-use tool that can be learned quickly

Wants: Visual representations of data

Pain Points: Users need to use several different tools (blast tool, database, analytic tools, etc.) to accomplish their tasks. There is a lot of time spent learning, training, and transferring information to different programs.


After completing the user interviews, we developed the following “I” statements that would inspire our personas and drive our design:

  • I want to connect/engage with my base on an immediate level.
  • I want to expand the reach of my organization.
  • I like visual representations of data.
  • I want to incite action.
  • I need something easy to use and easily accessible.


For this product, we created two personas. They both work for our hypothetical grassroots activist organization, Rights and Action.

Meg, Primary Persona

Charlie, Secondary Persona

User Journey (Meg- Primary Persona)

Insights → Features

Visual representations of data Graphs

View reports side-by-side Comparisons

Simple, easy to learn Centralized dashboard interface

Feature Prioritization

MoSCoW Method



Due to the rapid development of the product, as we were designing, we decided to design 4 separate wireframes demonstrating the dashboard layout and features and then conducted a brief series of usability tests. We then presented the wireframes to the client to receive feedback and consolidated our designs into the MVP. The following is the wireframe I created and proposed during this part of the process:

Usability Testing for Wireframe 2

I conducted usability tests with 4 users, asking them to view the results from a survey and send a new message to the people who responded “Yes” to the survey from 09/01/17. All 4 users successfully completed the tasks, but the word “survey” gave several users some pause. Some recommended using the phrase “message history” instead of “survey history”. On a scale of 1–5 regarding the ease of use (1 being hardest and 5 being easiest), the average rating was a 4.

Next Steps

As far as next steps are concerned, there are several things we think could be done to benefit the organizer and maximize the potential and product offering of Ripple. No matter who uses it, at the end of the day it depends solely on the user and what they’re able to get the product besides just information. How awesome would it be if they could use the information to truly benefit and grow their organization? If the product could identify super users (users who typically respond to announcements and surveys or attend events) those could be established lists and then the organizer could send that list messages asking for donations, since they might be more likely to donate, as opposed to rare uses, who when asked to donate, may, in fact, churn and leave the service. We would also like to see further work done on the inbox feature that the Ripple team implemented because right now it seems like it might be overwhelming for the organizer to potentially be managing hundreds to thousands of messages in one location. We also recommended the incorporation of more graphs and analytical statistics (such as the time of day that responses happen, a geographic distribution based on area code, etc). These additional stats could be used to influence when they send messages and market targeting.