Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing stuff is never obvious yet often better

gkogan.co

Post reply on HN
Print view View original

91–100 of 196 posts

Re: Removing stuff is never obvious yet often better

#91

Post by Glawen »

serial_dev wrote: post #83
refibrillator wrote: post #53

Upvoted to spread the immense wisdom in this post. But golly I must say the line can get blurry quickly. > Would anything of value be lost if this or that chunk of it was removed? In early stage projects I’ve seen this mentality backfire occasionally because it’s tough to estimate future value, especially for code and data. For example, one time in a greenfield project I created the initial SQL schema which had some…

Well, in your case it wasn't clear cut, but YAGNI is still a good default approach, I'd suspect maybe even in your case. First of all, it wasn't guaranteed that this feature of yours would come. Even in this case, the feature came, you could probably add it with not too much effort, sure maybe a bit more than otherwise, but on a large project it's hard to guess the future. What if someone else would have taken that t…

how about writing it down instead of relying in tribal knowledge?

Re: Removing stuff is never obvious yet often better

#92

Post by TeMPOraL »

blackoil wrote: post #68
shubhamjain wrote: post #60

Earlier quoted context omitted.

The problem is that it's easy to prove that signups are increasing, and lot harder to prove that there was a measurable increase in number of paying users. Most A/B tests focus on the former, very few on the latter. We had a free plan, and most users who signed up never made a single API request. So, assuming that the increase in signups is driving more business is just foolhardy.

You can always track signup/paying-users ratio. Purpose of landing/pricing page is to get the users to sign-up. Unless some dark pattern or misinformation is used to confuse users into sign-up, more users is a positive thing.

The problem with A/B test optimization is that, unless you're extremely careful, they naturally lead you to apply dark patterns and misinformation.

Re: Removing stuff is never obvious yet often better

#93

Post by lelanthran »

kmoser wrote: post #7
jclulow wrote: post #2

Perhaps removing a pricing scheme so complicated that it literally can't be modelled usefully by the customer would be even better?

The article states that the biggest factor was user misunderstanding of the options, not so much the number of different options. In other words, if they offer option A at $x and option B at 10*$x, if most users mistakenly think they need option B, the calculator is misleading. Also, I'm a big fan of "contact us for pricing." It's annoying for users who are window-shopping and want a quickie ballpark, but it helps yo…

>> Perhaps removing a pricing scheme so complicated that it literally can't be modelled usefully by the customer would be even better?

> The article states that the biggest factor was user misunderstanding of the options, not so much the number of different options.

(Emphasis mine)

It seems to me that you are in agreement with the GP :-/

When a significant portion of the target userbase cannot understand something presented by the software, the problem is rarely the users.

More developers should read Donald E. Norman's "The Design of Everyday Things"; even if you forget specifics in that book, the general takeaway is that the default position must be "It is not the users' fault!".

There must be significant evidence that the user is to blame before the user actually is blamed. The more users' that have that problem, the larger the body of evidence required to prove that this is a user problem.

More than 10% of target users have problem $FOO? Then you better have a mountain of rock-solid, beyond a shadow of a doubt evidence that the software/interface is correct!

Re: Removing stuff is never obvious yet often better

#94

Post by n4r9 »

lucianbr wrote: post #88
QuantumGood wrote: post #82

Earlier quoted context omitted.

At one time Musk stated that SpaceX data suggested that needing to add back 15% of what was removed was a useful target. He suggested that some of the biggest problems came from failure to keep requirments simple enough due to smart people adding requirements, because they offered the most credible and seemingly well-reasoned bad ideas.

How would you measure / calculate something like that? Seems like adding some amount back is the right situation, and not too much either, but putting a number on it is just arrogance.

Yeah, not sure how you'd measure this apart from asking people to tag feature re-adds. And all that will happen is that people will decide that something is actually a new feature rather than a re-add because the threshold has already been hit this quarter. Literally adding work for no benefit.

Re: Removing stuff is never obvious yet often better

#95

Post by SushiHippie »

refibrillator wrote: post #53

Upvoted to spread the immense wisdom in this post. But golly I must say the line can get blurry quickly. > Would anything of value be lost if this or that chunk of it was removed? In early stage projects I’ve seen this mentality backfire occasionally because it’s tough to estimate future value, especially for code and data. For example, one time in a greenfield project I created the initial SQL schema which had some…

Wouldn't using a VCS help in this case? So you could go back in time before this column was removed, and copy paste the code you already wrote and maybe change some things (as likely some things have changed since you wrote the code the first time)

Re: Removing stuff is never obvious yet often better

#96

Post by Jensson »

lucianbr wrote: post #88
QuantumGood wrote: post #82

Earlier quoted context omitted.

At one time Musk stated that SpaceX data suggested that needing to add back 15% of what was removed was a useful target. He suggested that some of the biggest problems came from failure to keep requirments simple enough due to smart people adding requirements, because they offered the most credible and seemingly well-reasoned bad ideas.

How would you measure / calculate something like that? Seems like adding some amount back is the right situation, and not too much either, but putting a number on it is just arrogance.

> How would you measure / calculate something like that?

SpaceX probably has stricter processes than your average IT shop, then it isn't hard to calculate stats like that. Then when you have the number, you tune it until you are happy, and now that number is your target. They arrived at 15%. This process is no different than test coverage numbers etc, its just a useful tool not arrogance.

Re: Removing stuff is never obvious yet often better

#97

Post by worldsayshi »

TeMPOraL wrote: post #84
mquander wrote: post #22

I don't know if this calculator was good or bad, but the rationale sounds superficially ridiculous. > Visitors who didn't see the calculator were 16% more likely to sign up and 90% more likely to contact us than those who saw it. There was no increase in support tickets about pricing, which suggests users are overall less confused and happier. Of course if you hide the fact that your product might cost a lot of money…

This is a blind spot for pretty much entire industry, and arguably spreads beyond tech, into industrial design and product engineering in general. Of course being transparent with your users is going to be more confusing - the baseline everyone's measuring against is treating users like dumb cattle that can be nudged to slaughter. Against this standard, any feature that treats the user as a thinking person is going t…

> treating users like dumb cattle that can be nudged

Essentially the failure is that we do treat users like this by relying on mass collection of data instead of personal stories. To be human is to communicate face to face with words and emotions. That's how you can get the nuanced conclusions. Data is important but it's far from the whole story.

Re: Removing stuff is never obvious yet often better

#99

Post by quectophoton »

raylad wrote: post #48

I experienced something similar. We had a website with several products that seemed fairly similar, so we were concerned that people might have trouble deciding which one to get, and not buy as a result. So we made a product advisor applet where the user would answer a few questions and it would suggest one or two products that would be best for them. Getting the applet right took a bit of work, but once it was done…

So maybe your advisor applet actually helped people, they were not buying just because it was the best choice for them given all the additional information you were now giving them?

> I still don't know why it hurt conversions, but it did.

Maybe people were indecisive and you just saved them trouble of trying stuff to find out for themselves.

If it was a service, then maybe they were signing up just to try because they weren't sure, and then taking advantage of sunk cost fallacy by pulling out an Amazon Prime strategy. Or, maybe without the advisor applet they might sign up thinking they can get away with the cheapest version (e.g. like people who purchase 3-5 EUR/month VPS), but with the applet you deny those hopes right away.

If it was physical products, then you might have helped them out of a bad purchase.

> So we moved it from the homepage to a FAQ section of the site, and hardly anyone ever used it at all.

Yeah I wouldn't expect to find it there. In the footer, maybe. But not in the F.A.Q., so there's that.

Post reply on HN