Admittedly, I am horrible at formally documenting my process, but I found these post it notes hiding under a stack of papers on my desk. Chances are I wrote them some time about January or February when I was planning out my initial prototype. While I had set out to design an easier and more sustainable way for people to save money, I ended up teaching myself and learning a lot about prototyping for behavior change— because lets be honest, saving money is not quite as attractive to people as spending it.
According to my post-its, here are the things I was thinking about as I started prototyping: (I’ve included a few thoughts and links to posts I have written in the interim to fill in gaps, insights, and findings.)
- Design for existing strengths not weaknesses I wrote about this before, but I think it is the one point that has been the driving force behind the majority of my design and prototype decisions, so I will say it again: The key to success is not in telling users to work harder at something they already suck at, but in giving them the tools to improve upon their existing strengths.
- Design for capabilities not limitations: We already feel so limited by what we can and can’t do with our money. Our options around saving are so limited that I found that some of my prototype participants didn’t even know what a savings goal was. They thought saving was something that was wrapped up in a 401K, home ownership or life insurance plan - all things that were inaccessible and irrelevant to their life experience and behaviors around money. They weren’t able to even fathom saving for something so huge - so they didn’t. And as a result, they didn’t save for anything else either. My design focused on setting short term goals - things that users felt like they could complete confidently and competently in a knowable amount of time. The framework was something they could wrap their heads around - it was something they felt capable of working towards and completing.
- Design for users’ lack of time It goes without saying that most mobile experiences should be designed around what Josh Clark calls “quick hits”: that is - Assume that interactions with the app are going to be wedged between all the other things we are doing in our day. Don’t have any delusions that people will actually want to engage whenever a notification comes through. The job of the designer is to make them want to engage and make that experience as simple as possible. “The best apps fold neatly into the fabric of a busy schedule… Get me there in a tap or two.” This means that the act of saving has to be quick. Easy. Effortless. In a nutshell, I had to make the act of saving as easy as swiping a credit card…. or easier.
- Design for users competing priorities This was a hard one to tackle because the priorities and behaviors that I was up against were pretty big. I have written about this elsewhere, but to summarize: I had to make saving money for something in the near future more attractive and pleasurable than spending money (and seeing immediate gain) in the present. The main way I have been thinking about this is to make the “saving” experience as positive as possible. If the one bad thing about making a purchase is feeling guilty about spending the money, I’d do the opposite. I’d make people feel like they were paying themselves. And everyone likes to wake up with some extra money in their pocket. I want my experience to feel like that.
- Be there for users when things start to break down: I had to figure out ways to anticipate even the most positive of actions breaking down. What happens when people fall off the wagon, so to speak? What happens when they get tired of making a daily contribution or realize they are actually saving too much and can’t sustain their day-to-day lifestyle? What happens then? As I worked through my prototype this past month I had to purposefully break interactions in order to find the best to build them back up.
- Make it as easy as possible to get people involved. This is obvious. Perhaps more than the actual contribution action, I’ve been putting a lot of time and energy into the onboarding process. At times it seems ancillary and I kick myself for not putting time into the other actions and potential features, but then I remember that in order to be involved you have to GET involved. So… moving on.
- Design for a trajectory of use rather than one time use. My prototype also addressed user over time. How long did I want people to be engaged? When do I give them breaks? How long is enough? How long is too long? I hate to beat a potentially dead horse, but a lot of my thinking around this was inspired from coaching and preparing competitive training programs for athletes. Change is only going to happen if you switch up the intensity, frequency and rest periods often so people don’t plateau or fatigue. The goal is always to be improving.
“ People think that design is styling. Design is not style. It’s not about giving shape to the shell and not giving a damn about the guts. Good design is a renaissance attitude that combines technology, cognitive science, human need, and beauty to produce something that the world didn’t know it was missing.”
I’ve spent the past two days thinking a bit more purposefully about who I want to pitch my thesis to on May 12 - a day I have dubbed the Frabjous Day - which is besides the point for this blog post, … but anyway. I made a quick diagram of all of the potential audiences for my thesis pitch— individuals and specific organizations, and what they might be interested in hearing about (in red). It is a lot and I have the basic skeleton of a compelling pitch for each of these gorups… Which is a real drag because I only have 7 minutes.
This weekend I spent a fair amount of time working through the various service touchpoints within the collaborative finance product I am building. Before this weekend, I had spent significant time building out a strong experience around the contribution action making sure that all parts of the system supported that action in a way that was meaningful, easy, and relevant to the users’ goals, needs and contexts. This thinking manifested itself in how I structured groups, contribution frequency and periodicity, and on-screen UI elements. I am feeling confident on most of these fronts and need to shift back to the greater user experience with the product. As I have been working these past weeks I have identified three main points within the user experience of my product that are especially important. Unlike my previous work around the contributions - which focused on getting someone to start something, these three points focus on the tangible acknowledgement of a completed user action. They are:
- completion of a daily contribution
- completion of a sprint
- achievement of a goal
My thinking is this: that if a user feels great about a daily contribution, they will be more apt to continue to the end of a sprint. If they are positively acknowledged at the end of a sprint, they will be more likely to continue on towards their goal. The positive feedback upon reaching a goal, seems an obvious one, but the event is such a major accomplishment considering the behaviors around saving, that it deserves an equally major celebration.
This week I will be developing more specific ideas around each of these moments and constructing a more specific narrative around my product that (hopefully) I will be able to communicate through a video or other means in the next 6 weeks time.
Mark has always been impatient, so he decided to make an honest effort at getting his head back above water. Taking the advice from his New Year’s resolutions article, he started small, by putting away one dollar a day.
Some time passed, and Mark realized that he wasn’t missing that daily dollar. He went up to two, then three, then four dollars a day as the months went by. Before long, Mark’s saving became automatic. He would make his daily savings transfer almost right away after he woke up.
My work for the past 12 months has focused on how we can use existing social structures and informal networks to create viable financial relationships and transactions. I think these kinds of transactions fuse design, interaction, behavior, and business objectives in ways we have never seen.
As I plow my way through the final weeks of thesis, I find myself revisiting the possibilities for products like Twitter to help the kinds of P2P transactions that my collaborative finance product facilitates. Companies like Chirpify have only started to pave the way for these interactions, with perhaps little awareness of the massive iceberg that they sit on the very tip of. Obviously, the possibility for direct payment between consumer accounts via a platform like Twitter has some exciting integrations. But I want to get at what’s lurking just below the surface - what’s out there, but not yet within our reach or vision as of yet.
As I think about the nascent ability for social platforms to facilitate transactions, I have to ask: what happens when this kind of social media driven payment technology reaches audiences who are not looking for a unique way to buy a shirt at their favorite store or make a donation to a local charity? What then?
As westerners, we are used to transferring money electronically because our banking infrastructure has made it possible to do so. However, in other parts of the world it is not a banking infrastructure, but a communications network that has already allowed millions of people to transfer money between each other and businesses, catapulting the need for institutional frameworks. (I’m thinking specifically of M-PESA and Safaricom, here, among others.) The shift from payments via a banking infrastructure to a communications network is massive. It has changed (or will change, depending on your geography) all of our interactions and traditional behaviors around financial products and services. Over here where our interactions with money have been, for decades and decades, the most private of matters, we think that the union of payment technology with a communication platform is new. It is not. And while we are a bit behind the curve, that does not make this kind of payment/communication union any less revolutionary. There are many more things I could say about that, and will, sometime in a following blog post or two.
However, for now, I will say that what IS new is the integration of payments to a SOCIAL communication platform like Twitter. The difference here is that the addition of the word “social” makes all transactions that were once very private, incredibly public. I am not sitting alone at my desk conducting a private transaction with an online retailer or beloved charity. I am not even out in the middle of Africa using my mobile phone to pay for healthcare services. No. I am conducting a transaction that is being broadcast to 100 million people around the world— which, for reasons that should be obvious, is amazingly powerful. It seems clear to me, but I will say it anyway, that because these transactions are made public via SOCIAL media, these transactions are, themselves, inherently social. Again, a seemingly obvious thought, but to my surprise not one that many people have thought of. Mostly because that level of exposure brings up the equally thorny topic of privacy, which people immediately assume is inextricable from our financial transactions. There has been lots written about this as products like Blippy hit center stage a few years back, so I won’t rehash here. I have found that there are bigger fish to fry and some incredible interactions and behaviors to design for within this newly social financial context.
(As an aside, My delineation between interaction and behavior is quite purposeful - where interaction is tied to physical actions (swiping a credit card) and behavior is linked more to our state of mind (I will not swipe my credit card because I am scared to go into more debt.) To design for social (and potentially collaborative) payment models means you have to design for both interaction and behavior - which unlike privacy, are, in fact, inextricably linked when it comes to money.
How do you design for that? How do you design for social and collaborative payment models? Once payments go public it is one thing to worry about broadcasting your feed and payment activity… but it seems like a trite problem compared to the massive opportunity that can be found when you combine technology, social groups and payment structures. What my thesis addresses is how our behavior changes when technology makes our payment actions go public, and how to design for that. What I have found over the past year is that to design for this kind of interaction, there are a few things we need to rethink:
1.) We have to rethink our conception of a social network.
Currently, our social products are wired for quantity. How many people can I follow, how many friends can I add, how many connections can I get, how many photos can I upload. This is all fine and well, but when it comes to our behaviors around money, this might be the first time in decades (dare I say centuries) where technology has led us to prioritize quality of financial relationships over the quantity of financial resources. Put simply, until we become comfortable with the social nature of our payments, WHO we interact with is more important than the amounts we transact. If we build social platforms for monetary exchange they have to design for meaningful interaction between people. Otherwise they become merely a broadcast.
2.) We have to rethink motivation.
When payments become social, the action of paying (not just the resulting purchase) also becomes social. If we assume that a financial action is the result of a financial behavior, and that behavior is most likely linked to a particular motivation or incentive, we have to ask, What happens when people start to expose their motivations (or incentives) via social payment platforms? What then? While people might be comfortable linking their bank account to a social payments network, are they equally comfortable with how other users perceive their actions, behaviors and motivations? To ensure maximum engagement, we must design experiences that are “safe” not only from a financial perspective, but also from a social and behavioral perspective. Which brings me to:
3.) We have to design for groups rather than individual users.
To design for a social payment platform means we have to understand the complexities of social motivations, which are… well, insanely complex. Adding social to financial exchange means that we’ve introduced a third group of stakeholders into the equation. Where e-commerce had to forge new relationships between merchant and consumer, social transactions have to address the addition of all social interactions that our financial transactions touch. This means shifting our designs away from a singular user, and towards designs that serve the strong personal connections amongst groups of users.
I wonder if we are equipped and ready to tackle such challenges as these. Not only as designers, but as users. I hope so. Because I am.
“ The next generation of successful social products will acknowledge that our social capital is a currency. They will provide tools to enhance our social capital’s functionality as a store of value, a medium of exchange and a unit of account. They will replicate the deep feature set at our hands to deal with money — banking, tracking, exchanging, investing, et cetera — for our connections and relationships. Over the past five years, social networks and the decreasing cost of bandwidth and storage have lowered the transaction costs of social capital exchanges by orders of magnitude. Now, the race is on to provide the best tools and infrastructure around this new currency.”
I’ve been thinking about the amount friction within my product. I have gone to great lengths to design an experience that makes the savings process as friction-less as possible without automating it all together. My conversations with both Charles and Allan this past week have me revisiting the idea, however, and examining the advantages and disadvantages of adding or subtracting friction from the savings process.
The friction filled point that I am talking about is, again, the payment action. Allan saw this repeated action as adding friction in a positive way - causing users to slow down a purchase (or contribution) decision and be actively involved in the process of helping someone achieve their savings goal. The reminder not only lets them actively participate financially, but gives them a definite time and place to check up, support, input, and suggest other ways that someone could reach their goal. It gives the “saver” constant and immediate feedback as to what people think about their goals and the ability to change them if their friends think there is a better, faster, cheaper, or alternative way to reach them.
Charles thinks that the payment action (as easy as it is) is still too much friction over time and that people will not want to bother with the daily action or the notifications that will come with it. These things in combination will become burdensome and actually heighten the amount of friction in the experience even more, causing people to not engage. He suggested that it become automated so that people don’t have to think about it at all.
I see the benefit to both arguments. The notification fatigue was one that I was actually really worried about in my prototype, but didn’t get a chance to test its limits because 1) my prototype was not long enough, and 2) people knew they weren’t saving for their entire goal, so could deal with the notifications. (That said, most participants responded positively to daily notifications for just over 3 weeks.)
I actually see great value in Charles’ insight, and the major problem I have with automating the contribution action is that there would be no engagement around the most important interaction and decision of the entire experience. The lack of responsibility around financial behaviors (even positive ones) is a problem I hoped to address. I am now realizing that in the execution phase of my project, that this goal is at odds with another goal I had of encouraging sustainable financial behaviors.
I go back to the idea of “alignment”- to have alignment with the goal of “sustainability” would suggest that I need to automate the payment action. Reduce friction. However, to align with the goal of “responsibility”, it seems that I would need to keep it as a conscious action. Add (a litte) friction. So now the real question becomes what are my priorities? How can I refocus my goals or refine the user experience into a more cohesive execution? I have some ideas. Time will tell whether they are good ones. Stay tuned.
I have been working to make a payment screen that is a simple, yet engaging experience that gives people the information they need in order to make a contribution decision towards someone else’s goal. I was able to streamline quite a bit from last week, and so Charles and I had a lot to talk about today.
Our conversation centered around the idea of alignment. Do the actions within the app align with the mission and goals of what I am trying to do: namely change behavior around savings habits. As such, we spent a vast majority of the hour or so we met talking about the payment action.
Feedback from my prototype suggested that users’ conscious decisions to give someone money was valuable because it reminded them in a very tangible way that they were helping a friend (or themselves) with a specific goal. In many ways, this daily action provided users with immediate, positive, and social feedback that they need to overcome the difficulty in saving. On the other hand, the daily contribution reminder forced them to take conscious financial action towards one thing rather than another. Not only does this have the potential to become burdensome, but also (for better or worse) makes them aware of the financial choices they are making… which also might become a hinderance to engagement.
So Charles and I began to talk about the advantages and disadvantages to making this action automatic - as most other savings programs have done. There seems to be something important about giving people the choice to contribute so as not to put them in a situation where they have “over-saved” but also so they can take ownership over the action. It is something that they did. On purpose. And with purpose. And while that might be difficult, it seems that there would be a greater sense of accomplishment at the end knowing that you took very conscious steps to achieve something rather than having that “something” (being the achievement of a savings goal) just happen for you. The question becomes though, how difficult does this become and at what point does it just need to be easy?
So that is a problem I will be working through in the upcoming weeks. The other “aligning” question that we have begun to talk about is how to align a potential business model to the user experience. This is something that has been lurking in the shadows of my research, prototyping, and design for the past 6 months, but one I have not really felt ready to address until… well, now. And “ready” is a relative term. But I think that in order for this to be a viable solution to a savings problem it has to have an awareness of the business limitations and opportunities. Which in the payment world, are immense and complex. By which i mean “immensely complex.”
This afternoon I had a great meeting with Allan and he gave me some fantastic feedback. He was enthusiastic about my idea but encouraged me to create ways for users to be more opinionated and involved in their teammate’s goals. This was an shadow of an idea that I had discarded a long while back because I didn’t want my product to become just another version of Svpply. However, as we talked, I began to see it not so much as a way to curate purchases, but a way to be involved in your teammates’ goals. As Allan put it, how could you NOT contribute to a goal and not comment, advise, offer suggestions or input into what you are helping to finance?
If someone is saving money for a series of date nights with their spouse or partner and you are in a group with them, why wouldn’t you want the opportunity to give them recommendations or help plan their first date? If another friend wants to buy some woodworking tools, but you suggest that they change their goal to a series of woodworking classes so that they can learn which tools they would use the most. I had a message feature built in, but I think this small twist will make a world of difference in the value that the product can provide to all types of users.
Allan also encouraged me to spend a lot of time boiling my service down to the essential components - three bullet points that encapsulate the “need to knows” about how to interact with it. I had heard this feedback before, but never felt like I had a plan of attack on how to accomplish it. He gave me specific, actionable steps - which were incredibly helpful.
Lastly, he told me to have fun. This was perhaps the best advice of all. I’ll be spending the next week, cranking out a new set of wireframes around expanded use cases, prototyping the messaging features, and culling the concept down.
Once I had documented possible scenarios, it seemed important that I address some of the group dynamics within the collaborative model. I came up with a series of interaction flows that addressed how money would pass between group members. The three images represent:
- Giving to your own goal
- Giving to a teammate’s goal
- Giving to a teammate’s goal if they did not give to yours
The vertical swim lanes (from l-r) show
- User action
- Financial reward (if any)
- Financial loss (if any)
Before I started officially prototyping, I documented potential advantages and disadvantages (fig 1.), and mapped out possible saving and lending scenarios within both the group (fig 2.) and individual models. (fig 3.)
In comparing these initial models, I immediately noticed a few things that helped me map out a plan of attack for each model. In the group model (fig 2) contributions and deposits were consistent and predictable. While the individual model focused wholly on giving to your own goals, the group model encouraged giving to others more than paying yourself. There were challenges to both approaches. I’ve outlined some of my original thinking and made notes in parentheses about possible ways to test each item:
What are the advantages and disadvantages of each model? (How will you test them?)
Advantages to the group model:
- Consistent behavior (daily payment notifications via Venmo)
- Explicit social pressure (confirmation of who has contributed to your goal)
- Saving and lending are combined
Disadvantages to group model
- Notification fatigue (Send notifications at consistent times that deliver relevant information, build in “days off”)
- Giving to someone else takes focus off of your own goals (?? This is an assumption.)
- Lack of participation from one member will affect the entire group (Build clear mechanisms so that team members are not negatively affected. Clear communication of where money is going and how it is circulating)
- Commitment to a single group may be difficult. (user feedback)
Advantages to the individual model
- Not tied to a specific group
- Complete focus on individual goals (give users tips on how to set their own payment schedule)
- Challenges between friends may increase saving motivation (create a weekly challenge that users can opt into for additional motivation and structure.)
Disadvantages to individual model
- Lack of groups decreases incentive to give tangible support
- Participants will find it difficult to get started on their own schedule
HOW I WILL DO IT: What is the context in which these things will be tested?
Group based model based off of collective investment
How does this work?
The above diagram shows how the group model can facilitate defined and specific groups within one’s social network.
- Users form small groups
- Each user (or group) identifies something they want to buy but don’t have money for right now.
- Each member of the group uses their mobile phone to make a regular contribution of an equal amount at regular intervals
- At the end of each interval, one person’s mobile “account” receives the total contribution
- The cycle continues until all members have received their share
- At the end of the cycle, members can decide to withdrawal their money or continue another round until their goal is met
Individual model that uses a group for support
How does this work?
In comparison, the individual model relies more on loose connections between many members within a user’s social network. Goals, amounts and collaborations are encouraged by the system, but ultimately self-sustaining.
- Users work individually
- Each user identifies something they want to buy but don’t have money for right now.
- Each user uses their mobile phone to make a regular contributions towards their goal at regular intervals
- Users can participate in and organize challenges with other members of their social network
- At specific milestones, members can decide to withdrawal their money or continue to the next milestone.
This weekend I went back and started to visualize the written documentation I have done for my prototype.
Prototype Implementation Strategy
February 3, 2012
This week I have started my first prototype in earnest. It has been a lot harder to coordinate than I would have expected. I have put quite a bit of time into planning how it will be introduced to people, what technology I need to run it, and how it will be structured.
During the planning phase, I decided to focus solely on saving rather than both saving and lending. While a lending component makes the system more robust, and allows participants to have a financial investment in the product, I have decided to focus on saving first for the following reasons:
- Lending adds complexity that will be hard for users to understand
- Within the system, saving is a prerequisite for lending
- There are few financial products that focus on social saving and none that focus on collaborative saving.
INITIAL INSIGHTS AND CHALLENGES
What does your prototype need to address?
- Short term gain vs. long term value
- What will make someone want to save instead of spend?
- What will keep someone from withdrawing before they attain their goal?
- Trust and reputation systems around money and social groups
- Motivate consistent deposits over a period of time
OVERALL PROTOTYPE GOALS
What does your prototype need to do?
- Get people to set a savings goal
- Get people to work in a group or individually towards that goal
- Implement an engaging mobile deposit collection experience
What do you hope to find?
- Will people be able to identify a savings goal?
- Will people make payments towards that goal?
- Will people be willing to work in groups towards that goal?