Sponsors

Friday, June 6, 2014

Design is not what you think it is

hero_image



There are some supremely talented developers out in the world who, at best, consider design to be a value-added feature that takes a backseat to just about everything else.



Ask a random sample of developers their opinion on design as it relates to their craft and you’ll receive responses ranging from wild enthusiasm to visible agitation. While it is apparent that a growing number of Android devs are placing increased emphasis on understanding and implementing good design, the ecosystem would be so much better off if we could break through to the hold outs. There are some supremely talented developers out in the world who, at best, consider design to be a value-added feature that takes a backseat to just about everything else. At worst, they bristle at the mere mention of design as a legitimate discipline in their domain.

Some developers feel this way because of overwhelmingly negative interactions with hostile users, project managers, executive override, or so-called creatives (more on this later). The demand for good design is usually delivered to them via scathing reviews, esoteric art school vernacular, or fluffy, meaningless marketing buzzwords that have no basis in objective reality. Others may hold similar positions out of misunderstanding or lack of confidence in themselves or others to carry out a particular vision.


bad_review


Whatever the reason, if you are a developer who is uncomfortable with or resistant to considering design a critical component of your project, allow me to offer a slightly different perspective from what you usually hear from design evangelists. I am a designer with the atypical distinction of having some development chops. With a foot in each camp, I can get a sense of where the disconnect is and I am happy to report that it is all illusory.


The divide between designer and developer does not exist in the way most believe


You have been mislead. There is no blood feud between the artsy creative-type versus technical code ninja. There is no right-brain versus left-brain. No red versus blue.



Consider the perspective that at its core, good design is logical.



As a developer, you are already a designer whose pursuits are no less creative than those who purport to hold a monopoly on the “creative” label. In fact, my personal journey on the path to becoming a developer has been one of the most creatively fulfilling experiences of my life. This is coming from somebody who has been involved in UI/UX design, film and commercial production, motion graphics and VFX animation, digital art of all kinds, and the occasional acrylic painting.


Obviously I am completely unaware of your individual situation or background. You may not be able to draw worth a damn or have any understanding of color theory, but I know you are wired for design.


When you look at someone else’s code and gasp at how redundant and inefficient it is, you are thinking like a designer.


Every time you go back to refactor a method, you are thinking like a designer.


Completely OCD about commenting and readability? Designer thoughts.


Design as logic


Consider the perspective that at its core, good design is logical. And being a developer, logic is totally your thing. This may seem to contradict the highly subjective descriptors that usually accompany design-related conversations, but make no mistake, there are established protocols and conventions that should be observed and they are equally as important as solid code.


joystick_car


Let me illustrate this with the following analogy:


You are an engineer developing a new car for your automotive startup. After years of intense R&D, the resulting product is unveiled to the world. It is truly the pinnacle of modern engineering, utilizing breakthrough low cost lightweight composites and a radically efficient but powerful engine with 30% less moving parts. For a base price of $5000 USD, it could change the world.


But you have to steer with a joystick.


And the acceleration is controlled via a throttle lever.


Also, there’s a brake button.


Really, it’s all in the documentation. Didn’t you read the FAQ?



They want a steering wheel and gas and brake pedals that operate predictably...



The above is extreme hyperbole, but you get the point. Users are not expecting you to include beautiful dynamic animations like Timely or come up with some chic Swiss minimalist layout, but at the very least, they are expecting a Toyota. They want a steering wheel and gas and brake pedals that operate predictably based upon established conventions. In the context of an Android app, they don’t want to hunt through documentation that opens up as a FAQ in their browser to discover how to activate a setting or wonder what that mystery icon in the action bar is all about.


Yes, a poorly designed app may function perfectly under the hood as long as the user understands what to do, but bear in mind that sloppy code that takes the scenic route to spit out the right answer can also be considered functional in the same sense.


So what now?


Luckily, there is a wealth of information out there that can assist you in figuring out how and when to leverage built-in interaction patterns to address a particular use case. Google has done much of the legwork to build these design libraries for you to implement.



You can easily grasp the basics of good design without a Fine Arts degree.



It is up to you to figure out how to assemble the pieces to create the leanest, frictionless user workflow you can. Again, these are the types of logic-based challenges you overcome on a daily basis and I am confident that with some research, you can easily grasp the basics of good design without a Fine Arts degree. I recommend starting with Google’s official Android Design resource. Pay particular attention to the Patterns section.

If you are part of a larger team, understanding design will help you better communicate with those who specialize in taking these fundamentals and elevating them to the next level. Even if your organizational structure has you quarantined from the actual design process, learning the language and the rationale behind design decisions will certainly not hurt. I have seen some not-so-friendly interactions between devs and designers due to a professional language barrier, so any steps toward breaking that down will be a boon for your team and working environment. I also recommend that designers should at least learn the high level basics of programming, but that is a topic for another day.


Take the leap


devpic


Don’t fall for the self-perpetuating meme that depicts designers and developers as completely different species engaged in some fierce territorial rivalry of form against function. There is a clear pathway for developers to use their existing skill set to branch out into design and enough overlap between the two disciplines where you don’t feel like you are starting from scratch.


It is clear that Google is getting real serious about reminding developers to be more aware of design, so there is no better time to get started!






from Android Authority http://ift.tt/1nWEV8j

No comments:

Post a Comment

Related Articles

Related Posts Plugin for WordPress, Blogger...