The Designer Who Got Run Over
The following is an anecdotal story compiled from experiences I have had working in mobile software consulting.
John (designer), David (tech lead) and Erica (large enterprise client) were on a conference call to review a set of designs which John had produced for an enterprise mobile sales tool.
“You know this looks good but I don’t know about the color of this button,” said Erica. “I am not a big fan of green here because it’s sort of hard to read the white text. I’d rather have it changed to purple.”
John had actually spent quite a lot of time selecting the colors in the mobile application and matching them to a related web application for the same client. He had spent extensive time coming up with a design language in which the end user would come to understand that green was associated with saving progress on a particular screen and turning the button to purple would violate the established pattern. A major competitor used a color scheme involving purple and John knew it was right instinctually to avoid off brand colors.
However, Erica was a major client. Rather than push back on this one issue, John decided it was too small to bother with and reasoned that if he just said yes on this one point then they could get on to more important things.
“Sure, I’ll make it purple.” So purple the button became.
With that one tiny admission John had lost some important ground. By backing off his design choice he showed weakness…from the perspective of the client, this weakness and unwillingness to defend a color choice meant exactly what the client thought it meant: Designers are just some guys who push pixels around and randomly choose colors for things without rhyme or reason.
While this seems like a tiny loss, it actually gets to the very heart of a major issue.
Designers must do everything in their power to justify everything they put on the screen from a business and technical perspective. If they have no defense prepared for every choice on the screen, they will get labeled as random pixel pushers and the design is now on the track to being compromised. Everyone in most organizations believes themselves to be designers (they aren’t) and when it becomes clear that there is no “meat” backing up design choices, terrible and inevitable patterns begin to emerge.
Over the ensuing weeks the button went from purple to red to yellow. The button moved from the lower left to the lower right to the top center of the screen.
David, the tech lead, also noticed this seeming lack of design resolve and began imposing his own ideas.
“You know, the Apple design guidelines state that this kind of button belongs in the tab bar on the left. In fact, this entire screen ought to go into a modal dialog because it only modifies data on this prior page.” Having watched John squirm in previous meetings it was clear to David that John had not internalized important UX rules for the iOS platform and that some of his careless design choices had real technical implications.
John found himself further modifying his designs. Now he had to move several similar screens into modal dialogs. Meanwhile, the button continued to jump around. None of this had been planned for and as time went by, the delta of the difference between what was being built and the original design grew much larger.
Engineer Psychology
To avoid becoming John, we must first analyze engineer psychology.
Engineers are super lazy. Ok, that is a bit of an exaggeration.
It is more accurate to say that developers (of native mobile apps) prefer to let their chosen framework do all the work for them and dislike deviating from the framework unless absolutely forced to do so. Something which might look cool superficially may require days of work if it deviates even in minor ways from core iOS UIKit controls.
Imagine if someone came to you (as a designer) and told you that it would be really cool if you were to turn your laptop on it’s side while you design.
Or that you should craft your interface by operating your mouse with your toes instead of your hand?
What if they told you to design an interface using only a pencil tool rather than several better suited tools for the same job?
This might be a crude analogy but engineers get the same sorts of gut responses when designers hand them interfaces which deviate violently from what their frameworks have been built to do.
Frameworks, like design tools, are tools and are meant to be used in specific ways. Most engineers will fight to make sure their tools are used in the appropriate manner, just as you would fight to use your mouse with your hand and likely dismiss the notion of using your toes as stupidity and not even consider it.
Overcoming objections
This instinct for engineers to fight for their platform may not always be in the best interest of the customer.
Most of the time, decisions to stick with the guidelines for a given mobile platform are good for users, sometimes they aren’t.
It is these “sometimes” which can be incredibly important and where innovation often occurs.
A good example is the magic button at the bottom of Yelp’s iOS 7 mobile application which pops out three floating sub options. Another example is Facebook “Chat Heads.” Still another example is YouTube’s floating multi-task windows which allow users to watch videos while browsing.
Knowing when to follow the rules and when to break them and how to argue with engineers on these topics is a whole other skill.
Unfortunately, engineers in the mobile world hold a huge amount of power and have the ability to introduce friction into the feature development process. They can complain and drag their feet and generally make life hard. If they aren’t on board with your design, I guarantee you your product will get built slower.
If you, as a designer, have a history of unknowingly violating design standards, you will come to the battle lacking credibility when it comes time to fight for those “important deviations.” So do yourself a favor: follow the rules as closely as possible until you reach a point where you need to do something atypical and your credibility will help sustain your arguments for doing things a new way.
The post The Designer Who Got Run Over appeared first on Rex St John.
