Spoke is an open source, peer-to-peer, mass-texting platform maintained by MoveOn. I made a contribution to the Spoke project ahead of the 2020 election cycle. This Design Brief documents that contribution—the redesign of interface used by texters (users who volunteer to do mass text messaging) to respond to replies—the Responding UI. It serves to tell the story of why I chose to redesign the Spoke interface, the design process, some insights into why certain decisions were made, and an invitation to future designers who wish to further evolve the Spoke interface.
Overview of Spoke
In case you aren’t familiar with the Spoke platform; here’s a quick summary of what it does, who uses it, and how it works. The Spoke platform enables an organization to set up texting campaigns (a script, pre-written responses, and a contact list) and admins can assign blocks of contacts to texters. The platform uses a messaging service (e.g. Twilio) to enable volunteers to press “Send” on each initial message (a human touch is required for compliance with regulations) and see and respond to replies. The texts are sent to contacts with local phone numbers, not from the phones of volunteers.
The person receiving the text sees a message that was written by the campaign that is usually modified to include the name of the texter, something like, “Hi! This is Arena. I’m a volunteer with Cats for Design. Do you like design?” A texter will send out anywhere from 500-10,000 messages in a session and get a handful of responses throughout the next few days. When responding, texters can:
record an answer to a survey question (e.g. Yes, they like design), choose from pre-written responses (e.g. a response for “how did you get my number?”), respond with a unique message that they type themself, edit a canned response, or opt people out of texts. Sometimes, texters encounter difficult to respond to replies. When this happens, they usually use an associated Slack team to discuss or escalate a conversation and then respond.
Observation and Inspiration
I was a volunteer texter in 2017 for an organization that had deployed Spoke for voter contact. The campaigns we were sending out were effective but the software we were using had the feel of something that had been enhanced many times without a holistic approach to design. It was frustrating and physically painful to use, and had many quirky, buggy interactions. As a good citizen of the software community, I set out to submit some bug reports and feature requests and was delighted to discover a GitHub issues page attached to the Spoke open source project.
My initial feature requests were actually met with some confusion it was unclear to me at the time that there were many forks of Spoke in the wild and I had submitted a feature request to the wrong GitHub issues instance. Once I realized the mistake and also realized that there was a vibrant and welcoming open source community I began texting for MoveOn to get a better feel for the root version of the web app and submitting relevant and detailed feature requests and bug reports. There was one feature in particular that made its way onto the roadmap (bookmarking a conversation).
Upon exploration, that one feature turned into a full redesign of the Texter UI. The Spoke team at MoveOn—especially one dedicated developer, a project and community manager, the leader of the text team, some insightful volunteers, and myself—collaborated to ideate, prototype, and implement a fully responsive, efficient to use, redesign of the Responding UI.
People who respond to replies using Spoke need an interface that is optimized for high volume, comfortable ergonomics, and sending high quality responses. Based on my observations, experience, and listening to the needs of other users; I identified three focusing principles at the outset of the design project:
It’s a numbers game. Optimize for reaching the biggest audience possible, fast.
Volunteering shouldn’t hurt. Reduce any unnecessary repetitive motion.
Thoughtful, detailed, and accurate responses are the most persuasive. Make pre-written responses easy to find and use.
Key Design Decisions
Mass-messaging over personal-messaging patterns
Design patterns used in one-to-one (or small group) texting interfaces don’t map directly to mass-texting interfaces. The main reason is that while personal exchanges are sometimes necessary and effective, the goal of the platform is to foster mass communication that is consistent at the organizational level. Therefore, making it easy for texters to pick a pre-written response (and easier than writing a custom response) was what I optimized for. I put picking a pre-written response front and center with hot buttons. I strived to eliminate any extra clicking (or tapping) needed to select the appropriate response. I also aimed to make selecting and sending a pre-written response feel like the default choice.
This design decision—to make picking a pre-written response the default—is most apparent in the addition of “hot buttons” for common responses. The hot buttons are labeled with the short version of the reply that the texter is seeing (e.g. Yes, No, Wrong Number) and allow them to pick that response intuitively and quickly. Additionally, my design consolidated two sets of response types (survey question responses and other/common responses) into a single list that the user can select from. This consolidation not only sped up the time to get to a response, but flattened the learning curve for new texters who are looking for the right response to a reply.
If I had chosen to optimize for personalization, I might have included an emoji picker or specified putting focus in the response text field. Instead the design minimized the response field and created the feel of a control panel for responding with the hot buttons, the all responses menu and other responding functions right next to the big send button.
Responsive web-app first
Native apps were out of scope for this development sprint. However, I still wanted to take a mobile-first approach to design. Before this redesign, many of the texting guides prescribed only volunteering from a desktop/laptop. It was possible to respond from a mobile device but it could be agonizing due to bugs and/or the recurring need to scroll.
Knowing that texters would need to respond from mobile, I picked a medium sized mobile phone as my default artboard size while exploring the design and periodically considered the design on larger viewports. It is now possible to use Spoke from an iPhone SE and it is super efficient to use it from a larger mobile device. Given the nature of mass-texting responder activities responding on a mobile device is ideal as replies trickle in after the large initial message blast.
Increase information density + reduce redundancy and clutter
There were several well vetted feature requests in the backlog to add more information to the Responding UI. There was also a lot of clutter in the existing UI. The challenge was to meet the needs of some users for more information, meet the need of the Texter to be able to read and focus on conversations, and make it all fit.
Screenshots and Video Tour
We used this prototype to interview users and get feedback before beginning implementation of the new interface. This version of the design (which turned out to be the final version) was modified after a round of user testing earlier designs. Click through yourself here:
Design and Development Process
The process was very thorough including rounds of user feedback and iteration to resolve points of confusion and optimize for ease of use. The process included:
empathetic conversations with texters feedback and more mockups collaborative design thinking and working sessions a code-based prototype and rounds of user testing* image-based prototype with iterations based on learnings validation and adjustments after launch based on feedback at scale*
*this design brief focuses mainly on the design contribution, the design work (sketches, mockups, clickable prototypes, etc.) were done by me, Arena, but other things were done by the MoveOn team (especially the coding, the first round of users tests, and a code based prototype)
Areas of Further Design Exploration (or Design Briefs)
Files and Links