WWGD

WWGD (What Would Google Do?)

I love Google's UX. Yes, love is a strong word, but as far as one can love the manifestation of a technology, the word may well apply. 

When I'm on a Google site I know where stuff is. I know how things work. I know what is going on. When I build a Web site or an app, I always try to start out with a Google minimalist feel (but rarely finish that way). For me, it's the perfect application experience, Web or otherwise. 

I think I finally understand why. 

Events leading to my epiphany

I've never been a UI guy. It's unimportant to me. It is simply a means to an end. HTML, Win32 client, mobile app, command line. I simply don't care. My application architecture and implementation won't be changed by the UI because the UI exists as little more than a window in to the world that is the logic, the stuff that interprets your data, applies algorithms, serves you with information. The details of the UI are irrelevant as long as the user can interact with the code. I'll even take it further. For me, the magic has always been in the code and the UI is a necessary obstacle in reaching the code. 

UX is to be built along with the code, or so they say

I came in to a manager's meeting the other day. We were talking about some of the previous sprint's issues, and one of my big issues was the way my team was dealing with the UI. The short version is as follows:

My team was coding and testing to the UI as if it was a contract. They didn't question the things that didn't make sense, they tried to write unnecessary and complicated code to conform to the display. These, in large part, caused us to fail to meet our sprint's obligations. Another manager commented, "yeah, we need to figure out how to get the UX guys to create markup while we code." 

My response? Nah, I don't care if they create the UI before hand and deliver it, we just need it to be ready, and I need my team to push back when it doesn't make sense.

The room responded with horror. No, I'm not kidding. HORROR. Two of the other managers looked at me as if I'd just punched a newborn baby in the face for pooping a diaper kind of horror, and a third actually became angry. How could I say such a thing? Allow the designers to design stuff before the sprint? OH, THE HUMANITY!!! I'm sure there are more than a few agile tech people reading this that are feeling much the same response. They could not understand that my issue was my team's failure to question questionable design, and not the fact that the design was created before the code. I gave in, I agreed to say I was wrong, and left the conversation a little confused. Who cares if the UI exists first? It's not a contract, it's a guideline, and as such, it exists for the purpose of being changed as needed. I always approach UX this way, and let the designers know after the fact how things needed to be changed in order to meet the product goals. 

These reports are useless noise...

The following day I went in to a reporting review. Our ops team is putting together some reports and alerts for the product, and we periodically review the work, the dashboards, the info. I've finally given up complaining that the red and green indicator circles are pretty damn useless because they insist that they have no control over the colors or how they're displayed. What ever. I'll ignore them because to me, Mr. RedGreenColorblind, they're all a similar shade of orange. 

Anyway, we came to a new report page. The page contained several graphs, each containing around 15 to 20 metrics, which (at least to me) were displayed in slightly varying shades of two colors: blue and not blue. The other people in the room insist the meaning is clear, I think they may be messing with me. These graphs are used for clarifying a list of error messages from different systems. Some of the error messages are very similar, such as variations on the phrase "Credit card rejected. Please request a different number." Some of the variations are based on word order, some are based on language (for example Spanish versions), and the list goes on. The colored graphs are supposed to provide clarifying queues to the words below, but to me it's a massive jumble of information overload because I'm unable to comprehend any of them. They're color coded. No words, just colors. I asked if there was a way that we could aggregate the info based on error category and the response in the room was complete confusion. How could I not make sense of the page? Maybe I'd been hit on the head with a brick or something. 

Later in the meeting a TPM friend of mine asked questions similar to mine about the proliferation of alerts that weren't represented on the dashboards, and how these didn't make sense because there wasn't any sort of comprehensible organization to them. I texted her to try to clarify that her confusion around the alerts was the same that I had about the graphs. She argued, no, the graphs contained useful information and the meaning was clear. 

And thus, my epiphany was had.

Hey, Paul, what the hell is your point?

Ok, ok, if you're one of the normal full color spectrum viewing humans of the world you're still not getting my

point. Just like my TPM friend wasn't getting my point. If you're one of the 8 or so percent of colorblind humans or a dog you might be catching on by now. Either way, I'll explain. 

The world of UX is driven by visual queues. Indicators telling us what's going on in an application, what we should do next, what the various pieces of information mean. As we move forward with stronger graphics processors, more dynamic screens, designers are integrating images, graphics, subtle colors and shades of colors to convey this data. Look around the technical world and you'll notice that more and more, actual words, groupings of data, simple menus, are being replaced by colors and shapes. The most simple example is a red dot that means something bad, a green dot that means something good. Other apps may use a wide variety of colors (naturally soft pastel colors which, regardless of actual color, I cannot differentiate) to mean many more things. An example would be from the days I worked on the old Microsoft Mappoint application. Cities, capitals, counties, historical buildings, and on and on and on, were all identified by different colors. To my eye every last one of those damn dots looked exactly the same. Exactly the same. They were rendered utterly meaningless, and since they were quite tiny, trying to mouse over them for the popup text was pretty difficult. The end result was a tool that I was simply unable to use in any meaningful way. 

The new world of UX is mostly lost on me. There is an entire world of visual queues on the Web, on the mobile devices, on computers, that I don't actually know exists. Really. I don't know it's there, you don't know I don't know it's there, and you can't understand when I'm unable to make sense of something that, to you, is completely obvious.

WWGD

This brings be back to the beginning. Why do I love Google UX? Go look at it for a minute. There is no reliance on any graphics to know what's going on. None. You can change the color of any item anywhere on the screen and not lose value from the application. You can remove images from any of their Web based tools and not lose value from the application. The Google designers are either absolute geniuses or colorblind. Google's design isn't "minimalist." Google's design is completely functional.
That's why I love Google UX.