I apologize for throwing this 4000 word essay out there like this. I thought and thought and just didn't know where else to put it. I hope someone enjoys it.
Yesterday a very respected colleague, who I also call friend (not in that Facebook way, but in that pre-Internet kinda-way), wrote a very well articulated article entitled, . Some might be surprised to hear that I cannot agree more. I also cannot disagree more.
On the one hand I have done basic coding in my time. In fact, my early career was filled with making web pages. On the other hand, I haven't directly applied that skill to my day to day job as a designer in about a decade. And the longer I've been away from direct coding the more I find my experience as a coder becoming less and less important to my personal life as a designer. It is probably very hard though to accurately fully know the value of my experience.
But the question isn't whether or not designers should know HOW to code, but rather, "Should They Code". Implicit in this question is that the code they do has a purpose and I think where I disagree most with Josh is the purpose of not the knowledge of technology, but the application of that knowledge to production.
FIRST, LET'S TALK ABOUT DESIGN AND DESIGNING
At it's core (even in it's dictionary meaning) to design is to plan. No more, no less. Now of course, as a HUGE advocate of the process, methods, and culture of traditional design I believe deeply that design in practice is definitely more than just "to plan". But I do equally believe that it's greatest contribution to product & service development is the creation of the plan, the vision, the very essence of the possibility. But it can't start or end there for the designer.
Before we can plan, we need to be able to ask questions. Some questions are about the people we are planning for. Other questions are about the possibility of the media we are designing for, in and with. Further, there are questions in how we want to explore presenting understanding, messaging, even legibility.
Yes, there is overlap to focuses, usually two at a time. Historically there has been these pair groups: HCI (peoplenew media (graphics/interfacesinformationdesign/architecture (graphics/navigationIS CHANGING?
Over that 20 year period there have been changes to our contexts that have forced us to consider the combination of these worlds What has made up this change?
* Tools have been one of the biggest change. jQuery, Ruby on Rails, HTML5 (CSS + JavaScript), a host of frameworks like Bootstrap by Twitter and Foundation by Zurb, etc. have all made not just coding, but designing directly in code incredibly accessible for those who have a high capacity for converting abstraction into tangible in the logic that programming works in. This capacity is not an anomaly but also not something that everyone can do at the same level.
* Startup culture, especially the type promoted in Silicon Valley, has been spread to the four corners of the globe. If startups can bootstrap an Instagram (sold for $1 billion with a minimum number of employees), then even an enterprise should bootstrap all their products & services as well, regardless of the issues of scale, scope, stakeholders, etc..
* The spread of Agile methods through the creation of Lean philosophies for both development and design. This has actually tightened a very developer centric model of software development where business analysts and designers have been replaced by a false myth of customer focus by developers themselves.
* The advent and growth of the Maker/DIY culture. It's fun, and it requires a spirit of learning every part of something in order to build what you want. It's not exactly individualistic to the extreme but it is a culture that heavily respects self-reliance with a very open & free peer-mentoring culture. It is also a culture that is based on the spirit of tinkering which I most certainly admire (more on this later).
* Open Source Software has a culture all it's own as well, where contribution is only valued if the contribution is in code itself.
So there are a large number of organizations big and small who are only hiring junior, mid-level, and even senior (sometimes even managers) designers who not only understand technology and its relationship to the user experience, but whom have the direct abiity to create viable artifacts, sometimes for production purposes, using programming languages.
Two caveats here and they are important:
* There is code (HTML/CSS) and there is programming (JavaScript, PHP, Java, ObjectiveC, Python, and associated frameworks).
* Early stage startups (before $1million in funding or revenue) are a completely different world where everyone in the organization does everything. Heck, the CEO should be able to code along side the CFO and CMO. Heck, they might even be the same person.
So if design is more than "Creating a plan", what is design? how is this definition relevant to this conversation on the place of coding in design generally?
I would be bold to try to define design itself. What I will say is that more important than defining design is to say that there is more than one design and there is more than one axis of design. Obviously, we have fashion design, interior design, information design, industrial design, visual/graphic design, architecture (which often self-defines itself outside of design completely), game design, web design, interaction design, and service design.
But what I mean is that within almost all of these media of design there are types of design as well. The differentiation has to do with the level of detail the designer primarily works at. When I work at the level of icon or typography it's a different type of focus than when I'm working on the UI, and the same can be said for the interaction design and information architecture as well. Then there is the strategic design.
So when people say that designers should or shouldn't know how to code, they are right and wrong because they are being too inclusive. Even if you assume they are only talking about digital media designers they are still being too broad. To suggest that a strategic designer, design researcher, typographer or iconographer has to know code I think seems obviously ridiculous. Of course, per above there are contexts where a single person would be doing all 4 of those things and standard UI design as well, so it isn't always a ridiculous proposition.
But just because it isn't absurd doesn't mean it is a universal truth either, nor does it mean that it is exclusive. The absolutes of the arguments also make it wrong on both sides.
So now that I've given all the context I can on this topic,I'm ready to tell you where I stand on this.
REALITY VS. THE IDEAL (YES, I'M AN IDEALIST)
REALITY
If you are a junior to mid-level (under 7yrs experience) designer the odds are just because of the current economic & cultural climate, you would be putting yourself in a very bad position if you didn't learn how to at least prototype in the following technologies: HTML, CSS, JavaScript, jQuery. I'd say having basic understanding of how to use databases, JSON/XML, and PHP would also be helpful. How to dig in? Start a WordPress blog and design and implement your own theme from scratch. Then when you're done, do another one.
This is just an economic reality of employability. Just deal with it. Even I as a 20yr, strategic designer who concentrates on research and vision when I was job hunting lost a lot of positions because I couldn't code at an appropriate level of expertise. I'm very good w/ tables.
So for all intent and purpose, the point is just plain moot. Because as Jr. and Mid-level designers become sr. and director level designers their tech chops will just be assumed as they move up the ladder. Our whole frame of reference will be completed changed (is changing) in the next 3-5 years.
THE PROBLEMS?
SCALING EDUCATION
Considering the amount of knowledge and number of skills within each major domain related to the design of user experiences is it scalable to expect that all designers have all these skills?
The answer is yes and no. For the junior designer I don't think it's a big problem. This part of the problem is really a problem with educational systems and not the problem of human capacity. This means that in the short term there will be struggles to manage scale but in the long term, this will become increasingly easy.
I know this because I've seen it first hand. Students are incredibly capable at scaling up. The good students do this type of scaling in their sleep. Not all of them, but that is true of any subject or capability. However, there are enough that can take on all that we throw at them.
But the issue remains short term. If mid-level and many sr-level designers are expected to scale up their practice to include something that didn't exist before, we are not going to be able to scale this. Yes, employers can be as picky as they want to be, but they also have seen that when they do, they have been wasting time and money on long drawn out recruitment campaigns. I've heard of some hiring campaigns to go months if not over a year to find the right candidate. This is especially true outside of tech and design hubs (where combined represent most of the design work out there).
So I'm not confident that this will scale in the near term outside of the startup context.
SACRIFICING DEPTH IN ORDER TO SATISFY BREADTH
As noted above there's a lot that goes into UX practice. We are barely scratching the surface of our ability to do our core objective which is to represent the people who will be using the products and services we design. So now we need to add visual design and programming to our core practice while we are still learning the main point of why we exist.
I'm worried about us diluting our core value to the products and services we represent. To be honest, I haven't seen the results of any organization that demonstrates a true attention to the detail of user experience that also has a single designer/ui developer model. Yes, there is good work out there, but not great, not complete. Of course, the same could be said of organizations that keep these roles in separate people who are collaborating closely as well (If I'm going to be honest). We just haven't popped the general problems of user experience.
I believe we've reached the point of "good enough" and this is not a good attitude for our industry to have.
THE GOOD SIDE
There are three things we get when we add programming to UX Design:
THE MOST IMPORTANT THING WE GET IS CONTROL.
While I was at Motorola Solutions (formerly Symbol Technologies), I was really impressed with the way the industrial design team (I was in their department) did their work. They seemed to have no problem having their intended designs be the same as the final product. This issue is something I struggled with for 14yrs before working there (and still do). After further observation and inquiry I discovered their process and culture enabled this, not just in the design group but in the greater organization itself. They did the following things to make this happen:
* They partnered with engineering throughout research and design. There were very few steps in the process where engineering were not included in design decisions and design was not included in engineering decisions.
* It was understood by internal engineering teams and taught to the manufacturing design teams from the get go that the industrial designers OWNED the surface layer of the design. By owning it, it meant that they worked in the CAD program that the engineering teams worked in (the equivalent of programming the front end). No one could make a decision in a specification of the total project that impacted the surface layer without going through the design team.
While I was at Motorola. Myself and my boss, Ted Booth, understood the value of this system and on one of our projects we tried to do this for the software we were designing. This project had us working directly in Expression Blend (as we were building a .NET 4 desktop application). The project ended up being a success in many ways because of the philosophical stance we took owning "the surfaces". It also failed in many ways because the group we were working with weren't ready for it, nor were the design team proficient enough in the technology to take it far enough on our own. So we blew budget on bringing in a third part to get us through the project. And blew our dates with learning curve, and cultural communication issues.
I will say that I have also had strong success since then through a completely different method which I'll talk more about below, but to tease you, it is called collaboration.
BY KNOWING THE TECHNOLOGY WE CAN TINKER IN IT
If people know anything about me its that I love the word serendipity. To me serendipity is the heart and soul of design. And to take advantage of it as a tool, you have to explore the world around you. One of the designer's best tools for exploring one element of their context is to tinker with the technology that their projects are going to be built on.
When I was at the Copenhagen Institute of Interaction Design's (CIID) summer intensive program in 2011 one of our courses was called "Computational Design". To be honest, I was skeptical about the topic, but what I learned was that programming due to its dynamic nature and it's literalism is a force for serendipity. By creating automation sequences you get to quickly experience change in a way we've never been able to do previously.
EXPERIENCE IT INSTEAD OF VISUALIZE IT
This one should be obvious to folks. I get to experience it instead of just visualize it. And no a "click through" is not the same as experiencing it-not today. When the transitions of an application are as important as the layout of the UI, we need to be able to experience it. This isn't just about testing. This is about designing as well. This is why both tinkering and experiencing are so important from a designers perspective because they directly impact the design phases of a project, unlike control which is about the development side of the project.
In the project mentioned above that I worked on for Motorola there were so many moments when we moved from wireframes (we had a ton of wireframes) into Expression Blend and in so doing learned so much about the flaws in our designs. The presumed transitions that we wanted to have were just not going to work once we started building it, no matter who built it. But because we were able to tinker with fresh ideas in real time, we were able to come up with a host of options we would have never been able to explore or discover if we went from wireframe to pixel-comp and handed it off to the developers to build for us we would have missed the discovery opportunity until it was way too late.
THINGS PEOPLE SAY ARE POSITIVES THAT I DON'T REALLY CARE ABOUT
* Speaking like a developer. People should just speak to each other plainly.
* We can work faster. I'm not a big fan of speed for speed's sake. Efficiency turns into expediency really quickly, and it leads to just mediocre outcomes.
* Designers need to understand technology. Yes, this is true. Understanding technology is different than being able to produce in it, and further being able to produce at a consumable, scalable level. It seems to me that developers are selling themselves short with this statement. There is real engineering (applied knowledge and execution) that goes into software development. It is called "computer science" for a reason. From understanding the development environment, to being able to de-bug, work at scale, and a host of other issues I've learned to keep quiet out of respect of those who I know do it really well.
Further, what I really love is how a designer's lack of knowledge actually tells developers what is wrong w/ the technological model in the first place and usually exposes more about the mental models of real non-technical human beings than anything else. And isn't that our job as designers anyway-be the humanists?
WHERE I REALLY AM CONCERNED
To repeat, I have acknowledged that there are environments where the economics of the context require that everyone not just the designer knows how to code, or more accurately, the technologist often needs to design, project plan, and run a budget, too. (Or the CEO needs to know how to code, too.)
In every environment I have worked in the economic pressure to have "all hands in the factory all the time" has just been too great. What this means is that every environment I've been in or connected with, the designer that can code looses design time to become a developer producing consumable code. They are waylaid with debugging, and their time is no longer focused on the issues of design, but rather on the issues of development.
This is true of the issues of the UI Design itself, where most of the folks doing design/development mostly "focus" as designers. Attention is lessened on visual design issues and microinteraction design that the designer is really hired to do in favor of expediency of putting that person in the factory working on production code. THIS MEANS THAT THE TWO BEST REASONS TO HAVE THE DESIGNER CODING ARE COMPLETELY LOST.
I'm sure that someone is going to say, but my organization isn't like this. Either that's great (anomaly), or you're deluding yourselves (most likely). The "just great" category of organization is rare. It takes a steeped discipline by management which I have seldom seen to not be swayed by the possibility of reaching deployment dates faster and more cheaply.
THE QUESTION OF SHOULD VS. SHOULDN'T
It sounds like I am saying that designers SHOULD know how to code but just not for production. Yes, that is true for many design contexts where coding means HTML, JavaScript and CSS.
The truth is that many designers in our field aren't in this context. Not most, but still a significant and important amount and we are part of the same eco-system that y'all are in. We are designing mobile applications built in ObjectiveC, Java and C#. We are designing desktop applications like the one I'm typing this article in. We are designing kiosks, ATMs, watches, medical devices, etc. where the programming technology changes every moment.
Yes, physical computing is becoming incredibly more accessible. I myself have dabbled in Arduino a few times.
What is also true is that simulation tools are becoming better and better every year, too. And in all honesty, I don't need to be able to code so much as to be able to prototype simulations of the future realities that I am imagining and want to bring to life. Tools like Adobe Edge and Macau are demonstrating that we are getting better at hiding code from the people who are building on top of it, but still only for HTML.
But why does code even need to be part of the equation? My students a couple of years ago created (that I might add, I'm incredibly proud of). They did code a piece of it, but not the hero of the design. When I presented this to an expert in interactive touch table design he actually asked me if my students built it. "No way! (except the administration piece)," I said. They built it 100% in After Effects and Premiere.
By using film making tools instead of coding tools, I get to work through the experiential aspects of it, tinkering in tools actually made for animating transitions. Further, I get to embed these directly into scenarios with people so not only do I get to imagine the UI, I get to imagine how people will behave with my UI and I get to improvise responses against human behavior.
So for me, I think we are asking the wrong questions, not just having the wrong answers to them.
The question needs to be, wHAT DO DESIGNERS NEED TO KNOW HOW TO DO TO ADD THE MOST VALUE TO THE PRODUCT AND SERVICE ORGANIZATIONS WE WORK FOR? For me it is the following:
* Have the set of tools and be experts at using them to DISCOVER THE BEHAVIORS AND MOTIVATIONS of the stakeholders who will be interacting with the systems we are designing with the goal of FRAMING PROBLEMS AND DISCOVERING OPPORTUNITIES for the organizations we work for.
* Be able to use VISUAL TOOLS at low and high fidelity to harness their creativity to synthesize a multiplicity of concepts aimed at CAPITALIZING ON THE OPPORTUNITIES discovered by doing #1. One of the goals here are to CRAFT DESIGN PRINCIPLES for the entire cross functional team to follow.
* Architect the STRUCTURES, paths, principles of content that lead stakeholders using the system from entry to understanding to finding MEANING AND VALUE.
* Take concepts from #2 added to the frameworks of #3 and drive deeper into them by CREATING SIMULATIONS EMBEDDED IN THE STORIES OF HUMAN SITUATIONS from #1 with the goal of REFINING DESIGNS INTO PLANS that can be validated and executed upon.
* EXPLORE the properties of proposed systems through SIMULATIONS of appropriate fidelity so as to experience possible futures. Refine these explorations towards a prototype that acts as THE PLAN for execution and deployment.
* COLLABORATE with those who execute on designs, to ensure that QUALITY IS MAINTAINED, lessons learned can be framed into viable changes that don't conflict with core DESIGN PRINCIPLES from #2. As lessons are always learned during production periods that lead to necessary changes.
Throughout all 6 steps there is a constant need to bring in stakeholders at all levels to not just validate outcomes but to contribute to their creation.
Sometimes code is the right tool for achieving some of the above. Sometimes it isn't. Even in a web design context it may not be the right tool all the time.
EPILOGUE:
Someone has claimed that knowing code and doing code keeps you as a designer from thinking strategically. This claim is pure hubris to me. Strategy and code are so far apart in what a designer may or may not be tasked with that the point is moot. The only concern is really one of time, not capability. Either your organization thinks that design is a strategic role and gives you time to do it, or they don't. Whether you are pixel pushing or semi-colon tracking, you'll be equally distracted from strategic issues.
One of the reasons I didn't post this right away is that I wanted this piece to be in a venue where people beyond my direct circle might get to it. My blog doesn't have reach, so I'm hoping that if you got this far, you liked it enough to try to spread it around. And thank you for getting this far. (WordPress says 3974 words.)
Full Post
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment