Hello!

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.