A while back I tried signing up for Noom (a weight loss / behavior change app with a massive marketing engine behind it) and they ask a million questions trying to give an impression of “we’re learning all these things about you so the AI can customize the crap out of your weight loss plan”.
I’m obviously cynical (just mildly!) in the case of Noom but it drives home a realization I’ve gradually come to about Beeminder. We used to think we needed to ruthlessly remove friction in the goal creation UI. At one point we even let you start creating a goal before you’d signed up. That was a terrible idea. I now, weirdly, believe that friction in goal creation is almost a good thing. Adding questions and settings and whatnot to goal creation helps users learn more about how Beeminder works and it creates a feeling of investment in the goal they’re creating. Obviously we don’t want to add gratuitous friction (as I cynically suspect Noom is doing) but, for example, any setting we think you ought to think about (like the deadline, perhaps) when you’re creating a goal, we shouldn’t hesitate to add it as a step in creating a goal.
Maybe also more handholding for newbees about things like chunky time / baby got bonus since that’s an extremely common point of confusion (including just today).
Another example of friction I’d like to add is having the user not only choose their goal units but choose how to abbreviate them and pluralize them (it sounds dumb I know, but I’ve got something spec’d out that I think will actually be nice!) so Beeminder can tell you things like “-.1kg needed by midnight” in a more useful way. (Related improvements along those lines are currently in the works, btw; codename: safesum.) That process should also help educate users about the concept of a metric to be minded. Obvious things for us but it’s surprising how many people do things like trying to put their goal value in the rate field or whatever. Slowing everything down, asking for one thing at a time and explaining it all along the way could help. I think we can even do that in a way that adds value for power users and doesn’t meaningfully slow them down either.
Trivia from the person who collects feedback: not understanding weekly/monthly rates is currently our #1 biggest cause of friction in general! It causes people to quit and delete goals at pretty high levels compared to everything else, and adding some hand-holding for it is probably the easiest way to act on of the things that cause multiple people to quit Beeminder (others being “make the graph more intuitive”, “why the heck can’t I have recurring tasks from Todoist” and “I don’t know how to turn it off”).
More than trivia, this looks to me like extremely important, actionable metrics that might be worth tracking over time to see how changes to the UI affect users. Maybe even going back in time with support requests to get historical data might be worth it.
That would be why I collect the feedback, yeah. We have IIRC a year of data at this point, so for example I know that the issues with PPRs have slowed significantly since some tweaks were made ensuring they’re shown on graphs. (@dreev wins this one, having insisted those tweaks would help, and I didn’t believe him.)
Tee-hee, and high-fives on the teamwork there, @shanaqui! <3 So what’s the most immediate thing we can do to mitigate this “weekly/monthly rates are technically daily rates” confusion? Need @mary in here for this too, who is thinking about less immediate, more fundamental answers to that.
I just had an idea in the meantime: if you choose, say, 3 per week as your rate then the initial safety buffer should default to ceiling(7/3). That made it sound complicated but I just mean we should encourage people to start with enough safety buffer that they can procrastinate as much as they expect to be able to procrastinate given their weekly rate. Like if I say “1 per week” I expect to be able to do nothing for the first week. If I say “2 per week” I expect to be able to go 3.5 days, etc.
Simpler still: If you pick “per week” then your initial safety buffer is 1 week. If you pick “per month” then your graph will be flat for the first 30 days. No choices. We gray out the “start this goal with extra leeway” section with a note saying to convert the rate to daily if you want to customize it.
That might be the best compromise because if a user knows enough about beeminder to fully understand the implications of a per-non-day goal, they should be able to trivially set it up as a per-day goal instead. Conversely, if a person does not understand the implication, I also think they’re more likely to select per week/per month/per year and get confused.
And fundamentally there’s something weird with setting it up as “3 frobnodules per week” when beeminder actually knows nothing about weeks and actually just “thinks” in days.
Anecdotally, I feel enough vague weirdness from the concept itself than I never made, say, a 6 per week goal. I just have 0.8 per day, which seems simpler to me.
If it was my choice? I’d kill the feature entirely. Maybe depending on how much friction it causes calculated as a proportion of non-daily goals support request to users configurating their first non-daily goals… but I’d lean toward killing the feature.
One thing that will help is the tutorial I’m [meant to be] doing (if struggling with*), of course. Then, yep, I actually really like your “simpler still” option. The people who get weirded out by weekly/monthly rates are usually not ready to look under the hood and figure out a lot of options for themselves, and like I said it’s a really high attrition point, well overtaking PPRs (which used to top the list).
*The issue is that I’m not very good at splicing things together/making graphics/etc. I originally intended to record it in slices so anything that gets outdated can be more easily yoinked out and just replaced in segments, but I think that’s making it more complicated and I should actually record straight through and stop trying to have skills I don’t have. I think we can conclude I’m not gonna make a high-gloss shiny tutorial, but just doing a video showing what I do should be easy.
I suspect that this would result in a lot of complaints from people who just haven’t caught on that 0.5 means “one every other day”. It’s obvious to us that we can have a non-integer in that field, because we understand how it works. I am painfully sure though that a lot of people would be writing in saying how stupid it is that you can only do things every day and why can’t we do weekly/monthly rates.
Another solution would be to actually have weekly/monthly graphs with weeks/months on the x-axis instead of days, so the graph would go up in increments of weeks/months. That’s what people actually seem to expect. But I suspect then they’d want to know why they can’t see what day they did the things…
My two cents: because I use weekends off on almost everything, I also use a daily rate on almost everything, so if Beeminder killed weekly and monthly rates I wouldn’t miss them.
What if rates were configured using two fields? “I commit to [ n ] units every [ x ] days.” Would that make things more or less confusing for new users?
I know at times I’ve thought that approach would make things a bit more user friendly for me, since I wouldn’t feel compelled to pull out a calculator to determine the correct daily rate. (In the back of my head I know Beeminder would probably let me put a ratio into the rate field, but I never feel adventurous enough to try it.)
I actually tried that the other day and was surprised to find out it doesn’t work, like it otherwise does in other fields (as told to me by someone on the forum previously in the Big Rational Datatype Debate).
Hey, I am serious beeminding since Aug/19 (I used the service before but did not like it, so I did not stick around until last year when I decided to give it another chance).
Please, do not kill the weekly feature, coming from someone that has no Math background except for high school, I cannot think about rates like 0.8 a day, I would actually need to have a calculator next to me, and if I need a calculator to use a website or app I will simply not use it. That becomes ridiculous complicated when I think about my currently workout rate, which is 2.5 a week (I want to work out 3x a week but I like leaving some leeway for things like getting a cold) , that would be a daily rate of 0.3571428571428571 (seriously? even if I round that up, 0.36 a day is ridiculously complicated).
I think that all my goals have a weekly rate right now, and I have around 25 goals. It is much simpler for me to think in term of what I want to do during a week than daily fractions.
That said, I have deleted several goals in the first week because of the weird daily rate of beeminder. Usually, I go too fast through the creation page, I forget to set the buffer to 7 days, realize that when I am on a beemergency, delete the goal and then I have to start the creation of the goal all over. It is annoying, just not annoying enough to get me to stop using beeminder, but I can see how that could get people to quit using beeminder all together.
I think an easy solution would be to default the buffer days in the creation goal to 7 when the person choose a weekly rate, like @dreev sugested, but keep the option to change when people want to start working on the goal right away.
The whole click to choose the extra safety buffer is complicated, because it is really easy to skip it and the wording is very complicated (extra leeway, safety buffer - it took me a couple weeks to start understanding the lingo). Removing that completely and simply keeping the box with the amount of days to chose would be simpler (the wording on the box makes much more sense to me), and defaulting to 7 would help when I go too fast through it.
Don’t worry, my terrible idea was (rightly so) shut down right away by the people actually working on beeminder (they’re the ones with the bee next to their avatar).
This came up today when talking about setting up our Beeminder goals for our workerbees book club. Adam and I both accidentally created do-more goals and blithely started adding odometer-style data to them. Nikki said they’ve often done the same thing for beeminding online learning where the metric is percent-completed. Here was my response to finding out I wasn’t the only one to screw that up:
Ok, I feel better now. I think it’s definitely a lesson for Beeminder’s design. In fact, I bet it’s another datapoint in favor of the “more goal creation friction is good” thesis (Opinion: Goal Creation Friction Is Good).
Anyway, […] I’m back on track with an actual odometer goal. Have to read to page 40 today!
PS: I just re-read my “goal creation friction good” treatise and am nodding along so hard. Like an evening deadline might make sense for this reading goal but it didn’t occur to me when I created it to deviate from my default 5pm deadline. The friction of remembering to go into settings actually feels mildly daunting or ugh-y or something – something I have to hold in a mental to-do list. The friction of a separate screen when I’m creating a goal asking me about things like deadline time feels … reassuring or relaxing or something. Like I feel like my hand’s being held and Beeminder’s making sure my goal is created correctly.
I don’t think I want to classify it as friction, because I don’t think it’s the friction itself that’s the good part–bit rather adding the “good part” would increase the friction. (I guess if you compared really small aircraft to larger aircraft, you could say “more weight is safer” even though it isn’t the weight that’s making it safer…)
I really want to try out a longer, more involved goal creation wizard.
Some great discussion with @adamwolf on this today:
First of all, he’s totally right that “friction is good” is a little … off. The airplane analogy is perfect. What I really mean is that making the tradeoff of more friction in order to get more clarity for the user, etc, is the right tradeoff. We’ve gotten this so wrong in the past – getting the goal created as quickly as possible and letting the user go spelunking in Settings afterwards – that I’ve been using “friction is good” as shorthand for making the opposite tradeoff.
But I maybe almost mean it. A little bit? Slowing things down, asking the user plenty of questions, educating them along the way, getting them invested in the goal they’re creating, even adding a bit of gravitas, are all . Not exactly friction for friction’s sake but just really not minding it much.
ADAM: I really want to try a heavyweight goal creation wizard, where you write a few sentences about what your goal is, what the actual actions are going to be, how you can prove you’ve done them, why you want to do it, how you know you’re done…
DREEV: no idea if i’d like it that extreme but i love it as a thought experiment if not an actual experiment. in any case, that’s exactly the kind of thing i mean by “more friction in goal creation”
ADAM: Call it the success wizard and do some differential comparisons between people using it and people using regular goal creation
We have IIRC a year of data at this point, so for example I know that the issues with PPRs have slowed significantly since some tweaks were made ensuring they’re shown on graphs. (
I think it’s definitely a lesson for Beeminder’s design. In fact, I bet it’s another datapoint in favor of the “more goal creation friction is good” thesis (
– that I’ve been using “friction is good” as shorthand for making the opposite tradeoff.
. Not exactly friction for friction’s sake but just really not minding it much.
no idea if i’d like it that extreme but i love it as a thought experiment if not an actual experiment. in any case, that’s exactly the kind of thing i mean by “more friction in goal creation”