Where We Started
Building on our pro-bono work in 2013 with the Vendor Finder web app, a grant from the Central City Foundation enabled Megaphone to retain us in solving a bigger problem. Despite Megaphone’s growing profile, vendors were seeing sales decline because their readers are carrying cash less often. Their vision was a mobile app that would enable vendors to process cashless payments on the spot, and halt the decline in sales that was harming their livelihood.
What We Did
We looked into other attempted cashless payment systems for street newspapers and other programs that help lower-income people around the world, finding a mix of approaches and degrees of success. We also ran interviews with readers, vendors, and Megaphone staff, and studied Apple and Google app store policies to position our transactions so they wouldn’t be subject to the usual 30% cut those stores take.
Development began with the custom web application. Accessible only to Megaphone staff, the backend manages vendor details, product availability, and most importantly, sales and payouts along with some financial reporting.
Soon after, we dug into creating the app portion. While some features were able to migrate more or less unchanged from the original Vendor Finder app, newer ones center on the cashless payments feature, like payment setup, a shopping cart, product showcasing, push notifications, and so on. Even in small apps, there’s always so much to do.
We tested and refined the design throughout the development effort, and a couple months before release settled into a gradual process of validating and testing everything thoroughly before gearing up to a public launch.
Direct and social media feedback tell us that customers find the app easy and enjoyable to use. Transactions are coming in, and vendors are picking up their earnings quickly, sometimes on the same day. But the real measure of success will come in the form of higher sales and tip numbers for vendors. We also want to hear that the system pays off enough to make up for having vendors make the trip to the Megaphone office to collect their earnings.
Cash will always be king for Megaphone vendors. Usually you want everyone to use your app, but we really do want the app to come second to cash transactions, because that’s what works best for vendors. But when cash isn’t in hand, there’s now a way for Megaphone vendors to make the sale.
While the Megaphone App is working away for vendors in Vancouver (and soon Victoria), the groundwork is being laid for a bigger difference. Megaphone has agreed to open source the app, meaning that with some customization, it will soon be available for use by street paper organizations around the world.
…though the Megaphone App is a tech solution, at its heart it’s still about one of Megaphone’s core values: Connecting people.
Todd, Tylor, Arian, and the team at Denim & Steel did an incredible job on the Megaphone App. They listened carefully to vendor and customer needs, and they created a solution that will help vendors succeed. By launching the App, we’re setting vendors up with technology that will help them continue to earn a living in our increasingly cashless society and help our dedicated customers ensure they can continue supporting vendors.
- Jessica Hannon, Executive Director
Six weeks after launch, Jessica added:
Vendors experiences with the App have been really positive, and it has been fun to see the transformation from “I’m not so sure about this…I don’t really understand smartphones” to “Woo! It worked! I got paid!” It has also led to more contact with vendors who might not normally come to the office very often (instead using depots around the city to buy magazines and calendars). That opportunity to check in with vendors more often and offer them more support and community engagement has been positive too!
On December 21, we moved the server and app code to open source projects under the Non-Profit Open Software License 3.0. The intent is to enable other street newspapers, and even other non-profits, to adapt the project to their own cities, vendors, and products, opening up cashless payments without starting from scratch.
The codebase is split into a server repo and app repo.
Concept & Strategy
Validation, ideation, and roadmap planning for new ideas.
Creative design and production for apps & websites.
- Ruby on Rails
- Custom-printed paper notepads
The Deeper Story
There are challenges in building any consumer app, but we can usually make safe assumptions about what are really privileges of a modern society. With the Megaphone App, things were more complex. We’d be building for people who live across an economic divide with differing access to smartphones and even bank accounts.
We understood that financial precarity makes vendors especially vulnerable to changes in the current system that they, and their customers, were used to. For vendors, cash transactions mean day-to-day certainty, and anything that got in the way of that was cause for concern. But they also knew that fewer people carrying cash meant lower sales, and gave us our chance to show that this could work.
So we started from an unusual position: by questioning the need to have an app at all. We wondered if the problem could be solved by through less complex means. After exploring a variety of analog systems, like subscription and deferred consumption purchases, we agreed that an app for cashless payments made the most sense.
More than App Design
Rather than app design, we looked at this as designing a system that would bring together and impact different actors, third party services, policies, and technical pieces. In that system design, we made a few important decisions:
The customer should have the app, as they’re most likely to have smartphones with data plans. Since most Megaphone readers are recurring customers, we also saw that we could set up payment once for many transactions by keeping the app on the consumer side, rather than having vendors process a credit card as new for each sale.
We concluded that we could use an external payment processor within the app store policies. Because we’re not selling a digital good, Megaphone sales are exempt from the requirement to use in-app purchases, and from the 30% cut. We’d also put a lot of work into streamlining credit card set up. If we were selling digital copies of Megaphone in the app, the requirement to give up 30% per sale would apply. This understanding saved the entire project, as customers are able to bear a 3% service fee for using Stripe, but not 30%.
Make it possible for Megaphone to pay vendors directly. Where some vendors may not have access to banking, it matters to all vendors that they get their earnings faster than Stripe can deliver it. Using the web backend we built for the app, we made it possible for Megaphone staff to see transactions the moment they happen, and to pay out accumulated earnings with ease when vendors drop by.
With the design set, the actual programming work to build the web-based backend and the mobile app for Android and iOS went smoothly (though always smoother on iOS). When two people are involved in an app interaction, waiting time is awkward time, and split attention. We obsessed over making the app fast using a variety of technical methods, but also making the tough decision to set aside the slick transitions and effects that bring oohs and ahhs.
When the app project was announced to vendors, and especially during our research interviews, we heard strong concerns from vendors about introducing cashless payments. And who can blame them? A cash sale is a certain sale, and for vendors who buy Megaphone’s products up front to re-sell, they saw a risk in trusting their day-to-day living to a system that would in many ways, be a black box to them.
We set about working on ways we could build trust in the system. We started with making sure the system was trustworthy, with multiple audits of the transaction process, hundreds of tests, and checking the numbers to be sure everything lined up.
In the app, we added a confirmation code to each transaction that appears in the app. We then turned to some old fashioned technology to bridge the gap, getting custom-printed notepads made to give to vendors so they could record their transaction numbers and amounts. With numbers in hand, they can verify for themselves that the system is working correctly before opening themselves up fully to cashless payments.
The Handshake Screen
During user testing, facilitated by Market and UX Researcher Lauren Isaacson, a usability problem surfaced that led to one of the most interesting aspects of the app, which we call the Handshake Screen. The original design for the transaction confirmation screen was intended to be shown to the vendor so they could see that payment was completed.
Many test customers did this correctly, but some saw the button to proceed and immediately hit it out of habit. This was too much potential for an awkward moment of digging up the transaction record in the app, so we started to think about this moment very differently.
Thinking about the physical posture of vendor and customer during a transaction, we redesigned this screen for two halves: one facing the customer using the app, and one upside down. When the phone is lowered towards the vendor, the inverted side shows the vendor the confirmation, with a button for them to press and indicate they have seen it. Only then can the customer press the a second completion button, and only then is the transaction completed.
The redesigned completion screen is doing more than just showing vendors that payment is made. It creates a different kind of moment for using an app. Lowering the phone to share the interaction works to retain rather than interrupt the connection between vendor and reader, and gives vendors some agency in the transaction even when they don’t have a phone.