How Google outsmarted their own UX

I just spent 40 minutes fiddling with google calendar trying to get it to realize that kc(a) => mail(a) after adding as a domain alias to within google apps.

I had added it as an alternative email to gmail and I figured that would do the trick, but no. All I got was an abyss of failed ux telling me that I was logged in with the wrong domain anytime I tried to accept a calendar event.

Anyone with >1 google account has seen this, no biggie. I then started looking inside calendar and plus settings for a place to add it as I did in gmail. Neither of these allowed me to add the email as an alias within the individual service.

Finally I backtracked to the google apps admin and realized that the google apps admin was smart enough to add an alias for mail(a) to my user profile within google apps. I tested it and I could accept invites to that email, so I figured I was getting closer.

People like me are probably some of the worst people to test your software because we are always trying to get into the head of the programmer who wrote it to figure out how to make it do stuff it can't do. I figured whomever wrote this must have just assumed that because I had mail(a) they could alias the same first name on the new domain and that would be all I needed.

In reality I always use one generic email in google apps that has everything catch all'd to it, but I really wanted to use a different name on the new domain for vanity sake. Anyway, we're on the right path… I think?

I click "add an alias" so I can add kc(a) - It opens up the ability to add anything *(a) but no ability to add something on the aliased domain.


Now I'm getting mad. Who wrote this thing anyway?

I decided to get a bit creative. What if I change my email address to kc(a)

WHOOOOOA. It worked. Google apps added kc(a) to my list of account aliases and now I can accept invites that are sent to that gmail alias.


This is a perfect example of what happens when you build a UX that tries to be too smart. The more you assume what the user wants, the greater the risk of getting further away from what the actually want.