A few thoughts on colors and options
I wanted to drop in and offer a few thoughts on the recent changes with pill colors and, probably more to the point, on options and customizations in YNAB.
I’ve been a YNAB user since 2009. It’s changed. A lot. Every one of those changes, whether wildly successful or filled with challenges, has been a learning experience. The pill colors are no exception. Let’s talk about a couple of mistakes we made.
We test everything before we ship it, usually in multiple ways. And then, typically, we send changes and new features to only a few users at a time, ramping up slowly. More testing, more learning. This has sometimes led us to pull back changes before they see the light of day—briefly in some cases for small tweaks, sometimes to wait on more significant needs, sometimes to go back to the shop to become better ideas.
With the pill colors, on the other hand, we went out of character. We tested the changes against a set of web standards, but our live user testing wasn’t nearly robust enough. And then we set it live—for everyone. This includes lots of users who love the change—and many, too, for whom it wasn’t helpful.
There’s not much more to say about that. We may have misjudged the colors, but that happens—the real mistake was not testing that judgment.
The pill color change was intended as a first step towards improving accessibility of this key feature, not a comprehensive solution. But, in retrospect, we weren’t clear enough about the narrow purpose of the change (including internally, which led to mixed messages we regret), and that added to a sense of confusion or disappointment with the change. And, of course, we certainly didn’t want to make readability worse for anyone, but that’s exactly what happened for some users.
We’ve taken other steps in the last year that we’re proud of, including adding icons to the pills to differentiate more readily between the signal colors. We’ve begun making our content more accessible, beginning with transcripts for our Debt Stories Podcasts. We’re very excited about recent changes to our site illustrations that reflect the diversity of our users and our world.
But there’s more work to do. We love having color in our apps, but we can’t rely only on color to send a signal. (I’m looking at you, Flags!). We also have work to do around type sizes in many places, the mobile apps in particular, and communicating more information through visuals as well as text.
As you probably know, one action we’ve taken to resolve the pill color issue is to provide the option to use the classic colors. They’re still not compliant with accessibility standards, but we’re happy to provide that option if it is a user’s preference.
So let’s talk options. YNAB basically doesn’t have many of them, and never really has. I’ve been known to make a joke or two about the item in My Accounts that says Options, and how the “s” wasn’t completely true, because there was only one.
Does this introduction of an option for pill colors change things? Does this mean we’re headed in a different direction? If I say “yes and no” will you accuse me of hedging? 😉
On the yes side, we’ve actually been talking quite a bit in the last six months or so about how YNAB and YNAB users could benefit from more opportunities for customization and ownership. The pill-color option we just released was made possible because we have already been deep into work that would set the stage for theming in your budget, as one example. There’s an active question from this morning about setting Monday as the first day of the week—it’s a great question.
But what about options that aren’t just changing a calendar or a color, but impact more core functionality?
It starts to get complicated here, and it’s where we've always been cautious. One reason to be wary of options is that they slow down development. Every time you create a fork in the road (this setting or that setting?) you introduce more opportunities for bugs, for design trade-offs, or just taking longer to engineer something. And those concerns aren’t internal ones—this impacts every user, perhaps most significantly because every option that exists on the current app creates potential delays on producing future improvements. This is particularly true if a potential option, overspending handling for example, impacts underlying calculations.
Of course, options that impact functionality can also impact how users implement the method—and it’s the method that changes people’s lives. So we’re cautious there, too.
That’s neither a yes nor a no. It’s just background, and it’s a conversation we’re always having—we don’t know what it will mean tangibly. But we’re excited, for right now, for you to have one more option than before.
Of course, options that impact functionality can also impact how users implement the method—and it’s the method that changes people’s lives.
Thank you for the thoughtful response. I interpret the snippet I've quoted to mean, "Income for Next Month is not coming back, and there will be no implementation of any form of program support for deliberately deferring income in order to budget a complete month in one budgeting session."
The reason I interpret the quote this way is that I have come to see the new YNAB methodology as being fundamentally tied to budgeting every time income is received. That would be 4 unequal chunks of money, in my case. And while that is very appropriate for someone who is just starting to budget and does not have a full month of liquidity, it's very limiting for someone who has been using YNAB since 2008 and came to rely on budgeting a full month in one session for clarity of prioritization. My underlying gripe is not with the program, but with the changed methodology. "Live on Last Month's Income" is no longer part of the methodology. It has been replaced with the ill-defined and non-actionable "Age Your Money," which is at best irrelevant and at worst mildly harmful for a user who is no longer living paycheck to paycheck.
Certainly the fluid months and budgeting every time income is received fixes the problem of YNAB 4 new users not being able to manage Income for Next Month on the budget page. I happen to believe a better fix would have been to make Income for Next Month a budget page operation in addition to a transaction operation; let the user *budget* income to be deferred, that cannot then be dragged back from future months without a conscious decision by the user to do so. Apparently the YNAB organization did not think of this when developing the new YNAB, and either did not consider the needs of people who are a month ahead or did not regard people who are a month ahead as being a big enough chunk of the market to matter.
That having been said, I see no reason why there should be no running balances, no ability to change multiple flags in one operation, and several other features that are standard in Toolkit. YNAB ought to be looking at what Toolkit does, and taking clues about what their users need. When a substantial number of newbie questions of the form, "How do I do X" are answered by, "Get the third party Toolkit," YNAB has a real problem understanding an meeting customer needs.
For my own budget, the biggest pain point remains the fact that future committed transactions are forbidden. Today I got an email from my broker indicating that a routine bill has been sent out. It is due 3 days from now, and will be dated 3 days from now in my register, but it goes out early because this bill requires a paper check. So YNAB stubbornly insists that this is a scheduled transaction that will need to be approved, when I know the precise amount and can no longer do anything to change it.
Yes, I get the idea that future transactions are forbidden because you're trying to force users to comply with the methodology. It doesn't work. Users that want to create fictitious income to budget will still do that, and you have made it harder to manage a budget conservatively when I schedule bill payments for future dates. I require mulitiple workarounds to keep track of this, and still only get about 80% of the clarity I would get from having my future committed transactions be real register transactions instead of scheduled transactions. I will lose even that 80% of the clarity in the event that the volunteer Toolkit developers burn out and stop keeping up with changes to YNAB.
The YNAB method did indeed change my life. But that was the YNAB method as of 2008 to 2012. There was a lot of good stuff in the former method, and some of the very best stuff has been thrown away.
Thank you for coming here to the forum and explaining the process behind the decisions. I'm one of the "classic" color users who disliked the first iteration of the new default colors. The new default colors look better, however, classic colors are still the best for my color-blind eyes. :-D
I'm open/available to help with UX testing for future changes.
Thanks for actually sharing some thoughts behind the decision making process. While I can't say I agree with everything at least there is a clear feedback from ynab. IMO this is the problem with the current feature request system, there is no feedback from ynab to us to close the loop and explain what is or is not coming and why.
As far as the income for next month, or whatever you want to call it, to say why does it have to only be for this month or next is a fair question. On the one hand I feel in most cases the funds will be budgeting now when they are received (into any month) or if the user wants to defer it for any reason most cases it would likely only be til the next month. The reason why I would use this is I earn highly variable income on average 7 times a month! That's a lot of tedium to budget 7 times a month....enough to make anyone go crazy I think. My use for income for next month would be to hold off until I have all my monthly income recorded then budget it all together is one large chunk, without having it just hanging out in tbb for weeks on end (i don't know that my OCD would let me do that if i tried).
So there it is. Maybe income as next month could make an appearance in a future update as income for x month. Where you can choose a specific month to defer it to. Could also end up being a fix for SFTF? If deferred funds weren't stolen from only shall we say soft-future budgeted funds?
As far as future transactions, maybe the best fix is a flag we can set when we make the future transaction that dictates whether or not it affects the budget now or not.
Maybe you could even hide this behind an advanced mose that had to be enable from the my account settings to protect newer users from confusion or worse. Actually I see that as the best way to deal with features you don't want to compliment solely because it's can be confusing or even dangerous for new users who don't know what is all going on yet.
Finally some feedback on your release notes...you mentioned you were able to provide the option to revert the pill colors because of a theming system you have been working on. Perhaps it will help to show that's there is more going on in these releases than just bug fixes by including somewhere some bigger projects and maybe even with milestone indicators that can show us some progress before anything actually is functional and ready to use because as of now i noticed the release notes seem mostly littered with fixed x bug. Or something really small like changed size of this column on the budgeting screen.
Also I have a new theory....you really only added the option for classic colors so you wouldn't have to remove the s or bother your OCD that is was really only 1 option any longer didn't you?
Just some thoughts.
[ Income for Next Month] was loaded with potential confusion for many users, and also felt like it lacked something as a binary option—what about two months?
Because just getting to next month is all that is needed to decouple the budgeting cycle from the actual income arrival cycle. Properly implemented, one could still budget that deferred income to any month thereafter. What is important -- and extremely powerful -- is getting away from budgeting piece-meal as income sporadically arrives throughout the month. True Expenses make far more sense, since one is budgeting on the same basis as those expenses.
The big-picture view when working with month-sized chunks is far superior. I make better allocations when they are strictly based on my priorities rather than priority AND arrival time.
Automatically deferring further than next month is typically counter productive due to the greater uncertainty and more numbers to change when things invariably change (bills increase, priorities/timelines change, etc.). However, the forward-flow would allow such users to do so if they wished.