As a designer, I often feel compelled to contribute constructive feedback to the services and apps that I use. In the case of Spoke, I took that to another level and made a significant open source design contribution. The work I did in collaboration with the Spoke team at MoveOn turned out to be a big win for volunteer texters, the organizations that use Spoke, and the candidates and causes we were organizing for in the 2020 election.
The interface that I redesigned is used by texters to respond as replies come in. It is simple and easy to learn while delivering more functionality and context about the contact and the campaign than the previous version.
In November 2019, when I found myself using Spoke to text voters in the Virginia House of Representatives election, I jotted down a list of bugs and feature requests as I was texting. I felt like texting voters was effective but the tools (Spoke, ThruText, ..., etc) were all pretty frustrating to use. It was clear that conversations with voters and the effectiveness of volunteering in the upcoming 2020 election cycle would benefit immensely from some design improvements.
I was heartened to discover that not only could I easily submit feedback, but that Spoke was (and is) an open source project on GitHub with an active community commenting on issues and pull requests. So, I set about writing my first GitHub issue—a detailed feature request to streamline the process of tagging contacts. The community was friendly and very enthusiastic to welcome a designer.
Contributing design via clear user stories and detailed mockups—and the full array of design and planning skills that I brought to the team—had a positive impact on the user experience, the capacity of text teams, response times, new texter training time, and overall user satisfaction. Around the time we were wrapping up the redesign, remote voter contact became crucial to candidates and organizations unwilling to send volunteers door-to-door during a pandemic.
This screenshot shows Spoke before the redesign. The responding interface offered less information yet was harder to learn and required a lot of drilling down to get to responses. (message text intentionally blurred)
Clearly Definied User Stories
When I first encountered the existing collection of issues for Spoke, they showed the vibrancy of the community but needed consistency and many lacked context. Some issues had been created when the community was smaller and didn't make any sense to new contributors like myself. Other issues were vague because they had been created during an election cycle by somebody who was frustrated or had an idea but didn't stick around to add context. There were many loose ends. So, the community manager and I set about tying them up.
After a flurry of effort, the set of issues was distilled down to a small set of detailed, contextualized feature requests and bugs that were part of the overall vision for Spoke to become more usable with more functionality for admins and texters. We also made sure there were lots of detailed small issues tagged for first-time contributors. Which paid off in the effort to grow the team during the busy election cycle. github.com/MoveOnOrg/Spoke/issues
Texter Responding Interface
To focus my design contribution, I identified 3 guiding principles: optimize for volume, quality responses, and ergonomics. These helped me make and justify certain trade-offs. The design takes a clear divergence from the typical person-to-person texting interface. I think of Spoke's responding interface more like a game controller where you are quickly handling conversations with minimal need to drill deep into menus or type long responses. Texters are encouraged and enabled to use pre-written responses that keep messaging consistent, accurate, and fast. All while keeping the interface flexible enough that texters can give responses a personal touch as desired.
I also took a mobile-first approach to the design. Before our work, Spoke was unusable on mobile devices (or barely usable to the point that the documentation and onboarding materials suggested avoiding mobile use). After the redesign, texters were able to quickly tap shortcut response buttons as replies came in, edit messages as desired, quickly opt out contacts as needed, and handle every type of reply. This enabled them to respond throughout the day untethered from their desks and/or give their wrists and backs a break from their desktop.
Mobile-first design of texter responding UI
See the full Prototype
To focus my design contribution, I identified 3 guiding principles: optimize for volume, quality responses, and ergonomics. These helped me make and justify certain trade-offs. The design takes a clear divergence from the typical person-to-person texting interface. I think of Spoke's responding interface more like a game controller where you are quickly handling conversations with minimal need to drill deep into menus or type long responses. Texters are encouraged and enabled to use pre-written responses that keep messaging consistent, accurate, and fast. All while keeping the interface flexible enough that texters can give responses a personal touch as desired.
To focus my design contribution, I identified 3 guiding principles: optimize for volume, quality responses, and ergonomics. These helped me make and justify certain trade-offs. The design takes a clear divergence from the typical person-to-person texting interface. I think of Spoke's responding interface more like a game controller where you are quickly handling conversations with minimal need to drill deep into menus or type long responses. Texters are encouraged and enabled to use pre-written responses that keep messaging consistent, accurate, and fast. All while keeping the interface flexible enough that texters can give responses a personal touch as desired.
The prototype we used for the final round of user testing and working out details is -> here.
screenshots of the actual spoke app before and after the redesign
My contribution to Spoke (an open source mass texting platform) was collaborative organization of the backlog, a redesign of the UI used by texters, and an ongoing presence as a designer in a community mostly comprised of developers and political organizers.
Problems solved: The responding UI went from hard to learn, buggy, and cluttered to an interfaced that was less cluttered yet displayed more information, functional on all devices, and easy to learn and use. The backlog went from a somewhat scattered collection of issues to a set of actionable, tagged issues with context and mockups as needed. Developers working on features that touched the texter or admin UI had a friendly and collaborative design resource.
Design Goals: Big picture: Make texting more efficient and effective by giving texters and admins an easy to use tool with all the features they need (a team effort). In the weeds: Make the app usable on all devices, optimize for volume, improve the quality of responses by guiding texters toward the thoughtful scripted responses, make texting efficient with fewer clicks and less mouse travel. Also, to encourage feature development with clear, illustrated, contextualized GitHub issues.
Challenges: Resistance to change by some admins and moderators (handled by clearly communicating the design and implementation, and thorough user testing to ensure the change would be positive).
Process: Conversations, User Interviews, Sketches, Mockups, Code-based prototype, User-testing, Iteration of the design based on user test feedback, Image-based prototype, QA, incremental roll-out, update of training materials.
Outcomes: Faster and better onboarding of new texters, massive volume capacity, participation from texters on mobile devices, recognition in the organizing community for the best texter experience.
Prototype of the Responding UI
figma.com/proto/...SpokeTexterUI...
Spoke on GitHub
github.com/MoveOnOrg/Spoke
About Spoke
opensource.moveon.org