A “Today View” Widget for YNAB’s iPhone App
Between June and August of 2016 I applied and was considered for a UX design position at You Need a Budget (YNAB), one of my all-time favorite companies. Out of 450 applicants I made it into their top 7, which I largely attribute to this “pre-interview project.” Later in the process they posed an interesting design challenge to candidates — you can read how I solved it here.
I want to work at YNAB. So do hundreds of other designers, I imagine. So I’ve decided to be proactive and demonstrate the kind of value I’d bring by showing how I would go about designing a new feature for their iPhone app.
My goal is to be exhaustive without being exhausting. We’ll see how I do!
I think it’s essential for designers to understand the business angle of a product, the mechanisms which allow it to turn a profit. It’s possible to become so focused on the user experience and the interface that we neglect the business’s perspective and drift into a little snow-globe world where everything is pretty and well-placed, untouched by things like revenue or churn. The danger for designers is that we become enamored with product ideas that seem to offer a lot of value to users, but don’t fit the business. Instead, we need to seek the overlap, which can only happen if we take the time to learn what matters to the business.
In this case I had to rely largely on conjecture, but I found a lot of helpful information on the company blog and their social media channels. I identified at least two big goals that the YNAB team is likely going for.
- Get YNAB4 users to switch to the new YNAB
- Increase user engagement with their budget, regardless of the device
With the first goal, we’re talking about acquisition vs. retention. The cost to acquire a new customer is almost always higher than the cost to retain an existing customer. It appears that a certain population of YNAB’s users are on the verge of mutiny and desertion (per forum discussions and Reddit). It’s not that they’ve abandoned the YNAB method in favor of something else… There’s a dynamic here that I would love to understand. In fact, as one of the first things I would do as part of the team I would seek to understand the underlying “jobs” that people “hire” YNAB to do for them, and would use that perspective to cast light on why some customers have switched to the new version and some have not. This fascinates me.
The second goal hearkens back to a post that Jesse shared a few years ago where he wrote, “We’re headed to a place where the device you’re using doesn’t really matter, but the budget does.” Clearly, that remains their focus since they’ve dubbed this year “The Year of Mobile.” More and more, people want to be able to do anything, anywhere, any time, on any device. Providing a connected experience with our products is paramount.
Jobs To Be Done
Adam Stoddard, former Chief Experience Officer (CXO) at YNAB, wrote about there being at least 3 fundamental “jobs” that people “hire” YNAB to do for them.
- Do more with my money
- Reduce stress
- Achieve some financial peace
Imagine if someone told you, “Budgeting is fun, so you should do it.”
No, budgeting isn’t fun all by itself. Rather it’s a way to gain those things listed above — that’s the real fun. Incidentally, for my wife and I, some of that fun flows back into the actual process of budgeting. We put it on our calendar and dedicate most of an evening to it. It invariably gets us on the same page, makes us more aware of our financial situation, and reignites our excitement to achieve our goals. That’s the real reason why we love our monthly budget and why we “hire” YNAB to help us stick to it.
Software is not an end unto itself. People only use an app as long as they feel it’s the best tool for the job they’re trying to do. Otherwise, they’ll start looking elsewhere. With so many ways to potentially improve an app, I look for real solutions, to real problems, for real people, that is, things that make the app better at what people “hire” it to do.
With business goals and key customer “jobs” squarely in view, I began listing out ideas that might be worth exploring. Some of these are bad ideas. Not inherently bad, mind you, but bad for a host of other reasons. My goal was simply to get them out of my head and on paper, where I could really scrutinize them.
- Add and edit categories from the mobile app
- Enable search / filtering in mobile app
- Allow direct import via the mobile app
- Provide lightweight reporting via search
- Support switching between months in the mobile app
- Provide a “Today View” widget for the mobile app
- Allow users to set up a budget account in the mobile app
- Improve the process of moving money between categories in the mobile app
- Provide an option to receive a notification when you’re leaving a known shopping location reminding you to log your transaction
- Allow users to view goals in the mobile app
- “Add Transaction” via force touch (on newer iPhones)
Why I Chose the “Today View” Widget
I chose to dive deeper on #6, a “Today View” widget for the mobile app. At first, it seemed like small potatoes, but upon closer examination I realized that it could help people engage with their budget (business goal #2) because it shortcuts having to open the app and wait for everything to load. It could also help them do more with their money (job #1) and reduce stress (job #2) since they’re more engaged and aware around the time of purchase.
While creating a budget is relatively easy, sticking to it requires you to keep your budget decisions top-of-mind and have the self-discipline to adjust your behavior when you catch yourself acting contrary to your plan (e.g. “I can’t buy those shoes yet because we don’t have enough saved — but soon!”).
If checking category balances requires unnecessary effort, people will do it less frequently, which means they’ll be less aware and more likely to overspend.
“[The food category] is really easy to go over budget in if you’re not careful.” — My mom, speaking from experience
Reducing the effort involved should result in people referencing their budgets more often, which equals more financial awareness and all of the awesomeness that comes along with it.
Ideas are always laden with assumptions — assumptions about the market, technical feasibility, customer behavior, etc. Some carry more risk than others and one of the biggest determiners of an idea’s success is how many of those risky assumptions prove to be true. This is one place where an extra level of rigor can pay massive dividends down the road.
We need to ask ourselves, “What are we assuming to be true in order for this idea to work?” This is actually a big part of budgeting. Let’s say that we want to buy a new car by next July. For that to happen we’re assuming we’ll have saved at least $9,000, which assumes that we’ll be able to set aside $750/month between now and then, which, in turn, assumes that I don’t lose my job—our sole source of income. If any of those assumptions prove to be false, we might not have the cash by next July. Not all of them, however, carry equal risk. The risk of me losing my job is quite a bit lower than the risk of us not having $750 available each month.
As with budgeting, so with software development. Acknowledging our assumptions up front is really healthy. It lets us handle risk in an intelligent way, before we make any major investments or put a lot on the line.
What are we assuming to be true in order for this idea to work?
Back to the “Today View” widget. Here are the things I was assuming to be true:
- People reference their budget categories when they’re out and about. High risk. If people don’t rely on the mobile app for this, providing a “Today View” widget only makes something that doesn’t need be done easier to do.
- People typically pin the budget categories that they need to reference most often. Low risk. If this isn’t typical behavior, it would be easy to instruct them in the widget (or app) itself. This assumption has to do with whether or not people use the “pin” feature, not its actual usability (which is a bigger risk).
- When referencing a particular category, the category’s current balance is the most important piece of information. Medium risk. If I’m wrong about this, the widget’s design would need modification, but the basic data should all be available so it wouldn’t necessarily undermine the usefulness of the feature.
- People feel more financially aware when they reference their budget categories in the same general timeframe as making a purchase. High risk. This is the real benefit to users when they have ready access to their top categories — financial awareness and peace. If I’m wrong about this, it wouldn’t necessarily discredit the feature, but it would indicate that we have an up-hill battle. My whole goal is to make budget information available closer to the point of purchase, and that only matters if people feel reassured when they reference it.
- People know how to “pin” budget categories in the app. High risk. If they’re unable to do this, or if it’s very difficult to do, my “Today View” widget won’t have any categories to show. I can offer instruction somehow, but that also adds effort.
- People often add transactions on their phone. High risk. If this isn’t the case, I’m simply making a seldom-used feature easier to access.
Four out of six of my assumptions were high risk. These were particularly important to test. In order to do this I needed to put them into a testable form, following Jeff Gothelf’s recommendation for forming hypotheses in his book, Lean UX.
We believe [this statement to be true]. We will know we’re right/wrong when we see [this signal or outcome], as measured by [these data].
I must admit, in the pre-release phase, I often struggle to come up with appropriate ways to judge whether a hypothesis is right or wrong. Generally, I’m very reliant on qualitative feedback, which gives me a decent sense of whether or not I’m on track. That’s the direction I took here.
Time to put my hypotheses to the test! I reached out to friends and family who use YNAB and asked them to fill out a brief screener before I chose whom to contact.
Three Experiments I Had In Mind
- User Interview : Discuss recent experiences using the YNAB mobile app with people who’ve indicated they use the app on a regular basis.
- Usability Test: Test initial concept for “Today View” widget with those who’ve indicated they use the YNAB mobile app.
- Usability Test: Test the “pin category” feature in the mobile app.
I started with experiment #1 (user interviews) and spent close to 2 hours on the phone with 4 members of my family. We discussed their experience with YNAB, particularly the mobile app, and their behavior when it came to checking categories and adding transactions. The last 3 questions were added during the 2nd or 3rd conversation, mostly prompted by some people’s comments comparing YNAB4 with the new version. I like to gather a little extra data when I can!
The Questions I Asked
- Which budget category do you spend out of the most frequently?
- Tell me about the last time you purchased something in [the budget category they mentioned].
- Did you reference your budget beforehand? If so, when did you reference it, how (what device), and what information were you looking for? Is that typically what you do?
- When did you log that transaction? Is that typically what you do?
- Why haven’t you switched to the new YNAB?
- Do you have any thoughts on the new version of YNAB?
- Do you keep receipts around?
The Biggest Things I Learned
- Some people use YNAB primarily (or even exclusively) on their mobile devices. Most of their frustrations stemmed from having to rely on the desktop app for basic features (e.g. direct import).
- For any given couple there is usually a primary spender, i.e. someone who does most of the regular spending on food, household goods, etc. This person is more aware of the balances in those categories. They may or may not even use the mobile app, though.
- Some expenses, like gas, are viewed more as a variable “bill” to be managed rather than as a discretionary expense. “You’ve gotta’ buy gas…”
- Some people look for categories where they’ve already overspent, along with the balance of the category they’re about to spend from. “I skimmed the columns to see if there were any other red items that I might have to be dealing with later just to see how far out of balance I am… Is [what I’m about to spend] money that I may need to reallocate?… I’m naturally looking at the colors.”
- When telling me about a recent transaction they made, 3 out of 4 people said they didn’t log it right away. They generally want to but in that particular instance they didn’t.
With my background as an artist, sketching comes very naturally. It’s the fastest and cheapest way for me to rapidly explore ideas and share them with others. This is essential because my first idea is rarely my best. I like how Julie Zhuo described this in her article, Building Products.
When exploring solutions for a particular problem, go broad before going deep. Brainstorm 10, 20, 50 solutions for the problem before getting into the mindset of picking a “winner”. The first 5 ideas will be the obvious ones. Creativity happens when you start to explore the 11th, 20th, or 50th idea.
I actually did these sketches before the phone interviews described above. In hindsight, I should probably have waited to sketch anything until I had talked with users. Their feedback did more to confirm my direction than contradict it, though, so it all worked out this time.
One thing I’ve found over the years presenting my design work is that it should be as self-explanatory as possible. It’s critical for team alignment. My developer colleagues love it when I can point to a working example, or when I share a coded prototype. I’ve seen business stakeholders finally start nodding their heads when they click around and see how something works, instead of just how it looks.
As much as I love sketching, I found that the sketches I produced (above) were very foreign to the device I was designing for — an iPhone. InVision to the rescue! I was able to add realistic animations and really bring the interactions to life.
My First Prototype (it’s interactive!)
(If you’re reading this on your phone, click here to view the first prototype.)
I used InVision to turn my sketches into a rough prototype, complete with animations!
My Second Prototype (it’s interactive!)
Next, I worked on the visual design, and spent some time reading Apple’s Human Interface Guidelines where they discuss how to properly lay out these widgets. It appears that a lot of designers go against Apple’s recommendations (e.g. removing most of the left padding), but I believe it’s wise to stick to convention unless there’s a good reason to depart from it.
I kept the styling minimal, reserving the punchy colors and fills for information that needed the most emphasis, namely the category balances.
(If you’re reading this on your phone, click here to view the second prototype.)
[ EMBEDDED CONTENT]
[I mocked up a few screens in Illustrator to explore the visual design] CAPTION
Where I Would Go From Here
For the sake of this case study, I’m assuming that there is sufficient business backing for this feature. If that were to be the case — and I’m nowhere near convinced that it would be — I would proceed to the second and third experiments listed above, and conduct some usability testing on this new interface as well as the “Pin Category” workflow in the existing app. Because the “Today View” widget depends on that feature, it’s important to test both.
Whew, you made it! High fives all around.
Check out more of my work, and, if you’re from YNAB, I’d sure love to hear from you!