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

101–110 of 196 posts

Re: Removing stuff is never obvious yet often better

#101

Post by serial_dev »

Glawen wrote: post #91
serial_dev wrote: post #83

Earlier quoted context omitted.

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?

Writing what down? A bullet list of 30 items that "we added something that currently doesn't do anything or not used, but in case two years down the road, you need something, it might be close to what you need, so don't delete any of these unused items"? YAGNI is much simpler.

Re: Removing stuff is never obvious yet often better

#102

Post by julienreszka »

Dubious claims with really terrible arguments.

Simply removing a feature without addressing the root cause of confusion will lead to other problems down the line, such as increased customer support demands or user dissatisfaction when actual costs differ from expectations.

Re: Removing stuff is never obvious yet often better

#103

Post by IshKebab »

SushiHippie wrote: post #95
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)

No because you still have to deal with the DB migration. Which tbf should be fairly easy since it's just adding empty columns.

Re: Removing stuff is never obvious yet often better

#104

Post by atoav »

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…

There are multiple companies on my blacklist that definitely got me to sign up. But as there was a hook that anybody acting as a trustworthy partner would have mentioned, I parted with them — potentially for life. You know, things like "click here to sign up, sacrifice your newborn on a fullmoon night while reciting the last 3 digits of pi to cancel"

I don't particular care whether their A/B test captures that potential aspect of customer (dis)satisfaction, but I am not sure how it would.

Re: Removing stuff is never obvious yet often better

#105

Post by carlmr »

strken wrote: post #69
bruce511 wrote: post #54

Earlier quoted context omitted.

>> Of course, the pricing page became plain ugly, but that didn't matter, because "Signups are increasing!!" I'm not sure I'm following you here, so perhaps you'd care to elaborate? The GP critique was that it was perhaps just creating a problem elsewhere later on. I'm not seeing the similarity to your case where the change is cosmetic not functional. The issue of whitespace (padding) is subjective (see the conversat…

I think one problem is that a better design would move the button above the fold without ruining the spacing, and therefore achieve a better result with even higher lift, but someone focused on just the numbers wouldn't understand this. The fact that the A/B test has a big green number next to it doesn't mean you should stop iterating after one improvement.

It still seems like a valid use-case for AB testing. Ideally, you should maybe redo the design, something you could AB test if it helps.

My guess is yes, because consistency in design usually makes people assume better quality.

Re: Removing stuff is never obvious yet often better

#106

Post by shdon »

roenxi wrote: post #17

> In an internal poll, 7 of every 10 people in the company thought the version with the calculator would do better. An interesting and pretty classic dynamic - I liked the article overall but I think this point didn't get the highlighting it deserved. If 30% of the people involved think that the calculator is a bad idea that signals a potentially huge problem even if the majority think it is fine. Be alert to the pol…

The article just says those 30% of people weren't convinced the version with the calculator "would do better", not that it "is a bad idea". Granted, they might have thought that, but it seems quite a leap. They could just have easily thought it would make no difference, or assumed the version with calculator was underperforming because of the cases where it gave the wrong answer.

Re: Removing stuff is never obvious yet often better

#108

Post by scotty79 »

> The calculator also gave users a false sense of confidence, which meant they were unlikely to double-check the estimate by reading the docs, contacting the team, or trying it for themselves.

How dare they think that a thing called calculator is accurate and not double check!

Re: Removing stuff is never obvious yet often better

#109

Post by carlosjobim »

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…

I would never entertain any "contact us for pricing" offer. It means that they are looking to rip you off. If you can't give a fixed price for bespoke solutions, you should still publish prices for standard solutions, so that customers can get an idea of your rates. Then they will contact you for bespoke solutions.

Re: Removing stuff is never obvious yet often better

#110

Post by BoredPositron »

carlmr wrote: post #105
strken wrote: post #69

Earlier quoted context omitted.

I think one problem is that a better design would move the button above the fold without ruining the spacing, and therefore achieve a better result with even higher lift, but someone focused on just the numbers wouldn't understand this. The fact that the A/B test has a big green number next to it doesn't mean you should stop iterating after one improvement.

It still seems like a valid use-case for AB testing. Ideally, you should maybe redo the design, something you could AB test if it helps. My guess is yes, because consistency in design usually makes people assume better quality.

A/B tests suck because you are testing against two cases which are probably not the best case. If you take your learnings of the A/B test and iterate your design that's a viable strategy but proposing a shit design and insisting on deploying is wrong.
Post reply on HN