To code or not to code? OMG! This is totally the wrong question.
So it’s just another day in Twitter Design land …
What that means is there is a deemed “useless” argument about some Defining the Damn Thing (DTDT) topic. This week’s installment (still going as I write this) was triggered by the following tweet.
This is what I call an irrefutable truism. In this case the truism is clear. More is better. Of course, if someone knows more, they are a better X. If what I learn provides more value to my being an X, it obviously makes me a more valuable X. Regardless of the topic chosen, the statement at some level is true.
In this regard, code is a reasonable thing to put in the category of more. This is true because for the vast majority of digital designers (the group we are limiting this conversation to), code is a default part of the digital stack. This is what I’ll explain later is a very non-nunaced look at that stack and at the roles and responsibilities of different disciplines in that stack. It creates a sense of both false equivalencies, and ironically creates a false sense of centricism around a singular part of that stack, while further ignoring the other aspects of the complex development cycle that makes this suggestion increasingly moot. His statement doesn’t acknowledge that learning has limits and as we go into a stack of a system decisions have to be made about which parts of the material, governance, and crafts in that system need to be learned by different people. While people are capable of learning more from the position of human mental ability, there are limits to how this scope of learning stops to scale due to so many pieces of indivdual and society complexity. In fact, access to learning even in this day and age has limits directly related to privilege.
As the argument continues throughout the weekend and into the beginning of the week, we begin to understand the focus of of Jared’s argument behind the initial truism. There are in fact 2 arguments: First, by a designer creating prototypes that are as close as possible to the final intent of the desired experience, the more likely that the final intent will be executed by other appropriately. Second, the more that a designer can speak the language of their developer peers the better they can collaborate with developer peers. Combined together these are two value propositions of just knowing more.
Again, both of these arguments are truisms and irrifutable in their framing. Of course, the closer the model is to product, the more likely it will be executed as intended. Of course, I can communicate better with anyone whom I speak the same language as they do. They also continue to ignore all of the data that suggests that there are consequences to these truths creating a unique paradox of logic.
Ok, so what’s your problem, Dave?
Let’s take the issue of language first …
Designers are an oppressed minority in many, if not most, in-house context where designers exist.
That’s a provocative statement, Dave. How can any team member be oppressed in a work context? How can anyone be deemed a minority?
Let’s look at this tweet that occurred as part of the argument …
This is the language of systemic oppression. I will go out of my way to speak the language of those who hold power, to assimilate, so they will trust me. It sets up a systemic pecking order in the organization using one of the more fundamental pieces of any cultural context — language.
Shouldn’t there be a single unified language based on the different facets? This new language would be a pidgin language similar to how Yiddish bridges Hebrew, German, and Russian to make something wholly unique and in fact unintelligible to the groups that didn’t learn to speak the new pidgin. Technology (all the parts of technology) needs to be part of that unified language. Code, in fact, is only actually a small part and arguably not the most significant or important part of the technology silo of the stack and thus the new language.
There is a movement among agile proponents called “Balanced Team”. It is a shame that it hasn’t gained as much traction in the general and formalized agile communities by this time. It’s been around awhile. One of my understandings of their tenets is that of mutual respect. From my perspective mutual respect can only occur through equity of perspectives. This means it is imperative for balanced teams to truly work to find a language that does not privilege one perspective over another. In fact, the process of creating/learning this new language would be an exercise in building trust, and creating/earning mutual respect within any organization.
The assertion begs to ask us, what is the very value of design?
So going back to the oppressed minority piece, in almost every organization I have worked in, design is a second class citizen.There are many reasons for this and many of them lie at the feet of designers themselves. But at the core of the issue is that there is no shared nor equal perception of the value of design to the business. This actually has real impact to a design team’s ability to actually reach their potential in providing the most value for their organization.
The impact is actually quite circular. Design isn’t valued. Design isn’t given priority and resources. Design is unable to reach its true potential in providing value to the organization.
Intent to execution
So now let’s go back to the other issue. The more true to execution a designer can come to prototyping their intended design the more likely that the intent is realized more accurately and precisely. There is a real counter argument to this that is often incorrectly articulated. It states that if I know too much I will limit my creativity to the box that I now understand too well. I have not found that knowledge limits creativity. My take on why knowing too much of the system has conssequences relates back to a core piece of human-centered design. The very core of Contextual Inquiry is that design starts off from the stance of the student or apprentice — aka learning. At the heart of this is the foundation of anthropology and the notion of balancing the outsider and insider perspectives to bring understanding through comparison. I am only as valuable as a designer as I am able to maintain that balance between the outsider and insider perspectives and to hold the mindset of student/apprentice.
The digital designer? High-fidelity prototyping?
The other idea here is that there is such a thing as a “digital designer”. Now, of course there are designers who not only work in digital media, but they will most likely only work within digital media for their entire career. However, design at its core is process-driven and is agnostic to its media. Thus, the fluent designer is able to move between media fluidly. In my experience Industrial Designers and Architects make awesome digital designers, more because of their rigorous foundational education in design, than any technological abilities.
Further, there is always this notion of “how much fidelity is enough?” In a world where documentaiton is frowned upon due to avoiding rework, isn’t a high fidelity prototype just as “design up front” as any documentation? Few designers who argue for designers to learn to code, suggest that designers do production level code. This means, that the prototype invariably is ancillary to the development cycle itself.
My other problem with the highest-fidelity prototype is it is framed as a hand-off. That the designer does a rockin’ prototype, tests and revises it, and finally reviews it with a developer to convert it to production. This goes against the very collaborative notion of agile, scrum, and balanced team which put collaboration (not coordination) as a higher-order principle. A self-organizing team has a collection of skills/capabilities and collaborates across those skills. I would much rather sit next to a developer and co-design and co-develop together sharing keyboard and mouse at appropriate stages of design & development throughout the product development lifecycle than have any sort of hand-off of one to the other. I bet I’d learn a lot about code as that designer, right?
This isn’t about reducing curiosity, but about countering a prescription on what to be curious about.
Almost predictably someone will throw out the argument of “you don’t think that learning is important to career development?”
Of course, I believe learning is important to career development. Curiosity and continuous learning is foundational to just being a good professional person and no one I know in this argument would suggest to stop learning. The issue is what should be learned. One of my favorite responses to this question came from John Cutler:
When I read John’s tweet, it brought up for me what I think is really the fundamental issue in this conversation:
What is a designer?
And now every reader has just in unison (yes, you’re all reading this at the exact same time) went “Ugh!”
Advancing the practice through education
When someone tries to dictate what someone needs to learn, they are also implicitly telling every educational program hoping to serve the direct and tangential disciplines of the practice being mentioned what they have to offer. In this way, Jared is not impartial in this regard. He is an owner of such an institution and by putting out a call for specific education like this, it sets his school apart by suggesting a bias towards the topic of coding which they offer.
Prescribing what to learn, is the same as prescribing what to teach.
Why is this a big deal? Shouldn’t industry make that prescription of education? Yes, except even Jared said during this debate that knowing how to code doesn’t make you a better designer, just a more valuable one. Jared defines value as being determined by pay, not by outcomes produced.
So, by having an argument that actually isn’t about ROI of education, but about market perception, Jared is asking for a prioritization of coding in educational programs. Since educational programs have to have to have limited scope, these programs by adding code to the core education of a designer, need to remove a learning outcomes that was previously there. When you prioritize you are defining. You are putting a stake in the ground and stating this is the core or foundation of a designer coming out to be ready to do the job of designing in this context (in this case digital).
Jared has been known to be a champion of generalists. But what he doesn’t acknowledge is that you can’t ever be a generalist. He uses the model of the broken comb to describe the mix of capabilities that a designer should have, but he is still limiting the size of capabilities by the size of the comb. For Example, many programs prescribe that designers should have fluency in the history of art & design. Many design schools make this a requirement. The accreditation for a Bachelor of Fine Arts in the United States prescribes it. Upon my limited look at the CenterCentre curriculum he and his team have made a choice that coding is more important than art & design history. I couldn’t make that sacrifice. To be critical a good designer needs to be grounded historically.
There is the stated, and there is the person stating it. Both matter.
We disagree and that disagreement is generally OK. But what Jared doesn’t acknowlege is his position of power, authority, and influence in the community. As an example designers are still living with the effects of Jakob Nielsen’s 3-clicks rule stated almost 20 years ago.
Like Jakob, Jared’s statements hold weight and have impact beyond just himself.
So, many orgs who are building design teams without design leadership present (or poor leadership) will just take Jared’s comment at face value uncritically. Now, of course, this as Jared says will probably lead to their new designers failing or flailing, and the company will course correct. But with all these companies figuring this out over years, whole generations of classes are hit with missing out on History in favor of coding (to make the point) and as we have seen already so many designers have no sense of the history of design already.
But maybe the generalist isn’t the goal, or even the best …
An assumption and bias noted above is the one of the generalist designer. Jared is working from the assumption that all designers working in the digital media should all be equal to each other as generalists. That a team of designers is a team of “digital designers” — again, defining the practice.
On my teams I have had 3 distinct design roles: Interaction Design, Visual Design, and Design Technologist. Each is a specialty. Each offers more focused value that in collaboration makes for a much more powerful unit than 3 individual Digital Designers. Further, the interaction designers by not being limited by digital are able to imagine the entire space of experience that even for a SaaS includes things beyond the digital such as sales communications, support systems, legal, etc.
Now just because you know code doesn’t mean that you can’t think about more than digital. Of course. I wouldn’t ever argue that you cannot be good at more than one thing. I would challenge that both abilities, and resources to do more things suffer at scales because the people who can stretch the most are also at the highest ends of the curves of capabilities for a host of good and bad reasons. As time is to learn is still a great privilege for the vast majority of ppl, it also means you are most likely reducing inclusion and diversity in your teams.
I’m not going to go there …
I’m not going to define the ideal designer. I’ll have my curriculum. Jared will have his. The point is they will hopefully both have their strengths and weaknesses and if all goes well, we’ll keep learning from each other as we always have and always do. We will grow as a practice from our different perspectives being in discourse with each other.
Is this a long term issue anyway?
- Isn’t this just a generational issue? Code is now part of lower education (K-12) for many (yes of privilege still) and it is only going to become more available over time. Soon it will be like saying all designers need to know arithmetic.
- The alternative future/near present is one where the abstraction layers between design, code, and technology are getting better and better every year. “Knowing code” is going to be made irrelevant by either that abstraction layer or because AIs are just doing coding for us.
- Lastly, doesn’t the advent of componentized design systems make this point almost mute. In my last few organizations one of the selling points of the design system was a reduction in prototyping by designers because the developers could actually be trusted to take low-fi prototypes and make them work utilizing the agreed upon patterns and components.
Another opinion on “No”; for further reading.
I think that Alan Cooper has one of the best arguments on this topic. It is profound, and definitely based on an articulation of the designer’s role being specialized and that in particular Interaction Design in practice is non-material in nature and technologically agnostic as it is focused on people, framing their problem spaces, and figuring out to create systems that behave to help those people meet their goals and satisfy their motivations.
Alan in the Twitter thread also adds the further point that out of all the problems that designers need to be thinking about technology is actually low on the priority list. There are so many more pressing domains that designers need to learn about and convert that learning into framing problems and solving them.
Acknowlegements
I want to thank the great feedback and advice and support given by the following people:
Others volunteered to help which is always great support even if it doesn’t work out.
Thank you everyone.