I know I talk about this often but, though I no longer mentor, my foray into mentoring has been a source of a lot of contemplation for me concerning product design, as an industry.
Commonly (particularly during introductions), I have heard from pre-career mentees that they believe they have what they often refer to as “transferrable skills” (or “relevant experience”). Roughly, here are some quotes to illustrate what I mean: “I come from a psychology degree, and I know psychology is important in UX.” Or something like: “I come from customer service, and so I know how to be customer focused, how to help people and give them what they want.”
Sometimes, they’re just introducing themselves. Other times, they are asking me how to play up up their background in their resumes and personal sites, in hopes that hiring managers may see and appreciate their transferrable skills (hopefully giving them a leg up against other pre-career candidates). Still other times, they may say this to me so as to convince me to take them on as regular mentees—as a way to show me they are serious enough for me to pour my time into.
I appreciate the situation a pre-career designer may be in, and I understand why these claims are made. I also know that they hear these arguments frequently from people who appear to be experienced. That said, I think these assertions they hear can be quite misleading, and is an example of the way people in the industry (or people who satellite it) can, at times, be a source of misleading information and unrealistic expectations.
What do people mean by “transferrable skills”?
To provide additional context, mentees are likely hearing the messaging that there are other industries, degrees, or certifications that can prepare them for a life of building software. This likely sources in the majority from people who want to be helpful—I’ve frequently seen advice in LinkedIn discussions given to pre-career designers that there are skills they can emphasize from their previous jobs or careers to help them get an edge on the market.
As is frequently said, the advice usually sounds like: “just because you have never worked as a designer doesn’t mean you have relevant experience! Look deep into your job history and talk about those relevant skills.” As a result, I hear many pre-career designers from customer service backgrounds, for example, argue that “knowing what people want is part of my job.” It is also commonly believed that psychology and empathy are important aspects of being a designer of software, which likely explains why I hear from mentees with psych degrees that they feel confidently they have an edge.
career changer ux design transferrable skills, I see a few results return. Going down the list, from UX Design Institute:
If you’re considering switching careers to UX design, you might be feeling some doubt or imposter syndrome. Are there specific careers from which you can transition into UX easily? Will I be able to get a job without any UX experience? Lucky for you, we have created a UX transferable skills checklist to help you make up your mind.
The list goes on to include:
…[S]witching to a UX design career still feel very daunting. As well as the promise of future rewards, there is also a sense of risk and unpredictability. Something else we hear about a lot is the fear of “wasting” prior education and work experience.
However, there’s another way of looking at things. The experience you bring from your previous career will almost always be an asset as you begin switching careers to UX design. Transferable skills can come from all kinds of fields, from marketing to management.
Your existing skills not only mean that you’ll have a head start in your UX education; you’ll also have a lot to boost your resume when it comes to hunting for that first UX design job.
The list goes on to include:
Collaboration and leadership,
Wireframing and prototyping.
Or from Coursera:
Attention to detail,
And so it goes. One observation, however, is that there seems to be disagreement among the sources about exactly what these transferrable skills into design are said to be—there’s a lot of variation between them. Another observation is that the vast majority of the transferrable skills listed are soft skills.
What are the actual skills needed to compete on the market for product design roles?
The best thing someone can do to get hired is determine what knowledge gaps there are standing between them and their target job, and then fill those gaps. To do this, I would recommend that they start at the end. For example: do you want to work in the tech industry? If so, it’s a good idea to figure out what the tech industry tends to watch for (generally) in its hiring pipelines, and then work backwards from there.
In general, tech companies have two baseline requirements, and the standards get higher on these two as the designer gains more experience:
Designers need to be able to reason about some software from start to end, and build software that makes sense for most users (some people call this “UX design”),
Designers need to be able to make whatever software they make look professional (some people call this “UI design,” or “visual design”).
In the context of hiring pipelines, these are evaluated usually through a personal site demonstrating around three pieces of software that the pre-career designer has made. Without this, the probability of a hire goes down to almost zero. If the portfolio does not demonstrate that the designer can do the two things above (make software, and make professional looking software), then that probability of a hire also hits almost zero.
These two skills above imply various finer points, specifically the following, however:
You understand some baseline of how software works (e.g., you understand that elements in a view can be programmatically generated and dynamically changed),
You understand what the internet is (e.g., you understand that pulling and pushing objects up to a service is a required action in any internet service),
You understand how to open up Figma—drop in images and SVGs, press R for rectangle, T for text, and so on,
You can produce designs that look professional, aesthetically,
You can make a personal website that looks professional and attractive, and you can reason about why you’d want to make some software, why you believe users would want it, and show exactly how it works (see using Figma above).
These are hard requirements—in the words of a dear friend (also a recruiter who I worked with at a certain Bird App): “if you can’t make software, I can’t hire you.”
The articles above emphasize soft skills (e.g., “teamwork,” “collaboration,” “listening,” etc.), but soft skills are not likely to put someone in a position of a differential advantage when job searching—this is considered a baseline requirement of virtually every job, not just ones in tech. In tech companies, we need to see your technical skills, or no deal. Because the expectation of professionalism exists in every professional industry, it wouldn’t be accurate to consider this “transferrable to design.” It’s a requirement everywhere.
Going down the list of the suggested transferrable skills:
It is expected that every human being be capable of abstract thought on the condition of seeking employment.
It is expected that every human be able to consider the perspectives of their colleagues and associates on the condition of seeking employment.
It is expected that every human be able to engage in written human language on the condition of seeking employment in skilled roles.
Product research is not a product design role—the hiring pipelines, pay bands, expectations, day to day tasks, reporting structure (usually), etc., for researchers are completely different to design roles. A company might expect a designer help out with some usability tests or, more rarely, ask a designer to set up A/B tests for some new flow in a feature (usually done by data scientists), but these would usually be one-off expectations.
It is expected that every human be able to work with other humans on their team on the condition of seeking employment.
It is expected that every human be able to work with other humans on their team on the condition of seeking employment.
This stands out as a listed skill that is not a soft skill. This is a very large bucket, and not many other roles can confer these needed skills.
Making software requires you have some knowledge about how software fundamentally works, which you can get if you come from engineering. Some related roles—like data science—can help with that, too.
Learning how to make professional (read: attractive) interfaces can come from being a very skilled graphic designer (either in name or in function). Graphic designers exist to make surfaces (e.g., websites, posters, zines, magazines, etc.) look beautiful, and some graphic designers are very skilled at this.
According to the article that lists this as a transferrable skill:
UX designers don’t have to add images and colours.
Yes, they do. This is a common misconception sourcing from more dated understandings of the industry. It continues:
While you might not have the exact visual design tools or skills yet, you probably know colour theory, visual hierarchy, branding, typography, white space and element placement if you’ve done any visual design. That might be from a graphic design job, Adobe Creative Cloud classes, marketing, photography or another artistic job you’ve done.
One can be a very skilled architect, photographer, or painter and make beautiful domiciles, photos, and paintings, respectively, but there’s no correlation between these skills and the ones involved in making a beautiful layout. For example, it’s very common for students in art school to switch majors—e.g., an architect switching to graphic design. Those students transfer in and tend to be at the absolute bottom of their class (read: unable to meet expectations around aesthetic beauty) for this exact reason. Making an attractive structure is a very different practice to making an attractive layout.
This stands out as an example of a skill in these lists that is actually not a soft skill. At tech companies, people call this “product thinking,” and is an axis on which designers (and product managers) are evaluated.
Understanding basic economic principles (e.g., incentives, what a market is, the concept of “ROI,” etc.) can be useful when working in tech, regardless of one’s role. For example, for product managers and designers, understanding what your customers are likely to find most important in their decision to use your product, and then prioritizing future feature work accordingly is a question of understanding incentives. Deciding what to work on (“prioritizing”) is a question of opportunity sizing, as well, meaning that there’s some regard for ROI—the projected impact of some new work.
But understanding businesses, markets, and products on a base level can also help you decide which companies you’re most interested in (e.g., selling to consumers versus other businesses; working on a product that’s core to the businesses’ priorities versus just one aspect of how they generate revenue; etc.), and also helps you on the job (as mentioned above, for one example).
What’s more, in the context of hiring, it can help you determine what products you want to build into your portfolio, so that you design software that is genuinely compelling to your potential customers (e.g., companies you want to work for). This helps you get jobs, because you know not to show up to interviews with software no one will ever want—but rather with software that is compelling, plausible, and interesting. This makes you stand out from other candidates, who generally have work from their design programs (e.g., bootcamps and universities) that are implausible and demonstrate not a lot of product thinking.
As a result, having some understanding of how businesses work is useful—notice, however, this is not a soft skill. Developing an understanding of businesses, markets, and products requires some time and effort investment to develop.
Lastly, merely getting a business degree will not necessarily confer advantages in one’s ability to understand software businesses and products, specifically. Making successful software products is very different to other business models, and can be difficult to grasp for people who have not spent time making software. Managing a hotel is very different to selling software as a service. As a result, unless the individual has worked in a finance role at a tech company before (or is interested in software businesses and how they operate as a hobby), this cannot be said to be a “transferrable skill.”
It is expected that every human be able to communicate with other humans on their team on the condition of seeking employment.
It is expected that every human be able to relate to other humans on their team on the condition of seeking employment.
It is commonly said that “empathy” is needed in product work. I haven’t seen that this is true in my seven years, so I would disregard these claims. What’s more, I would need evidence to believe that working in any one particular industry is likely to make humans more or less effective at reasoning about the feelings of others.
Just build software you think makes sense, and then make it look professional. Empathy is not specifically required, and I don’t think there’s clear evidence that any specific role can confer it more than others.
It is expected that every human be able to demonstrate leadership (e.g., taking responsibility, being proactive, etc.) in their roles on the condition of seeking employment.
Most roles at tech companies are IC roles, and most people will spend most of their careers being ICs, so this is not required. Others may expand the definition of the word “management” to include being able to demonstrate leadership, so see above.
Wireframing and prototyping
This is not a soft skill. Firstly, most designers do not wireframe—this used to be common in more dated software companies (e.g., through the use of Axure or Balsamiq), but this is not common practice. So far, I’ve yet to work at a tech company where any designer ever makes the traditional “gray boxes,” so the first part of this skill can be disregarded.
When it comes to prototyping, this can get very complex. For most roles, you’ll never need complex prototyping, and simple screen design software like Figma (and its prototyping) should get most designers all the way there. For more complex interaction work seen in complex, gesture-based products (e.g., Apple’s mobile and desktop OSes, Google’s mobile OS, Instagram Stories and Reels, TikTok’s video editor, FigJam, etc.), those more complex interactions need to be modeled out, and it’s the designers who are going to do it.
At a certain camera app company, we use Origami to do these. It’s visual programming, and so that level of complexity is very high. At a certain Bird App company, I didn’t frequently have a need for complicated prototyping (nor did other designers), and so complex prototyping was atypical.
Figma’s prototyping is very easily acquired (a tutorial of a few minutes should do just as well for most people), and no other roles outside of interface design can help acquire this, so this would not be a “transferrable skill.”
It is expected that every human be able to solve issues that come up as a function of their daily work on the condition of seeking employment. What’s more, solving problems in the context of building software is very different to solving problems in other contexts. One must understand software fundamentals (what a codebase is, what programming is, what an app is, basics of how the internet works, etc.) in order to determine what workarounds might be necessary when working on a product and a constraint is hit.
It is possible to solve problems when working as a sales associate at a fast fashion company. But solving problems in software is a very different situation. In my experience mentoring over eighty people, I have yet to see someone who’s worked outside of software be able to easily reason about how some software ought to work—this is not a reflection on those eighty people, but rather demonstrates that working on software is not the same as working on other areas. It requires domain-specific knowledge—just “solving problems” is not enough. Without working in software, there’s no other way to acquire this. This would not be a “transferrable skill.”
It is expected that every human be able to adapt to changing conditions on the condition of seeking employment.
Attention to detail
It is expected that every human be able to put the time and effort in to sweat the small stuff of their work and make sure it’s within a reasonable margin of error on the condition of seeking employment.
Software roles are highly technical—as mentioned, the currency of tech companies is technical ability, so my advice to mentees is to focus less on trying to make one stand out via soft skills, and spend all of one’s time building a beautiful portfolio website, filled with two to three stellar pieces of software that just make sense. Again, these are your two areas of focus:
Make good software (software that users actually want, and software that is pleasant to use),
Make professional looking software.
Wrap these in a beautiful and unusual portfolio, and this is the optimal way to get hired. There’s no better use of a designer’s time. Very talented graphic designers may have great visual skills, which would constitute a transferrable skill, but that might be as far as one can expect to go with transferrable skills.
Tech companies are unusual in that they are among the most merit-driven companies—the interview processes are very rigorous, and hiring panels make their decisions based on the quality of one’s portfolio of software. Hiring panels do not evaluate for certificates or degrees (in fact, most people on your panel probably will not even read your resume deeply enough to recall where you went to school, if at all). If the work isn’t there, no amount of soft skills, networking, and etc., can make up for that.
Design programs (e.g., bootcamps and universities) tend to misrepresent the technical requirements required of designers. It’s not clear to me why this is this so common—one explanation could be that the people who work at bootcamps and universities tend to never have been designers, themselves, so they may have significant distortions of what being a designer at a tech company is like. The more cynical explanation could be that underselling the importance of hard, technical work in these careers may be a customer acquisition strategy—people are lured in by tech salaries and low requirements, only to realize upon graduation (with few job opportunities) that the requirements are quite different to what their programs led them to believe.
Based on my experience mentoring eighty people across all sorts of bootcamps (e.g., Designlab, Springboard, etc.), universities (e.g., UMich, CCA, etc.), and online courses (e.g., the Coursera course with Google branding), it’s not a great investment to index into the advice these programs impart, as there are too many distortions in how they represent the requirements of design roles—they tend to overindex on soft skills. I would advise mentees spend all their time building two to three great pieces of software, represent those in a beautiful portfolio, and then start applying to places. Resume-hacking is probably not a great use of one’s time (recruiters and hiring panelists tend not to read these). Again, in the words of a very dear, tech recruiting friend: “if you can’t make software, I can’t hire you.”
Thanks for reading Internet Grill! Subscribe for free to receive new posts and support my work.
Reading this was actually really fun and at the same time very insightful! Thank you for that. I am curious about the idea of creating software and even creating software that helps people. When you say creating and building, do you mean actually create the software as a whole? If I am not mistaken you mean designing the software to look good and has value to users using right?