The Arguments for Learning Code
The topic of whether a designer should learn how to code has been debated countless times online. My personal stance is that understanding code is helpful for anyone who works with developers, and this isn’t limited to designers. I believe it’s useful for project managers and product managers as well. If nothing else, understanding the basics of coding creates empathy for the people who write the code, and it’ll demystify the process involved. People routinely underestimate the level of effort involved with fixing a bug or adding a feature because they don’t know how complicated those things can be.
Understanding how to code also has advantages on the professional end. When comparing two equally experienced designers for a position, the prospective employer may lean towards the one who possesses additional technical skills like knowing how to write HTML and CSS. This is a competitive advantage for designers who want to be a web designer.
The other argument for learning how to code is simply that it’s empowering. You can execute your own concepts, make tweaks on the fly, and design in code through the browser. Having programming skills will help you understand the nuances of your design decisions.
Last but not least, knowing code will help position you to design for more cutting-edge interfaces. Being able to create high-fidelity prototypes of AR/VR will require knowing how to code to a certain extent. For instance, virtual reality is not an experience that can easily be prototyped without knowing some amount of code.
So with all of these arguments for learning how to code, I will now explain why I decided to take front-end development out of the Designation curriculum.
Designation’s Identity
One of the main considerations that factored into this decision had to do with the positioning of the bootcamp, and who it was for. Designation is a UX/UI bootcamp based in Chicago, that once marketed itself as a full-stack design program, with “full-stack” meaning UX, UI, and front-end development (FED). The concept was to develop T-shaped designers who would have a broad understanding of different disciplines with a deeper focus on one.
The term T-shaped was first coined by Tim Brown of IDEO. He described a T-shaped person as someone who has the ability to collaborate across disciplines and “possesses a depth of skill that allows them to contribute to the creative process”. In the context of Designation, this meant training our students in the fundamentals of UX, UI, and FED, but allowing students to cultivate a focus on one of those 3 disciplines.
In practice, this was accomplished by having students spend the first 10 weeks of the program, which included an online component, being exposed to all three areas, and then allowing students to choose a specific area of specialization, which they would then gain additional practice through a series of live client projects.
The Wrong Bootcamp
The role of learning code, in my mind, was always in service of learning how to become a better designer. However, in every cohort, there were roughly a quarter of the students who joined the program because they wanted to become programmers. This was always a curiosity to me, because it seemed odd to join a design bootcamp to become a developer. It seemed that attending a coding bootcamp would be a better fit. However, one of the factors that led to this phenomenon was cost.
In the early days of the program, some students came to Designation, because it was cheaper than attending a true coding bootcamp. At that time, the tuition for Designation was much lower, over half as much as development bootcamps, and so it made sense from a purely economic standpoint for some of these students. Unfortunately, Designation wasn’t a coding bootcamp, which made it ill-suited to help students become professional developers.
When students joined the program with the aspiration to learn code, they often came with little to no programming experience. And even worse, they didn’t have a math or science background either. This meant that their journey to learn code would naturally be longer and harder. It is no accident that the best development bootcamps in the country try to focus on admitting students who have at least a basic understanding of programming.
Hack Reactor has a whole prep that precedes being admitted into their software engineering program, because they understand that to be employable as a developer, one needs to know more than the basics of code. They need to have a deeper understanding, and Hack Reactor spends over 12 weeks preparing their students. And their students aren’t starting from zero.
So in the confines of Designation, it was very unlikely that someone with no programming background could join the bootcamp and learn enough front-end development to become a professional developer. Having studied computer science myself, I know that there are a plethora of concepts that I can barely delve into in just 12 weeks, let alone when those 12 weeks are shared with UX and UI. Some of those concepts include logic, data structures, algorithms, databases, patterns, networks, programming languages, and much more. At my most successful, the furthest I ever got with my students was to scrape the surfaces of gitHub, HTML5, CSS3, Bootstrap, responsive design, LESS, jQuery, and jSON. I was never able to reach topics like MVC patterns, object-oriented programming, cross-browser testing, command line interface, and more.
These advanced concepts that would make someone qualified to be a front-end developer was always outside my reach as curriculum director, because of time. Evenly dividing the course between three disciplines meant that I would only have a third of the time free for teaching code, which was around 2 to 4 weeks, and frankly speaking, it wasn’t enough.
Based on my observation, only one to two students every cohort succeeded in achieving enough proficiency with programming to pursue development. And the ones that fared the best always had studied coding prior to joining the bootcamp. It was time to make sure that students didn’t join Designation for the wrong reasons. For me, this meant removing front-end development as an area of specialization. But you may be thinking that this still doesn’t address the question of removing coding from the whole program. If understanding code is such a competitive advantage, why not leave some of it in the curriculum. Maybe it would be sufficient to give exposure to the basics, like HTML and CSS. Well, the short answer is we tried that. However, this still presented some other key challenges.
Expanding Digital Landscape
In this rapidly evolving digital landscape, the stack of technology that one needs to be familiar with is constantly growing. For instance, designers today need to know not only how to create responsive designs, but also how to design for other mediums, such as native mobile apps, TV, wearables, the internet of things, AI, virtual reality. The list goes on.
The programming languages used for each of these mediums are different. For example, if you’re trying to learn how to code for mobile apps, then this will depend on whether you’re trying to program for Android or iOS. If it’s Android, then you have to learn Java. If you’re trying to program for the iPhone, then that may mean learning Swift or Objective C. It’s no longer sufficient to learn HTML and CSS when it’s no longer about designing for the web alone.
The landscape is broader and more complex now. The shift to mobile over the last 5 years has been undeniable. To adapt to this sea change, we began to shift the Designation curriculum more and more towards mobile and app design. This meant that covering HTML and CSS wasn’t as relevant as it once was. It’s more important to master prototyping tools which help visualize and communicate the interaction model for designs than it is to learn how to program them.
The Rise of Prototyping Tools
In the past, there were only a handful prototyping tools that were widely used in the industry, such as Axure and iRise, and these programs were very expensive and had a high learning curve. But now, the world of prototyping tools has finally come of age. There’s more options available now than ever before, with each serving a different purpose and each helping to produce a different level of fidelity. InVision has made visualizing user flow simpler and easier to create. Tools like Origami, Framer, and Proto.io make creating intricate user interaction models relatively straight-forward with minimal programming skills. For low fidelity paper prototypes, there’s POP. If you’re trying to represent complex microinteractions and animations, there’s Principle and Flinto. Admittedly, this is a fragmented landscape, but what can be achieved now without knowing how to program is truly incredible.
While the learning curve for these programs vary, they are overall easier to learn and master than learning how to develop a product with a programming language. And at the end of the day, it’s far better to build a high-fidelity prototype that can be user tested, validated, and documented for hand-off to a developer than it is to invest a large amount of time trying to become conversant in programming.
The disadvantages for learning how to code for a designer is that it will take a lot of time and energy to become proficient. And then it may still not guarantee that you will be able to achieve the effect or functionality that you are envisioning. Moreover, even if you did end up mastering that skill, the technology landscape is constantly shifting, and requires a continual commitment to stay abreast of those changes. In the past, people used Backbone.js for front-end development, then it became Angular.js, and now, it’s React.js. Staying on top of these trends ultimately distract from what should be the main focus of a designer, which is mastering design. There is more than enough skills that a designer needs to perfect to keep them busy without having to learn coding on top of it.
Skate to Where the Puck is Going
Just as the digital landscape has been expanding, so too has the skills that a designer needs to learn. In the early days of the web, it was enough for a designer to know Photoshop, HTML, CSS, and basic Javascript, and be able to get a job. However, with design becoming increasingly commoditized and outsourced, the modern designer must expand their toolkit. This means acquiring skills beyond just visual design and web design. Designers today must understand user research, strategy, product design, user testing, information architecture, UI patterns, analytics.
To be competitive these days, a designer must understand business goals, how to communicate with stakeholders, how to facilitate a workshop, how to collaborate with developers. There’s hard skills and soft skills that a designer must be equipped with. In recognition of the importance of these vital skill sets, I had to make room in the Designation curriculum to allow students to have the opportunity to develop them. Time was an intractable constraint. With 18 weeks for the whole program, I had to consider what was more vital to my students’ success.
One of the guiding principles that I have always used for iterating on the Designation curriculum was thinking about where the industry was heading. Wayne Gretzky is famously quoted as saying, “I skate to where the puck is going to be, not where it has been.” The program needed to look ahead to the future and adapt accordingly.
Depth vs Breadth
My final reason for taking out front-end development from the Designation curriculum is that I wanted my students to become true T-shaped UX/UI designers who possessed a deep understanding and proficiency in one discipline. One of the unintended consequences of having a program that offered more than one area of focus was that students didn’t know what to specialize in. It was a paradox of choice. Many students found themselves paralyzed by the choices. They didn’t know if they wanted to become UX designers or UI designers or product designers or web designers.
Our students became crippled by the options, and because of this, they naturally wanted to hedge their bets. They wanted to be able to do a little bit of everything; in effect, becoming masters of none. When the students struggled to learn code, those disillusioned students turned their attention to UI, but when a few of them realized they weren’t very good at that either, they decided to major in UX. Unfortunately, by this point, these students hadn’t cultivated a deep knowledge of that as well. By taking out coding from the bootcamp, it forced our students to be more deliberate about their area of focus. It took away one more potential source of distraction.
Also, by removing coding which had previously taken up to a month of time in the program, I was able to spend more time on concepts important to UX and UI, such as user-centered design techniques. In the past, I was only able to spend one day on design thinking. I had one day for user research. I had one day to teach user personas, and because of that, the content was always artificially constrained and limited. For instance, the day-time exercise for user modeling was creating proto-personas and not high-fidelity personas based on user interviews, because you need time to conduct user research in order to be able to make informed personas.
By freeing up 4 weeks of the program, it allowed me to restructure the program around learning how to conduct user research in the context of a practice project. I was able to include more time for information architecture and learning prototyping tools, and even beyond that, introduce soft skills workshops like how to work and communicate in a team environment. Many students would ask me if the program could still be considered full-stack after this change. And my answer is yes! The full-stack now spans a different array of knowledge but it continues to be based on helping students be T-shaped designers who can collaborate across disciplines. It just so happens that development skills have been replaced by interaction design skills like wireframing and prototyping.
Key Points
So to review, in today’s complex digital landscape, coding is more multi-faceted than merely learning HTML and CSS; and prototyping tools have become more robust, which take away from the need to learn coding. And there’s skills that a designer must learn beyond visual design that requires more attention than learning how to code. And finally, designers need to choose an area of specialization and commit to cultivating an understanding of user-centered design techniques, interaction design skills, and soft skills.
With all that said, I’m still a believer in learning to code, but for a starting designer, my advice is to learn the key skills most relevant to being a UX/UI designer first, and then to decide on if they want or need to learn coding afterwards. Ultimately, it’s a question of timing. Rather than trying to learn everything at once. It’s best to focus on the key skills first. One might say the 80/20 skills; the 20% of the skills you’ll use 80% of the time. And when looked at it through this lens, coding is a skill that can be saved for another day. My core 20% skills are user-centered design, interaction design, and soft soft skills.
References
For additional reading related to this topic, I would suggest checking out the following articles:
- Designers shouldn’t code. They should study business.
- Why designers should stop coding (written by a unicorn)
- My Thoughts on Unicorns in the Mystical World of UX
- Unicorn, Shmunicorn: Be a Pegasus
- Hiring a designer: hunting the unicorn