This is also a follow on from a previous article that I wrote about the changes that have taken place within Skyscanner since I joined. You can read that article here:
Unicorn? Full-stack? Should you bother?
It seems so many designers are fraught with this decision of whether or not they should be learning this, or that, or venturing into lands unknown to fulfil the merits of their role as a UX designer, UI designer, Visual Designer, Front-end Designer…ach who cares, a title is nothing more than a string of characters — note the subtle code reference ;)
Designers should instead be asking themselves: “Am I doing the job that I am expected to do to get the most out of the team that I work with?”
Hopefully, anyone reading this who is currently working will have at some point gone through an interview to get into their current position. During the interview, it should have been made clear to you what the role was and what you would be expected to do. If this was not clear to you, I would question why you took the role, but I will leave the interview process discussion for a future blog post (watch this space).
Questions should have been asked of you, and you should also have reciprocally posed some questions to your potential employer to be certain that you met their requirements for the role, and that they could offer you what you wanted from the position. In essence, you are hired to fill a gap within a company and you should take on a role to also fill your own personal gaps.
This is not to say that your role cannot change (which it inevitably will) but the reason it should change is that it needs to change. This is the key thing that I want to address. Over my many years in the design field, I have practised an array of disciplines: exhibition stand design; product design; visual design; front-end design (HTML, CSS, JS); prototyping; animation and am now briefly touching on native app front-end design (if that is even a “thing”).
Before you drop your cup of coffee and think, “whoa, who is this guy and how does he manage to do all this?” The simple answer is that I don’t do all of the things all of the time. I mentioned earlier the keyword, “need”. In order to deliver on some projects someone needed to step up and pick up an aspect of design to get something out the door. If I felt I could be that person, and developing that skill was of interest to me, I would pick it up and run with it.
Smashing plates
To pick up on a past analogy of spinning plates, a designer (whether UX, Visual, Product, or Web…) typically has to be spinning at least a couple of plates. A Visual designer should be spinning the “principles of design plate” along with a “typography plate”, a “Photoshop plate” and perhaps an “Illustrator plate”. A Web Designer should be spinning “HTML, CSS and JS plates” along with the “principles of design plate” and say a “Sketch plate”. The analogy goes that if you don’t keep spinning each and every plate the ones which are neglected will inevitably fall and smash (in this case, your skill will be lost).
I can confidently announce that my Flash plate was smashed many years ago, and to this day remains in pieces on the floor. But this is OK. My need to learn and use Flash diminished as the web progressed. I would have been wasting my time had I continued to invest time and effort in developing that skill.
I often feel at times that my Visual Design has not kept pace in the way that I had hoped, but this too is OK. There are only so many hours in the day and we should not be so hard on ourselves to try and be experts in everything, all the time. The Unicorn term could not be better suited as a reference to the types of designers we sometimes feel we should be. Unicorns do not exist (just in case you weren’t sure)and neither do designers who can do everything all of the time and to the highest standards.
You mentioned a “gap”?
Yes, I did. This gap is one that you should identify within your current team. Look around at who you work with. Maybe you are working with different teams on different projects. How is the makeup of those teams? Are they engineering-heavy? Design heavy? A good mix? What skills can you bring to each team, and which skills are missing that you wouldn’t mind picking up? This is what you should be asking yourself, and your team, not the dreaded question that appeared at the start of this article.
Communicate often and be honest with each other about your strengths, and also your aspirations. If your developer knows that you are interested in CSS, they may perhaps give you some resources to check out and mentor you on some aspects of a project. Maybe he or she would prefer to spend more time working on the back end and not having to worry about the CSS. You could both be doing each other a favour.
To ask the question “Should a designer code?” completely void of any context will only ever lead to a poorly fought debate. We need to be asking ourselves and our teams better questions, not wasting our time trying to answer this one.
So, I too agree that we should kill this “Should designers code?” question. Nobody should do anything which they are not needed to do or have no desire to do. I definitely feel that an understanding of the medium for which you are designing is a must, as discussed in Andrei Herasimchuk’s post, but that applies across any discipline. But let’s be clear that an understanding is a very different thing to subject matter expertise.
To go back to the interview reference earlier, if you are not interested in the coding aspect of design, don’t apply for jobs that ask for it. Or if it comes up in an interview, be clear about where you stand. If you are going to be working with a team of talented engineers who you meet with and communicate with regularly, chances are they could code up your designs quicker than you could even think about what term to search for on Google to get you started. Maybe this approach will work for you.
If however, you are interested in learning code to help develop your career and to have more meaningful discussions with the rest of your team, and perhaps contribute in ways you feel would benefit the wider team, then go for it. It won’t be easy at first, but with a good support network, anything is possible. I did it and would not go back, but I followed this path of my own choosing, long before it became a hot topic of debate.
Perhaps the project you are on just now is looking at redesigning a site. Maybe it’s using SASS as the CSS preprocessor, and you feel that you could jump in there and start building up a strong design system that would allow the developers to focus more on the logic and code structure — go and learn SASS. Perhaps your project is focused on improving the accessibility of a site. No one in the team is an expert in this and you are interested in the topic so you want to pick up some HTML skills, look at ARIA roles specifically and then test your changes in screen readers — go for it! See how using HTML5 and ARIA roles could benefit your project.
Looking ahead…
If in a year’s time, working on a different project, or within a different team (perhaps in a different company) you no longer need these skills, don’t be afraid to let the plate drop. Our industry moves so quickly that there is no concrete set of skills that will prepare you for every eventuality along the way, and some skills will inevitably become redundant as technology moves on. Learn what you need to learn for the project that you are working on today and don’t be afraid to drop redundant skills and pick up new ones as you go.
You will find that the “dropped” skills never truly leave you and that exposure to that skill will inevitably help to shape the way in which you think about, learn and apply all future skills, so nothing is actually wasted.
I am lucky to be in the position that I am in. Within Skyscanner, we are pushed to become masters of our own products and of our own decisions. We decide as a squad what needs to be done and when in order to meet the wider goals of the company. If that means that learning Objective C using XCode is something that I could benefit from, which could also aid the progress of the team, then I can go for it, pick up the skill and start applying it in current projects. If I move to a new project and need to focus on web skills, I can drop the Objective C stuff. I don’t need to maintain this unless, of course, I want to as a personal matter — but then that is my choice.
In essence, learn what you want to learn to aid the progress of your team and product for as long as it is useful and interesting to you.
I would love to hear your thoughts on this and learn how others learn and apply their skills depending on the roles and the projects on which they work, so please feel free to comment below.