What if there aren’t actually any specializations in design?
What if there aren’t actually any specializations in design?
In a previous article, I described the internal workings of a number of tech companies I’ve worked at over my seven years in the industry — these ranging in size from eight to eighty thousand employees, with products that have zero DAUs (daily active users) to 500 million.
My intent was to provide a portrait (as sincerely and clearly as I could) of how products are made at tech companies: how teams are organized, what designers get up to, how product strategies are made, and so on. Some designers may never have worked at FAANG companies before, while others may never have worked at tech companies with employees in the single digits, and so the opinion may provide an interesting look behind the curtain.
But I also wanted to document how I’ve worked and, by extension, how the designers I’ve worked with at these companies have also worked. This was for the purpose of building up shared context, with which I could then approach a question I don’t frequently hear asked: are there such things as specializations in product design at all?
I can explain!
I understand that the reader may be quite familiar with (and potentially invested in!) the debate over whether product designers should “specialize,” or whether they should “generalize.” Before detailing my perspective on this debate, specifically, I’ll detour to provide some context about the common positions in it (mainly for those who may not be familiar with this debate at all).
Why should one “specialize”?
With respect to a product designer’s career trajectory, it is generally said that there’s one major concern a designer ought to decide on at some point in their career: whether they should “specialize” or “generalize,” with people usually arguing for one over the other for various reasons.
Among those who believe designers should specialize, there are often numerous supporting arguments. From UXmatters, laying out benefits of specialization:
- You gain a lot of in-depth experience in your specialty. By focusing all of your time on either user research or design, you gain in-depth experience in one area. You’re able to focus on what interests you most.
- You get to work on the best projects for your specialty. Companies that choose to hire specialists are usually those that value both user research and design, and they tend to spend time and money on both of those activities. Companies with dedicated user researchers tend to allocate more time for research and trust researchers to innovate new activities. Consulting companies with specialist researchers tend to place a high value on user research. This attracts clients who also value and want to include user research on their projects.
- You have more time to focus on your specialty. Instead of being overburdened and stretching yourself too thin by trying to perform all of the activities of both user research and design, you’ll have more time to focus on your specialty.
- You become a rare and highly valued UX professional. As you gain more experience, you’ll become an increasingly rare and more highly valued UX professional. Although there are fewer specialist positions available, you’ll have much less competition for them. Plus, you can command a higher salary.
Why should one “generalize”?
This is the other side of the coin. It is said that, instead of specializing, one can generalize,— or choose to cast a wide net — allowing one to accumulate a lot of knowledge about a great many things. As is frequently believed, however, this comes at the cost of deep knowledge in any one thing in particular. Once again, from UXmatters:
- You gain more experience. As generalists, new UX professionals, who are just starting out in their UX careers, have the opportunity to gain a lot of experience in both user research and design.
- You have more career opportunities. Because many companies combine user research and design into a generalist position, there are far more job opportunities open to generalists than to specialists. So generalists have more career options and mobility.
- You experience more variety. Generalists experience a wider variety of activities. When user research begins to get boring and repetitive, they can move on to design. As multiple wireframe iterations begin to get tedious, they can move on to usability testing.
- You experience the user research firsthand. While specialist designers may or may not observe all the user research and usability testing sessions, generalists conduct the user research and usability testing themselves. Through their firsthand involvement in the research, they can internalize the findings more deeply and then are better able to apply that knowledge to their designs.
- It’s easy to become a specialist later. It’s far easier for a generalist to become a specialist than it is for a specialist to become a generalist. Generalists can choose to specialize in one of their areas of expertise, but specialists usually lack experience in one or more of the tasks that generalists must perform.
As is the case above, I’m sure that there is more that can be said about the arguments for this position and, as always, the reader is encouraged to check out these (and other) sources to learn more about the commonly cited, different angles in this debate.
Separately, I’ll also add that, in my seven years, I cannot recall a situation wherein an individual has argued specifically for generalization over specialization — personally, I have only ever seen arguments in favor of the latter. My impression is that this is a common perspective.
Back to what you came here for
With a shared understanding between reader and author concerning the arguments broadly made for specialization or generalization, respectively, in product design, the reader may be wondering why I do not appear to be arguing in favor of one approach or another, as is typically done. I do this for a few reasons. To start, however, I think it’s instructive to talk about what the specializations are said to be at all.
What are the available specializations in product design?
Searching “ux design specialize,” multiple results return. Just going down the list of those results, starting with Career Foundry, some specializations are listed (quoting from the source):
UI design,
Interaction design,
Information architecture,
Visual design,
UX research.
From UXmatters, the quoted specializations include:
User research,
Interaction design,
Information architecture,
Usability testing,
Visual design,
Front-end development.
From Invision:
UX researcher,
Information architect,
UI/UX developer,
Usability analyst,
UX writer.
Right, so I think the reader can see some interesting patterns developing here: despite how authoritatively each source speaks, it seems none of them can agree on exactly what those specializations are. This seems important — I think many might agree that, if one is to successfully argue for specialization or generalization, one should be able to agree on what those specializations are in the first place.
There are other problems with these lists, though: not only do the listed specializations not agree with each other, but some of these roles don’t even exist — or are not specializations of product design at all. Just going down the titles provided above:
UI design. As stated in my previous article (mentioned above), I detailed how tech companies do not hire UI designers. We hire product designers that are expected to execute on the product to a high level of craft. Having visual excellence is considered a baseline expectation on the market. Some companies have higher standards than others when it comes to visual excellence, but some level of excellence is still considered a minimum requirement of the designer role across all tech companies. A minimum requirement is not a specialization, and you cannot specialize into a role that doesn’t exist, given that tech companies do not hire for them, exclusively.
Visual design. Visual design and UI design are interchangeable phrases in tech, so see above. More rarely, a company (e.g., Google) hires for a title like “visual designer,” but this is not a product design role. You cannot specialize into a role that doesn’t exist. Visual designers at Google, for example, are people are who are hired to perform tasks like (but not limited to): making icons (illustrators), making product imagery (illustrators), doing branding work (graphic designers), and other visual work on creative (read: non-product) teams at tech companies. This is not a product design role, so it is definitionally not a specialization of product design.
Interaction design. This is just what product design fundamentally requires one do. When one is hired to design products at tech companies, one is expected to open up Figma and plan out how the proposed software behaves based on various user inputs. This is the minimum, floor-level requirement to perform this role. If one can’t design interactions (e.g., “user taps this, this other thing happens”), then one cannot work as a product designer. A minimum requirement is not a specialization.
Information architecture. Tech companies do not hire “information architects.” Like with visual design, designers at tech companies are expected to be able to design screens that simulate viewports in native and web apps, and place elements within them in a way that would make sense for most users when quickly scanning and parsing. A minimum requirement is not a specialization. You cannot specialize into a role that doesn’t exist.
UX research. This is not a specialization within design, but a completely different role. The hiring pipeline for researchers at tech companies is completely different to the ones for designers — they have totally different promotion expectations, pay bands, managers, cost centers, reporting structures, and so on. Small companies may hire designers that can help pick up these tasks, but this is still just a designer who is flexing to help with coverage. A completely separate role is not a specialization.
User research. See above.
Usability testing. Usability testing is something a researcher (or anyone else) does while doing research work. This is not a specific role, but an action one can take while working as a user researcher. A specific, narrow task only sometimes performed within a role is not a specialization.
Usability analyst. This is not a role tech companies hire for. You cannot specialize into a role that doesn’t exist. Depending on what this analysis entails, this is not a specific role, but an action one can take while working as a user researcher. A specific, narrow task only sometimes performed within a role is not a specialization.
Front-end development. This is not a specialization within design, but a completely different role. This is an engineering role. The hiring pipeline for engineers at tech companies is completely different to the ones for designers — they have totally different promotion expectations, pay bands, managers, cost centers, reporting structures, and so on. Rarely, designers may become interested in engineering and pick this up on their own time (this is true in my case, as well). I would highly recommend this, but this is not a specialization of design. A completely separate role is not a specialization.
UI/UX developer. This is a title variation on the role above, so see above. Some companies have a few, rare roles called “UX Engineers.” Again, these are specific kinds of front-end engineers — not designers. A completely separate role is not a specialization.
UX writer. This is not a specialization within design, but a completely different role. The hiring pipeline for product writers at tech companies is completely different to the ones for designers — they have totally different promotion expectations, pay bands, managers, cost centers, reporting structures, and so on. Small companies may hire designers that can help pick up these tasks, but this is still just a designer who is flexing to help with coverage. A completely separate role is not a specialization.
The sources above don’t seem to agree with each other, and most list specializations for design that either don’t exist, or are fundamentally not specializations at all (the most egregious including listing engineering as a design specialization!). These sources, therefore, have fatal problems in their assertions and understandings of product companies, — and technology — more generally.
For what are probably obvious reasons, by contrast, specializations in engineering are usually more broadly agreed upon. For instance, in engineering at tech companies, there are these common specializations:
People who work on the client (e.g., iOS, Android, and web — unless using something else, like React Native or Flutter),
People who don’t work explicitly on the client (e.g., backend engineers, so people who focus on building APIs and other infrastructure, etc.).
At smaller companies, engineers might be expected to work across client and infrastructure, both (the reader may have heard of the term “fullstack,” for example), but you won’t find engineers expected to make PRs in Java codebases (Android), and then also expected to pull up the company’s Swift codebase (iOS) and push out the equivalent feature there, and then another one in a web codebase.
If you work at a small company, these tend to either focus on one platform at a time (iOS is a common choice in Western markets), deprioritizing other platforms (e.g., Android, etc.). Or they might use something like React Native or Flutter — these require web or C++ engineers, respectively.
However, some people argue that specializations in design don’t occur on the title level (e.g., “researcher,” or “UI designer,” etc.), but on the industry level. For instance, some argue that there are designers who are most optimized for different kinds of product industries: fintech, healthtech, femtech, etc., and that these product areas are specializations, themselves.
Interestingly, no other roles are segmented this way. For example, copywriters at Twitter (a blogging app) have the same responsibilities as copywriters working on Chrome (a web browser).
Engineers are also not segmented this way, despite that an engineer working with patient data (as in a healthtech company) would have to deal with the complexity that HIPAA (federal heathcare legislation in the States) tends to introduce. There are no “healthtech engineers” — there are just engineers who, due to various circumstances, currently work at companies that make technology for the medical industry. Then, one day, these same engineers will pack their bags and move over to another company, frequently to one in a completely unrelated product area.
There’s a reason why the engineering hiring pipeline at Coinbase (a crypto trading service), for example, is virtually indistinguishable from the engineering hiring pipeline at Meta (a social media and ads service) and Slack (an enterprise IM service) and Medium (a web-based blogging service). The reason for this being that these companies agree that engineering is engineering — no matter what company it’s done at, and no matter what product is being made. Likewise, hiring pipelines for designers at Coinbase, Meta, Slack, and Medium are also virtually indistinguishable for the same reasons: these companies all take this exact position with respect to design, as well.
Back to basics
Certainly, there appears to be disagreement among those who accept that specialization or generalization in product design is possible — mainly around what the specialization even is. Before jumping into my perspective on one side or another, I want to talk about what both sides of the argument (“specialization versus generalization”) assume to be true:
Product design, like being a surgeon or a developer, has a high enough ceiling of complexity such that specialization is needed,
Specializing is seen in other industries (e.g., surgery, etc.) — so, too, is it required in product design,
In other industries, specialization results in higher compensation — this is true in product design, too,
Tech companies specifically seek to hire product designers who are specialists and generalists, respectively.
I do not agree with any of these assertions.
Product design isn’t surgery
As mentioned, the argument for why specialization or generalization is needed in product design is typically done via comparisons, mainly to other industries (like engineering, medicine, surgery, etc.). However, I think this comparison is not appropriate — what is generally true for one profession or role is not necessarily true for another. Product design is far too different to the other industries and roles it’s frequently compared to (surgery being the classic example).
Going on the example of surgery: there are many organs in our bodies that are wildly and unrecognizably different from each other, such that a surgeon working on a heart would be completely incapable of impromptu working on a brain. Designers do not have this problem. Like engineers, they are expected to be able to be effective at the search engine company they work at this year, and then the social media company they work at the next.
What’s more, the margin of error when working on human bodies (compared to working on software) is extremely low — in some surgeries, there is virtually no margin of error. Designers do not have this problem, which means that the tolerance for risk by companies that employ us is just higher. Software and businesses can always be amended when a mistake does occur, — forever and ever — as long as there’s still enough money to keep the lights on. Humans don’t have this advantage. Once tissue is disturbed, it’s disturbed forever — no takebacks.
Given that organs are wildly different from each other, and the margin of error involved in working on them so low, specializations cannot be said to be nice-to-haves among surgeons — depending on the specific operation and the patient’s risk factors, a specialist may be required. In some cases, a generalist would be completely unable to render any services in any way — some legislation may also exist to legally bar them from rendering certain services, for example, which is also not a constraint that exists in the making of software. These restrictions occur because the law understands that body parts vary drastically — expertise in one organ system doesn’t at all suggest one has the capacity to work on another. This is not the case in product design (or even engineering).
Interestingly, however, even in surgery, — a context in which margin of error is extremely tight — becoming a specialist is neither common, nor always required, either. Generalist surgeons are the most common of all surgeons, and they are perfectly suited (and, in fact, frequently recommended) for most surgical concerns. They are a must-have, not a nice-to-have, in any nation’s medical system. Sending patients to specialists — when they’d be just as well with a generalist surgeon — taxes medical systems (incidentally, this exact issue is why PPO and HMO plans exist in the States).
More interesting is that, even among very narrow specialty surgeons, they have to be ready for a wide variety of reasons to be seen by patients — even among specialists, generalization within their area is still expected.
For example, oculoplastic surgeons (eye doctors who only operate on the structures around the eyes) may be seen for a variety of reasons. For example, some patients may need emergency surgery due to a severe and sudden onset of dangerous and life threatening bacterial infection in the eyes; some may be patients with glaucoma, thyroid eye disease, macular degeneration, and other long-term disabilities that tend to cause wildly different — and equally complicated — deformations of the eyes; some patients may have no diagnosis, but may be soliciting their services for purely aesthetic reasons.
And yet, oculoplastic surgeons are the best people to consult for all of these concerns. Specialist surgeons, doctors, and etc., still take on a huge variety of cases within that specialty — they absolutely must to be prepared to do so, or else they just couldn’t be considered to be very experienced. As mentioned earlier, a surgery as specialized as an orbital decompression can be indicated for many different reasons (from aesthetic, to medically necessary as part of rare eye disease) — and they have to be prepared for patients to consult them under any (or all) of these circumstances. To put this another way, when a patient comes in for an orbital decompression due to Graves’ related eye disease, concerns are both for functionality (restore functionality to the eyelids), and for aesthetics (return the eyes to their natural position in the sockets). Oculoplastic surgeons have to optimize for both concerns, as their customers care about both.
If even specialist surgeons have to be ready to take on a wide array of extremely varied cases and concerns when the risk to one of the most important sense (i.e., vision) to human beings is on the table, one can only hope that we can all have the strength of character and humility to accept that product designers can certainly manage to do the same — especially when our risk of failure is as low as it is (luckily for us!).
Product design is also not engineering
Within the context of these arguments, another common role product design is compared to is software engineering. I do not think this comparison makes sense within this context, either.
The only reason why tech companies hire Android, iOS, and web developers separately is because no human could reasonably be expected to have the fortitude to push out PRs for one feature across three codebases at the same time — each codebase with its own quirks, build pipelines, expectations around QAing, and etc.
It would be unreasonable to expect someone to even be able to type fast enough to do this within a reasonable amount of time — and also extremely painful and inefficient. It’s in the company’s interest to parallelize the work with a fleet of iOS, Android, and web developers picking up one feature and implementing it alongside each other at the same time in their respective codebases.
What’s more, the level of complexity in engineering is extremely high. It’s not just that engineers have to learn different technologies and work with a wide variety of tools they didn’t make (imagine working with five different Figmas, and each Figma has to integrate well with the next Figma in your toolchain, and pull information from the other Figmas in your toolchain, and send information from one Figma into another). It’s also that some kind of engineering is very different to other kinds.
For example, there are engineers that work in sandboxes provided by various platforms (iOS, Android, the web), and they build internet services on top of those platforms. These are comparatively easier to go between (especially between the native platforms), as they are in similar areas of concerns, and have very similar concepts. However, the engineering work that goes into the creation of these platforms is different than that which goes into making the software built on top of them — it’s a lower level kind of engineering, closer to the hardware, and so the scope of the concerns in this kind of engineering is significantly increased.
For instance, it is very common that engineers can feel comfortable working across web, Android, and iOS when working on personal projects. However, they often have their professional preferences, which is how they sort themselves professionally (for example, an engineer may feel comfortable making iOS and Android apps, but has most of his/her professional experience working on Android, so the engineer tends to mostly choose to interview for Android roles).
It is, however, not common that an iOS, Android, or web engineer pick up work on Vulkan or Metal (or vice versa), even in their personal time (or other lower level engineering of this sort). As engineers frequently quip when venturing into the world of graphics engineering (especially Vulkan): “it took me two weeks to figure out how to even render a triangle to the screen.”
What’s more, it is commonly discussed in software engineering circles that there’s a shortage of engineers who will take up the mantle of the more (what some might call) dated, lower level programming on which most technology today relies on (e.g., graphics, networking, etc.).
This situation I’ve described (it being too expensive to reasonably expect engineers to go between codebases in professional settings; it being too difficult to switch engineering areas; etc.) is a result of the fact that the ceiling of complexity of engineering is naturally very, very high. It is exactly this which attracts engineers to this role.
By contrast, you can be asked to onboard on to a company as a designer to work on social apps, or enterprise apps, or fintech apps, or use Figma (or, more rarely, Sketch or Adobe XD), and these are all easily interchangeable and routinely expected by companies (for good reason). In fact, it’s frequently argued within design circles that tools are “just tools,” and that a good designer should be able to use any tool and still output good design. For good reason.
Engineering is hard (which is what explains the compensation), but this is not explicitly why specializations occur. They occur because there’s just no alternative: no one can type fast enough to reasonably push out the same feature across three codebases within a reasonable timeframe. For example, despite their similarities, an Android engineer switching to working professionally on iOS is going to need a substantial time investment before they are able to be effective in the role at all; switching between different kinds of engineering (e.g., from app development to graphics programming, etc.) is also extremely difficult. It’s almost like restarting your entire career.
There’s nothing like this in design — the ceiling of complexity is comparatively significantly lower. Meanwhile, some argue that expecting one product designer to both be able to create well-reasoned, easy-to-use products while expecting that same designer make it look professional is unreasonable. As this argument goes, building up your reasoning capacity to reason through interactions in products takes away from developing your aesthetic skills — as such, these two things need to be separate roles. Despite this, tech companies have this expectation, anyway. Quoting myself from that previous article:
Tech companies do not hire “UI designers” — designers are expected to make good products, and make them look professional.
Quoting myself from another:
In reality, you do not get to choose whether you are a “UX” or “UI” designer in today’s market. This is an academic discussion about a market that no longer exists — a luxury belief. The reality is that you are going to experience increased difficulty finding — and retaining — customers as a designer if you do not make professional looking work. When FAANG companies hire designers under titles like “UX designer,” or “product designer,” or “interaction designer,” these are all the same jobs: you are planning out how some software will work. But there is an additional expectation — not always explicitly stated — that you will put in the effort to make the product or feature look professional. There will not be an attendant visual designer at your beck-and-call to jazz up your schematics. It’s just you.
Despite it taking time to get to a point where one can design software that works and looks professional, this is the expectation tech companies have — for good reason, as it is entirely possible to hit this bar, and thousands of people do it every year. If one wants to work at tech companies, one has to be ready to meet (or exceed) their expectations. By contrast, pushing out PRs across three different codebases for the same feature just is physically not a reasonable expectation. This is why these specializations in engineering exist.
In design, specialists are paid less
It is commonly said that specialists are paid more. In most industries and roles, this is probably true. This isn’t the case in product design, however. It’s commonly understood that designers who work on the brand side (visual designers, so not product designers) are paid significantly less than designers who work on the product. Even designers who specialize in design systems (i.e., design system designers) are frequently paid significantly less than designers who work on product.
While it depends on the company, in general, designers that do feature work — the ones who design products from end-to-end — make more than designers on non-product work (e.g., visual designers, design system designers, etc.).
Specialist surgeons command higher rates than generalists because this work is extremely risky and hard, and takes significantly greater time investments to excel at — as a result, fewer doctors want to invest in these skillsets. This creates scarcity, translating directly into higher rates for these providers. It’s simple supply and demand — product designers assume more risk than brand or design system designers, given that the products worked on are customer-facing and directly related to the business’ bottom line (i.e., the product users are “paying” for), and so this is part of why compensation is higher.
Closing thoughts
Product design is already a very narrow and specialized role. Tech companies have specific expectations in these roles, usually and mainly these two:
Designers are paid to plan and model how some software should work, and
Designers should make the software they model look professional.
Certainly, some companies produce software that is known to be easier to use — and more professional looking — than others than others but, regardless, these are the two main expectations that all tech companies have of designers. In its truest sense, “design system designer” is the best shot product design has at specialization — and these roles, as mentioned, tend to command lower compensation than designers who work directly on the customer-facing product, rather than internal tooling.
In addition to these minimum requirements, however, expectations can vary per team and company, too, of course. For example, where most companies are fine with just representative, still screens in Figma to model how some software should work, with engineers doing interpretive work to fill in the blanks as needed, a certain Gradient Camera app asks designers to model higher levels of detail. For instance:
These are complex interactions that tools like Figma, Axure, etc., cannot reproduce. However, the Gradient Camera app has enough interaction complexity that there’s no way around this level of detail in our models. Notice a few things:
Animations are asynchronous (e.g., the video player animating in while the toast animates out),
The prototyping is not screen-based, but object-based (e.g., the cards in the stack individually animate out into their positions, even when not visible in the stack; a particle emitter is taking in sound data and rendering an animation based on that data; etc.),
These prototypes can take user inputs in complex ways (e.g., users can tap and drag on the album art and reposition it freely on the canvas).
This is what goes into making a prototype pictured above.
Due to the nature of this product, this particular company needs designers who can step up and model these advanced interactions — this is because the Gradient Camera app is a product that uses canvases and canvas-like surfaces to allow users to interact with the product in complex ways (e.g., users can draw, add in GIFs and resize them, objects animate in and out in complex ways, etc.). These interactions are some of the most complex a designer might work on in their career.
When the ceiling of complexity around interactions increases (as is the case in Gradient Camera app), designers are commonly expected to fill that gap. This is reasonable. As interactions get more complicated, designs become less possible to split across designers. It is easier to have “pure UX” designers (who then pass gray boxes off to “pure UI” designers) the simpler the products are (e.g., websites, e-commerce sites, etc.). As they get more complicated, this becomes nearly impossible. In products with complex interactions, the gray boxes are hidden behind complex gestures, are usually ephemeral, and can often be highly dynamic, themselves. I don’t see a way to sustainably break this up between multiple people, which is why Gradient Camera app doesn’t bother.
For my part, I’m not sure where the “UX” ends and the “UI” starts in the models above. The timing of interactions in gesture-based products really matters — and it’s one of those things you need to “feel” out, and only while building a very detailed model. This cannot be easily separated into “UX” and “UI,” as more simple products that only rely on simple tap targets can.
But there are other products that can be this complicated, too, for example: the TikTok editor, FigJam, Facebook Live, etc. In products like these, there are also a lot of gesture-based interactions that can asynchronously occur, and that are difficult to communicate in still screens. This is why products like the Gradient Camera app ask this of their designers. This is contrast to even when I worked at a certain Bird App — in that product, like most I’d worked on in my entire career, there were mostly just simple tap and click targets that either bring up modals, or cause page refreshes.
Certainly, most products don’t need complex dragging and pulling and pinching that is commonly seen in mobile video or image editors (e.g., TikTok, IG Stories, etc.), and so the amount of motion and animation work needed in these products is very low. This is a good thing — most products are simple enough that simple taps and clicks are exactly all that’s needed. Again, it’s not every day that you work on interaction-rich products.
For our part, designers at a certain Gradient Camera app are expected to (1) be the sole designers on their teams, and (2) develop product strategies (our cadence is every two quarters — it was quarterly at Bird App), and (3) execute on those strategies as sole designers, and (4) build complex prototypes of every interaction (see above). At every workplace over my last seven years, though, I’ve had to do 1–3 — and, sometimes, other tasks. The last one being new to me.
For example, I’ve designed A/B tests and dropped the trackers in the codebase — this is frequently done by data scientists and developers at companies like Bird App and Face Literature company, but it made sense for me to do it in the situation I was in. Other times, I’ve written scripts for users to follow in usability tests of interaction prototypes concerning features I wanted a gut check on — researchers are the ones that are usually employed to do this, even on a part time basis.
At most companies, I’ve been relied on to inform our quarterly roadmaps — and sometimes relied on very heavily. I’ve also worked as both a designer and developer at tech companies (very few companies ask designers to know anything about engineering because they understand this is a very tall order — it makes hiring nearly impossible).
Making software isn’t a science — it’s just software. As a result, there will be lots of role collision, and designers should seek to, above all, be grateful, be helpful, and be open to doing stuff that isn’t explicitly in their job descriptions. Learning is not subtractive, either — it’s always additive. A designer learning how to make incredibly detailed prototypes or learning to be a fully functioning engineer can only be said to be a stronger professional for it, for example.
There is no specific reason why, in product design, putting points in your aesthetic or technical abilities should somehow take points out of your capacity to reason through user flows in a feature you’re building. We are fortunate to work in an industry where it is possible to be good at a great many things without significant investment or risk of failure seen in other industries (see: surgery).
No matter where you go as a designer, you’re going to be expected to produce software that is made in way that’s reasonable for most users (“easy to use”), and that looks professional (read: some regard for visual design, or whatever your client/employer allows you to get away with). From there, responsibilities might increase, where you may be expected to take on a lot of strategy work (usually more commonly done by product managers), or to model very detailed interactions (see: prototypes above), etc. My advice would be to roll with the punches.
Whatever is needed to get the software out — and, ideally, a great product made — is our one job. That creates a lot of incredible opportunity for lots of depth in lots of directions. It’s not every day that all of this lines up as well as it does in software.
What if there aren’t actually any specializations in design? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.