I doubt it was that simple. The UX flow changes if you can purchase as a guest.
More importantly, I expect when the system was built, the developers asked if all orders had a user, received the answer 'yes', and accordingly built that into the system.
Then one day some consultant comes along and pronounces that 'not all orders have a user now, please implement a guest checkout'.
So the developers probably needed to recode the whole flow, possibly remove some foreign key constraints, allowing a user to only partially exist (which needs to reconcile with a real user later if the email matches an existing user later).
And what if they don't create an account at that time, but they do later, should all orders to a given email then get attached to that account?
Are there privacy issues around this? Can we assume an email address belongs to an individual, I am not sure you can.
All this for a system that is processing millions of dollars in orders. So regression testing and deployment, would have to be done very carefully.
This is all just what I can think of off the top of my head.
So, with respect, you did not just change a fucking button.
It wasn't simple on the back-end. Your estimate of "man-weeks" is off by an order of magnitude, because of the back-end system complexity.
As the article states, it started with the button, which, as you quite rightly point out, dominoed into a lot of changes and thinking about edge cases that didn't exist before. The point I was trying to make was that it started with the button.
The big story here isn't that adding this particular button will yield $300m in revenue. The story was that, by watching users, we saw an opportunity to reap $300m. And we took it and it worked.
The original draft had more detail. As did the backstory piece we wrote. Editors cut it down for page count. (It was originally a foreword to a book on web form design, which was all about the buttons and the fields.)
Yes, good software should abstract the complexity away from the customer. That does not mean the complexity does not exist.
My post was motivated by the fact that the article is written as if this was a trivial change - "The designers fixed the problem simply" - and it really was not (for the developers).
"We took a simple idea and made $300million more dollars" - Yes.
"We did something simple and made $300million more dollars" - Not even nearly.
I mean, sure. But this is, like, a day of work + however much testing you want to do to make sure it works right. It clearly cost a lot less than 300 million dollars.
I'm sure it took much longer, but the "core" work here (in other words, what you'd need to do if this were just your project and you weren't too concerned about uptime) probably didn't take weeks.
I doubt it was that simple. The UX flow changes if you can purchase as a guest.
More importantly, I expect when the system was built, the developers asked if all orders had a user, received the answer 'yes', and accordingly built that into the system.
Then one day some consultant comes along and pronounces that 'not all orders have a user now, please implement a guest checkout'.
So the developers probably needed to recode the whole flow, possibly remove some foreign key constraints, allowing a user to only partially exist (which needs to reconcile with a real user later if the email matches an existing user later).
And what if they don't create an account at that time, but they do later, should all orders to a given email then get attached to that account?
Are there privacy issues around this? Can we assume an email address belongs to an individual, I am not sure you can.
All this for a system that is processing millions of dollars in orders. So regression testing and deployment, would have to be done very carefully.
This is all just what I can think of off the top of my head.
So, with respect, you did not just change a fucking button.