A big piece is that companies are extremely siloed by default. It’s pretty easy for a team to improve things in their silo, it’s significantly harder to improve something that requires two teams, it’s nearly impossible to reach beyond that.
Uber is particularly siloed, they have a huge number of microservices with small teams, at least according to their engineering talks on youtube. Address validation is probably a separate service from anything related to maps, which in turn is separate from contacts.
Because of silos, companies have to make an extraordinary effort to actually end up with good UX. Apple was an example of these, where it was literally driven by the founder & CEO of the company. Tumblr was known for this as well. But from what I heard, Travis was more of a logistics person than a UX person, etc.
(I don’t think silos explain the bank validation issue)
(I don’t think silos explain the bank validation issue)
It might very well be that there’s no team responsible for IBAN validation at Amazon as the team that’s responsible for payment information might be an Amazon.com team that doesn’t care about IBAN’s which are only important for Amazon in Europe.
Also, they apparently did write code to validate it. And if most everyone puts in either a correct IBAN, or a correctly formatted but typoed wrong IBAN, it might be that no-one has ever complained to Amazon about having to wait for a server-side verification. There’s probably a low-priority bug ticket written by some tester sitting on their backlog, but without customer complaint or measurable loss of business it won’t get worked.
There are two levels of IBAN validation. One is to take the number and it should if you take modulo 97 result in 0. There’s also a more complex one that’s about querying a database about valid IBAN’s that multiple MB big. You can easily do the modulo 97 trick client-side for validation and then do the more complex one on your server.
Also, they apparently did write code to validate it. And if most everyone puts in either a correct IBAN, or a correctly formatted but typoed wrong IBAN, it might be that no-one has ever complained to Amazon about having to wait for a server-side verification.
I’m relatively certain (for non-public reasons) that this produces at least 100 customer complaints/year and there’s a good chance that it produces 1000s. But there’s no tracking.
If you type a 20 digit number and make a single mistake it’s unfun to submit a form and having to retype everything again.
It’s also not like this is the only thing that’s wrong with the IBAN page. It’s for example easier to type 20 digit numbers correctly when there’s a little space after every forth number.
There are also something less visible that’s wrong with the page that leads to problems that I don’t want to speak about here but in case anyone at Amazon reads this and wants to do something I’m happy to say it.
A big piece is that companies are extremely siloed by default. It’s pretty easy for a team to improve things in their silo, it’s significantly harder to improve something that requires two teams, it’s nearly impossible to reach beyond that.
Uber is particularly siloed, they have a huge number of microservices with small teams, at least according to their engineering talks on youtube. Address validation is probably a separate service from anything related to maps, which in turn is separate from contacts.
Because of silos, companies have to make an extraordinary effort to actually end up with good UX. Apple was an example of these, where it was literally driven by the founder & CEO of the company. Tumblr was known for this as well. But from what I heard, Travis was more of a logistics person than a UX person, etc.
(I don’t think silos explain the bank validation issue)
It might very well be that there’s no team responsible for IBAN validation at Amazon as the team that’s responsible for payment information might be an Amazon.com team that doesn’t care about IBAN’s which are only important for Amazon in Europe.
Also, they apparently did write code to validate it. And if most everyone puts in either a correct IBAN, or a correctly formatted but typoed wrong IBAN, it might be that no-one has ever complained to Amazon about having to wait for a server-side verification. There’s probably a low-priority bug ticket written by some tester sitting on their backlog, but without customer complaint or measurable loss of business it won’t get worked.
There are two levels of IBAN validation. One is to take the number and it should if you take modulo 97 result in 0. There’s also a more complex one that’s about querying a database about valid IBAN’s that multiple MB big. You can easily do the modulo 97 trick client-side for validation and then do the more complex one on your server.
I’m relatively certain (for non-public reasons) that this produces at least 100 customer complaints/year and there’s a good chance that it produces 1000s. But there’s no tracking.
If you type a 20 digit number and make a single mistake it’s unfun to submit a form and having to retype everything again.
It’s also not like this is the only thing that’s wrong with the IBAN page. It’s for example easier to type 20 digit numbers correctly when there’s a little space after every forth number.
There are also something less visible that’s wrong with the page that leads to problems that I don’t want to speak about here but in case anyone at Amazon reads this and wants to do something I’m happy to say it.