Spoke
Share
Explore
Spoke

Spoke

Design Brief: Redesign of the Responding User Interface Used by Texters
Arena Reed
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.

Design Principles

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:
⁠
np_network_99104_12BA2B.png
⁠
⁠

Volume

It’s a numbers game. Optimize for reaching the biggest audience possible, fast.
⁠
np_hand_44713_12BA2B.png
⁠
⁠

Ergonomics

Volunteering shouldn’t hurt. Reduce any unnecessary repetitive motion.
⁠
np_quote_2409407_12BA2B.png
⁠
⁠

Quality

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

⁠
Before-01.png
⁠
⁠
⁠
After-01.png
⁠
⁠
Clickable Prototype
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:
⁠
https://www.figma.com/proto/iSEUsi3RlJgPmEzvidKDga/Spoke-TexterUI?node-id=652%3A5025&viewport=468%2C-219%2C1&scaling=scale-down
⁠
⁠

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
mockups
feedback and more mockups
collaborative design thinking and working sessions
small prototypes
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*
fine tuning (e.g.
https://github.com/MoveOnOrg/Spoke/issues/1740
⁠
)
*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)
1
User
Link
Area
Notes
GitHub Issue(s)
1
Texter
Sender UX/UI
Mass Send of Initial Texts
Optimize for speed and volume
​
2
Texter
Message Inbox for Texters
Dashboard
Optimize for search/scan/filter and organizing for batch handling
​
3
Texter
​
Escalate Conversation
Already implemented, needs visual design
​
4
Texter
​
Tagging
Already implemented, needs visual design
​
5
Texter
​
Stats
Consider ethics of gamification but also give encouragement and numbers to texters
​
6
Texter
​
Virtual Assistant
​
​
7
Admin
​
Reassignment
​
​
8
Admin
​
Change Texter Roles
​
​
9
Admin
Admin Responses UI
Manage Responses and Shortcut Buttons
​
​
10
Admin
Theme Customization UI
Customize Theme and Branding
​
​
11
Admin
​
Off-script message review dashboard
​
​
12
Texter + Admin
​
Set response character count, hit character count when responding
​
https://github.com/MoveOnOrg/Spoke/issues/1819
There are no rows in this table
⁠


Files and Links

More about Spoke here:
⁠
https://opensource.moveon.org/
⁠
⁠
GitHub Project:
⁠
https://github.com/MoveOnOrg/Spoke
⁠
⁠
Figma Source File:
⁠
https://www.figma.com/file/iSEUsi3RlJgPmEzvidKDga/Spoke-TexterUI?node-id=164%3A59
⁠
⁠




Gallery
Share
 
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.