My name is Whitney Williams, and I'm a freelance designer-developer living in Greenville, South Carolina. I couldn't be more excited to be here with you, so let's get started.
How many of you are designers only?
How many of you are developers only?
Ok, and how many of you feel like you do all of the things? You're not just a designer or just a developer; you do a little bit of everything.
Most of us, I think, do a little bit of everything. Even though I'd label myself now as a front end developer, I started my career as a graphic designer. I learned an enormous amount about things like color, hierarchy, and typography, and that designer background continues to inform the way I write code today.
There's a lot of talk right now about how people who build the web are increasingly trending towards specialization. Front end developer, back end developer, user interface, user experience, dev ops, web designers, content strategists… the list goes on and on. The sheer complexity of the websites and applications we're building demands a certain amount of specialization.
That being said, it's incredibly important that we recognize that drawing lines in the sand is a losing strategy. Just as design isn't purely aesthetics, development isn't simply lines of code. The belief that these two fields have competing interests can stand in the way of successful collaboration.
In reality, the principles of good design often mirror those of good development; every member of the team ultimately shares the same goal: to ship a product.
So let's take a look a few of the skills designers possess that can make us better developers.
Perhaps the most common skill associated with being a designer is creativity.
When we talk about art and design, we often refer to what psychologists and sociologists sometimes refer to as "big C" creativity, "the biological and behavioral traits that contribute to the extraordinary achievement of individuals." This kind of creativity is important, but intangible; it is the desperately sought after stroke of genius.
But creativity can also be defined in a different way. "Little c" creativity, or everyday creativity, is much less elusive. More importantly, however, it can be practiced.
Everyday creativity is simply the ability to investigate, generate and recognize ideas, alternatives, and possibilities to solve problems.
As developers, we practice what the sociologist Benjamin Dalton refers to as "habitual creativity". When writing code, we hack things together; we make it work. We iterate, we debug, and we refactor. We consciously seek to improve on habitual actions, to build routines and practices that are more efficient and successful than they were previously. Every single day, we create and build new things.
Creativity doesn't have to mean that we are building new things, or that we are reinventing the wheel. As developers, we must remember that innovation in any field is more often evolutionary than revolutionary.
By reorganizing, recombining or reinterpreting concepts or ideas, we are practicing creativity. When we examine the best way to improve an existing feature, discuss the implications of removing an existing feature, or plan out the scope and path of new features, we are practicing creativity.
While designers and developers may solve different types of problems or practice different kinds of creativity, we both rely on the same basic skill to reframe our thinking and arrive at a viable solution.
By practicing creativity, we're also developing another crucial skill: intuition. Intuition builds on creativity, giving us the insight and ability to quickly perceive the quality of our ideas.
Experienced designers can identify when something doesn't feel right. Similarly, experienced developers possess a sense of which programmatic approach will work best. Being able to harness our intuition can increase efficiency dramatically.
My first job out of college was spent working as a graphic designer at a local advertising agency. After a few months, the lead designer left to found his own agency. All of a sudden, I was in the hot seat with practically no real world experience. My two bosses, in their 50s and 60s respectively, had been in the advertising field for decades, making my lack of experience all the more exasperating.
The first large-scale project I tackled on my own was the rebranding and localization of a French road mesh company with offices in South Carolina. One of the most tedious tasks was the recreation, editing, design, and typesetting of literally hundreds of product datasheets.
The sheer amount of datasheets to get through was astounding, especially considering the size of our team: two project managers; two company founders; and me, the sole designer. When we sat down to discuss how best to proceed, one of the bosses suggested that instead of recreating each document from scratch, that we edit the existing PDFs.
Not having access to the native files dramatically increased the frustration and difficulty of maintaining consistency across all documents, so I suggested that we create a few basic templates, simple enough to be flexible, but with enough of the basic layout mapped out to be useful.
My boss was hesitant to invest time in something he couldn't directly sell to the client, so I set to working editing each document individually. By the end of the week, I could tell that there was no way we'd meet our deadline, so I came in Saturday morning to build a few templates.
On Monday, I quietly switched to using the templates, aware that I was not only not following the rules, but that I ran the serious risk of making my boss angry. Luckily, I managed to crank out about a half dozen files in the same time it might have taken to edit two or three had I done them each manually.
When I handed in my work, my boss asked how I had suddenly become so much more efficient. I told him the whole story: how I had come in on Saturday to sketch out and create the templates, and how I had packed a bag of snacks in case the plan backfired I ended up at the office past dinner.
He wasn't immediately impressed, but he also wasn't angry. We finished the project using my templates.
When I left that position, my boss commented on my ability to recognize and understand the long-term goals of our projects, and acknowledged that my sense of intuition had enabled me to work more quickly than he had expected given my limited experience.
I'm not saying that ignoring your boss is a good idea. Actually, it's really risky. I got lucky. I trusted my gut and it turned out to be right.
What I'm saying is that whether you're a designer or a developer, you often have a sense or gut feeling of what works and what doesn't.
Trust your intuition. It may not be right, but it's a great place to start. The more you practice, the more you hone your craft, the better that sense of intuition will be.
COMMUNICATION & UNDERSTANDING
Once we have mastered the ability to generate and judge the viability of our ideas, we can put them to use. As designers and developers, our work rarely exists on its own, but rather, is part of a larger whole built collaboratively.
Design is not purely aesthetics, just as development is not simply lines of code. Designers must consider how functionality affects form, and developers must be creative in building out functionality. Ultimately, designers and developers must work with one another to create a single unified entity: the product.
Rather than seeing ourselves as disparate groups, designers and developers alike can achieve greater success by remembering that the ability to communicate effectively among all members of the team is at the very heart of both design and development.
Google the phrase "designer developer communication," and you'll have a hefty 19.7 million results to comb through. With so many blog posts and articles written on the subject, it shouldn't come as a surprise that the ability to converse with one another doesn't come naturally. After all, it's common to hear designers and developers both admit to feeling as if they don't "speak the same language."
But is the lack of shared lingo the real issue? I don't think so.
Instead, I believe this statistic speaks less to a lack of communication than a lack of understanding. So how can designers and developers overcome the lack of common vocabulary and get to a place of true understanding?
First, the obvious: learning how to break down boundaries and overcome stereotypes isn't easy. But by actively promoting positive, open conversations in which collaborative questioning and searching are encouraged, we can establish a baseline of shared knowledge and understanding.
Reframing our requests in terms of objectives to be fulfilled instead of dictating their implementation can also help us avoid giving the impression that the only path to success is through our own dogmatic directives.
The natural outgrowth of a healthy relationship founded on communication and understanding is empathy—the ability to identify and relate to one another's thoughts, attitudes, and feelings.
While empathetic design has recently experienced resurgence in popularity, the principles are far from new. In a November 1997 issue of the Harvard Business Review, Dorothy Leonard and Jeffrey F. Rayport state, "The techniques of empathic design—gathering, analyzing, and applying information gleaned from observation in the field—are familiar to top engineering/design companies… but they are not common practice."
Pete Smart, a designer from the UK, was reminded of the importance of empathetic design when he travelled more than 2,500 miles to try and solve 50 problems in 50 days. By getting away from his daily routine, Smart found that the constraints of his design process sometimes allowed him to miss real empathy. He states, "Real empathy is not naturally fostered in focus groups. It's not uncovered in analytics. It doesn't start with personas or empathy maps. Real empathy starts with people."
While Smart's journey focused on design, the lessons learned are equally applicable to development. Empathy is for everyone.
A programmer who is skilled at anticipating and responding to customer needs is better prepared to capitalize on the possibilities offered by new technologies. In fact, some of the most impressive ideas come from engineers and designers who actually use the products they're developing.
Rather than relying on traditional research techniques in which data are gathered in relative isolation from other disciplines; empathic design demands creative interactions among members of an interdisciplinary team. Working together from day one, designers, developers, and other members of the team can maximize innovation by directly connecting those who know what can be done with those who need something done.
By combining the knowledge of _unexpressed _needs with the knowledge of how to fulfill those needs, companies utilize their existing technological capabilities most effectively.
While empathy for the user is undeniably important in creating better products, it is also important to promote empathetic culture within our teams.
The design and innovation firm IDEO states, "When companies allow a deep emotional understanding of people's needs to inspire them — and transform their work, their teams, and even their organization at large — they unlock the creative capacity for innovation."
Adam Waytz, assistant professor of management and organizations at the Kellogg School of Management, agrees. "The organizations that engage in these types of activities are very effective in what they do, particularly in the domain of innovation,"
A culture in which team members feel an inherent sense of trust and freedom allows for greater experimentation and creativity, better communication and understanding. By promoting even one of these things, we also subtly encourage the others. Healthy culture begets healthy culture.
What happen then when the creative juices aren't flowing, when our intuition leads us down the wrong path, when communication is falling and our empathy is at an all time low?
Those of us working in design and development have committed ourselves to a life of constant improvement. We have committed to never stop learning, dedicated ourselves to keeping up with the rapid pace of our respective industries. Our craft and work require an incredible depth of knowledge that takes a lifetime to truly master.
This constant pressure is stressful; no wonder we sometimes forget our manners and revert to childlike name-calling or blaming, We are only human.
Whether we're designing better interfaces or developing new features, it's easy to lose patience with ourselves and others. While a certain amount of pressure may motivate us to generate better work, rushing through tasks almost never results in the sort of thoughtful, inspired designs and lines of code others admire.
Instead, we must give ourselves time to try and fail. We must judge one another not on fleeting moments and hasty decisions, but on the body of work as a whole. A single snarky Twitter remark should not define our entire existence. We should give one another the benefit of the doubt, understanding that we too have failed.
Designers know that innovative ideas don't often come at the flip of a switch. Instead, the most effective solutions are often the product of hours of thinking, sketching and reworking. Similarly, the best solutions in development are almost always the result of refactoring, of taking a function or snippet of code and engineering it to be faster, simpler, more modular, or independent.
By allowing ourselves to time to think, to architect, and ideate, we can push through barriers that seem insurmountable. We can take the time to communicate once again, the objectives we hope to achieve. We can persevere when the ideas don't come, when the layout isn't quite right, and when our code just doesn't work.
We can put our heads down and get to work, knowing that the answer will eventually come. We can knowingly practice patience, trusting in the belief that our best work is yet to come, that the pinnacle of our careers in not in the past, but in the future.