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.
Testing
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.
Accessibility
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.
Options
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.
-
Thank you for taking the time to give us a thoughtful explanation of the state of the colors and options changes.
-
Thanks! The classic colors are easier for me to see. :-)
-
Todd said:
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.
-
Patzer It can't mean that Income For next Month isn't coming back ever.
After all, users already have created half a dozen different workarounds to make it happen, so the system as is already supports it natively, just not with direct functionality. So they might as well build it into the system so that it overcomes the various drawbacks that each workaround method has.
Therefore, it should actually be a functional requirement to bring back Income For next Month to reduce the tedium and improve the experience for those using the workarounds.
QED.
-
Patzer You've got a lot there; I'm going to focus on just your first paragraph or two. Or really, just this phrase:
deliberately deferring income
I've used this phrase myself, and I like it much better then "Income for Next Month".
The latter was loaded with potential confusion for many users, and also felt like it lacked something as a binary option—what about two months? What about October? But the essence of it, the deliberately deferring income? It isn't as obvious as it was in YNAB 4, there's no doubt, and I'd like to see it be stronger. It was certainly a powerful moment for me as a user when I was first able to send a few dollars onward.
In calling this one example out and not addressing the other features you mention, I'm not implying we don't think about those or that they're less important. I just wanted to hit on one example. In everything, there are trade-offs, but that never means "not considering" the needs of certain users.
-
Todd FWIW, the workaround I use to budget a full month in one session does not recreate Income for Next Month. It's more of an ad hoc way to deliberately defer income and avoid Stealing from the Future. I don't move this month's income into next month for budgeting. I defer this month's income, then move a month's worth of budget into next month as TBB. I will typically have a dab of left over deferred income for the month after next.
The basic requirements of deferring income, as I see them, are to make a decision to reduce TBB in the current month and increase TBB in the desired future month, while not allowing the program to steal TBB from the future to meet current month budgeting desires. Right now, users do this with various workarounds that each have drawbacks. Some workarounds do not avoid SFTF. Others require user action at month rollover.
It would certainly be nice if the program had a way for me to say, right now, "Put $1000 of TBB from June into July, and leave it in July unless I do something explicit to change this decision. If I overbudget June, TBB should show as negative in June without affecting the $1000 of TBB in July." Ditto for August, September, etc., however far the user wishes to budget.
Alas, the program lacks this capability. I could create it with a workaround . . . except the workaround that wouldn't require user action at month rollover requires the use of a future committed transaction.
-
Patzer Along a similar line, I'd like the option to set up a true budget template. I want every month to automatically look the same at the beginning without having to input the numbers each time. I'm putting the same amount into nearly every category every month, and the few differences (slight fluctuations for electricity, phone bill, etc) are usually within just a couple of dollars.
12 of my 15 primary categories are literally the exact same dollar amount budgeted every month. When July 1 rolls around, it would be nice to have those pre-populated so that I can make adjustments if/when necessary instead of a forced micromanaging of things that are already set.
YNAB falls apart when it comes to future budgeting with the mediocre goal system and lack of automating the budget each month and then adjusting from there. -
Forest Green Lightning I use the quick budget option every month for all categories. Single click.
-
Forest Green Lightning
I'm using goals of Budget $X each month for that kind of template. Then I have 3 to 8 categories I need to reduce, freeing up funds for lower priorities. The down side is, the simple-minded goal nags want to yell at me for being under budget when in fact I deliberately trimmed those categories. Hence, coding CSS to turn the pills transparent and hide the nag icons. YNAB had no interest in coding a switch to let me turn off the nag icons, and had no interest in coding a switch to let me turn off the orange/tan pills entirely.
I do not expect YNAB to support a template the way I want one, which seems to be the same thing you want. Users have asked for such a template since the days of YNAB Pro, and it never made it into any new release of YNAB. Today we have a so-called template, but it doesn't really work like a template that would fill the budget cells and then stop nagging you to go get more money.
-
Forest Green Lightning et all: I haven't wanted to turn this thread into a discussion of multiple different features ... but templating (for lack of a better word) is another interesting example of where assumptions about what YNAB (the company) is interested in may be misplaced. So if there's a good existing thread on it, please point me there. 😉
-
Todd
Todd said:
templating (for lack of a better word) is another interesting example of where assumptions about what YNAB (the company) is interested in may be misplacedPerhaps YNAB (the company) is unaware of how the responses by official YNAB Support make the company look. Either the YNAB support personnel cannot understand well-reasoned arguments as to why features would be helpful, or they have been told to defend the status quo without ever admitting that the status quo has any weaknesses. After a year and a half of various discussions and seeing what changes YNAB (the company) actually makes to the program, "Please submit a Feature Request" sounds an awful lot like customer service code for "Sux2BU."
To be fair, Support is very, very good at explaining the official workarounds for the various bugs that have been deemed to be features. But Support is either woefully unprepared for (or forbidden from) engaging in productive conversation about how the software could be improved. YNAB (the company) would do well to consider making hanging out on the forum and engaging in such conversations part of the job for someone who is involved in program development decisions.
-
-
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.-
No problem, Ivory Sander , thanks for taking the time to read!
-
-
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.
-
Todd said:
[ 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.
