Here's a sketch of a contrived UX -heavy Web development team, idealized in terms of every subspecies of UX specialist having a job: Some kind of strategist/lead/architect/grand poobah, to be the principal contact with clients and the first and last word on design,

A project manager, who is not a designer, to deal with people, resources and schedules,

A user research, testing, and analytics person,

An interaction designer,

An information architect,

A content strategist,

A visual designer,

A front-end developer,

A back-end developer,

A software tester,

A system administrator,

Juniors, interns and internettes. Okay, the care and feeding of that troupe is going to be well over a million bucks a year. And that's not counting gear, office space, support staff, marketing, biz dev, etc. A team like that is going to have to complete a six-figure job every month just to keep the lights on. But of course, six-figure web jobs typically don't work like that. We'll cover that shortly. I'm going to leave aside for a moment that in reality, many of these roles can be coalesced together, and the mechanics of real projects don't align perfectly to all hands engaged on the same thing at once. I want to focus on one thing: In order to support a team like this, you need a million dollars worth of client. These entities are not buying websites for funsies: they actually need their investments to perform. Whatever you do for them is going to have to generate sales or cut costs, more so than whatever they spend on you. Moreover, the people in charge of these entities aren't going to bet the farm on a silly website, so you really only have access to a small amount of their working capital. That means the company is going to have to be several times larger than the project. To pull an unrealistically huge fraction out of the air, let's say 5% , your million-dollar client has to be a 20-million-dollar company. Here's the million-dollar question: how many of those are there? How many are there in your area? How many cushy strategy and service design jobs can the ecosystem support, both globally and locally?

Now for the Mechanics I'm focusing on generalized web-based stuff: websites, sitelets, web apps, intranets, etc. As a medium it's both relevant and unique; problems solved for the web can be exported to other media. Web projects also tend to have the property that what they cost to make is a linear function of how long they take and vice versa, so unless you're pricing based on the value of the outcome, your revenue is pinned to your capacity to take on work. Our dream team above will therefore have a definite envelope of possible work it can take on. We need to consider: How long it takes to get a project,

How long it takes to do a project,

How many projects the team can handle concurrently. I'm not even going to try to model the sales cycle here, but suffice to say that its length goes up exponentially with the size of the project, as does the overhead on cajoling, travel, lawyers, credit, insurance, et cetera. This is a truism: consider how much thought you put into buying a coffee versus buying a house. This is going to cap the size of project this team can take, which, when accounting for your revenue expectations, means no fewer than µC active clients a year. Clients and projects, of course, are not 1:1, as the former may have additional requests as time goes on. Each client therefore generates at least one project. While we can imagine different members of the team being active on different projects at different phases of development, no one person is going to be able to give serious consideration to more than two, maybe three projects at once, and only then because of the inherent back-and-forth with the client and the other people on the team. This capacity may increase nonlinearly with the size of the team, so we'll be generous and add one more slot to our dream team, bringing its carrying capacity CC up to 4 . This means no more than a certain number of projects a year. Sorry folks, I don't have time to create a satisfactory model for what I just described, but if I did, it'd feature the sales funnel, projects coming in and going out, what parts of what are being researched, designed, implemented, tested, deployed etc. A model like that ought to be able to tell you the ideal team composition for a given class of project, and the ideal class of project for a given team. Invoking the rule of thumb that 80% of the revenue tends to come from 20% of the customers, we can imagine our million dollars split up in this completely contrived, yet appropriately self-similar way: Project size What the money buys $1,000,000 What you need to keep the lights on $800,000 Big flagship project $160,000 Comprehensive, ground-up website redesign $32,000 Sitelet, renovation, research brief, etc. $6,400 A workshop/facilitation session $1,600 A day of consulting? Maybe? You aren't going to bag a sub-one-year web project worth $800k unless you're in-house or have a sweetheart client and/or doing value-based pricing. An ordinary schlep website—at least one that makes use of some of that design talent—hovers around $100k and a year in development, give or take a few months and a few ten large. You'd need ten of those just to stay afloat, but remember the team can only handle four at a time. More Mickey-Mouse stuff like Wordpress and Drupal installations obviously cost considerably less money and take less time, but there's no way you could get the equivalent of even a thousand billable hours out of each member of the dream team with those. Arguably even the presence of dedicated specialists makes $100k a small project, with the average being about three times that. But that's kind of my point. Not only is all that specialist design talent only employable at the high end, not to mention completely out of whack in its ratio to dev, if you wanted to be an average performer, you'd have to gross just shy of $180k per employee, which cuts the team down to 5.5 to hit the million-dollar mark on the nose. Since people tend to stop functioning when you cut them in half, we'll have to round either up or down. Let's say a team of five: the leader, two devs, two designers, and the rest subcontracted. This will also take CC back down to 3. If you're trying to be a design-heavy shop, you're still stuck with $100k-$300k projects. You're stuck that way because of the extremely narrow range between your revenue target, the number of clients you'll need ( µC ), the team's capacity ( CC ), and the time it takes to complete each project. Incidentally: What insane next-level shit are you doing that somebody is going to fork over three hundred grand to your fly-by-night boutique design studio? Okay, fine. Good design commands a premium. So let's imagine the world is brimming with design-savvy clients aching to fork over their money. They still have to have the money, so how many of them can there possibly be?

Actual Numbers To recapitulate our revised team: A leader, client-friendly generalist, entrepreneur,

A senior designer with a lean toward user research, analytics and interaction design,

A senior designer with a lean toward information architecture and content strategy,

A junior developer with a penchant for JavaScript,

A senior developer who does back-end code, and knows how to run a server/cloud/whatever,

Subcontracted PM, visual designer and software tester. Let's imagine a $ project. Assuming the potential client spends % of its current expenses on payroll at an average salary of $ , and likewise assuming that it has times its expenses in operating capital, and is willing to spend % of that capital on your project, a business entity with that kind of money will probably employ at least people. There are such companies in Canada and in the US. Since only growing companies invest in superfluities like web development, we immediately subtract the % that aren't. We then assume that they're only inclined to buy on average once every yearsyear. If your revenue target is $ , then you will need of these clients every year. This means that in Canada, the theoretical maximum carrying capacity in the business ecosystem for teams like yours is and in the US it is , for a total of . If people on your team are dedicated UX professionalsperson on your team is a dedicated UX professional, then there are enough eligible business entities to support practitioners doing jobs this size in all of North America. However, if only % of the executives in those companies recognize the value of design and have the wherewithal to do something about it, then the number of UX professionals that can be supported at this level is for Canada, for the US, and for North America in total.

How do these estimates stack up? I took the subset of the members of the VanUE meetup group—1447 as of this writing—who are actually in the greater Vancouver area, where I'm from. That number is 1309. That's not an unreasonable number to go in and manually prune out all the bots, duplicates, recruiters, business owners, managers, developers, students and tourists, but I'm doing this analysis on my own time, so I'm just going to hand-wave, and say that maybe a little more than half, say 700 of those are actually employed as legitimate UX designers. Sure, there could be designers who aren't on the list, but if they're going to be on any list, they're going to be on that one. Earlier this year, before it got paywalled, I grabbed the top digital agency stats from Business in Vancouver, and learned that combined they employed 929 people in 2013. We can say that maybe a fifth of those people are UX designers, so 186. Note that to BIV , digital agency also means advertising, VFX , etc. If we imagined these agencies accounted for a quarter of all UX employment, then multiplying that number to 744 is awfully close to my original spitball estimate. Is it reasonable that over half of the UX designers in Canada are in Vancouver, as my back-of-the-envelope calculation above would suggest? Probably not. A quick check on LinkedIn has 1019 people with that title in Toronto, 371 in Montreal, and 473 in Vancouver—way lower than my spitball. 1863 people in the three biggest cities in Canada probably amounts to about 75% to 80% of all designers in the country, pushing the total to around 2500. Montreal may be low because even though I can speak French, I don't know what UX designer is in it. I got these results by doing a search for job titles, but LinkedIn is dumb and only lets me search for one job title at once. As such, there are bound to be duplicates. It's also way too exhausting to search all the other permutations of UX job titles by hand. I'd get a more accurate estimate but that means writing a script to go in via the API . If somebody wants to pay me to compile detailed dossiers on Canadian UX designers, I'm not above that. Also, only 90 people on the VanUE list specified LinkedIn accounts. If LinkedIn is more accurate, then a lot of those people on that list are tourists. Okay, so 2500 is almost twice what I got using my default values for my little Mad-Libs form up above. There are enough variables that you can nudge them around until they match. That thing was really just an experiment to get a sense of some ballpark figures, ideally through a lens of an ad-hoc team of independents or a small agency. A more accurate model would need to be considerably more detailed. Better modeling of revenue breakdown by project size would be nice, as would explicit handling of in-house teams. I already have a better model in mind that would be a crapload more accurate. I can already do it for the US but not for Canada without paying several hundred dollars for the data. StatCan quoted me $72.68/hr + GST with an estimate of hours to produce because in my country, taxpayer-funded data is curiously not in the public domain.

Going In-House Agencies exist because clients don't do enough of that kind of work to warrant staffing up their own team. If you run a company who does enough business with a design agency, then you might want to consider it—or heck, just buy the agency, like Capital One just did with Adaptive Path. There's obviously a huge efficiency gain to doing that, since internal teams don't have marketing, biz dev, and operations overhead. Note that I use the term agency loosely, to refer to any business entity, person, or ad-hoc group of people that is not a department or employee of the client. Bigger companies obviously hire more designers apiece. In the Information Architecture Institute's latest salary survey, which, granted, only had 147 respondents, 78, or more than half of them, work for companies larger than 300 people. 45, or 30%, work for companies with over 3000 people. But a little designer goes a long way. Google, for instance, has only 296 designers out of 55k people—at least according to LinkedIn, which, yeah, dodgy. Capital One's glitzy acqui-hire of Adaptive Path netted them only nine UX designers—or 13, depending on how you count. They have 44k employees. The message here is that megacorps who staff up in-house, in the long run, probably make the global market for design smaller. If you want to see what the carrying capacity is for an internal design team, just set the form's project size to the total cost of employment for all designers, the revenue target to the same number, and the interval to 1 year. Also your piece of the working capital pie is going to be way lower, maybe 1% to be generous, and maybe 5% of executives would have the minerals to do something like this. Remember that the cost of employing somebody is about 1.3 to 1.5 times their gross pay, for benefits, gear and extra support staff, so a designer who earns $100k would cost say, $140k. Don't forget to set the number of designers to your team's size. Here: I'll do it for you, for a team of 3 at $100k salary apiece. With those numbers I get something like 800 designers for Canada and 2078 for the US. Granted, bigger companies will hire more designers, but the bigger the company, the exponentially fewer there are of them.

My Point I don't know if you've looked around much, but just about everything still sucks. The world needs more design, but all this specialized talent prices itself out of most markets—at least in the way it's currently organized. Most business entities are neither megacorps nor tech startups. They're mom-and-pop shops, non-profits, small, brick-and-mortar businesses that actually move atoms around for a living. We can jack up the economy's carrying capacity for content strategists, information architects, interaction designers, researchers and whizz-bang cross-channel geniuses if we can figure out a way to deliver what we do for less than what these entities would have to pay to hire one more average employee. It would also be nice if we didn't have to compromise our cushy six-figure incomes. Well, maybe your cushy six-figure income. I haven't had one of those in a while. There isn't a lot of money in figuring this stuff out. At least not on this side of it. Here's my prediction: The more big companies climb onto the UX design clue train, the closer the number of viable specialist designers will come to being fixed. Then you get a supply glut. Then you get a price crash. That would suck terribly, so it would be prudent—and not to mention lucrative—to figure out how to make what we do more affordable. Figure out how you can work alone There are sub-disciplines of the UX umbrella who, given an appropriate context, could theoretically work with clients directly: A content strategist can work directly with a client if the proper infrastructure is in place.

So can an information architect,

So can a visual designer, for that matter. What you would need is something like a CMS . But not just any CMS : one that is actually designed around your role as a content strategist, information architect, or visual designer. It may or may not reside on the client's system; it may reside on yours. Think about how a system like that might behave. Figure out how you can break up the job My experience with interaction designers is that they tend to view programming as an activity performed by the help. This unfortunately makes them categorically useless to clients and employers without the help of the help. User researchers may be able to produce useful business-strategic insights on their own, but they are also largely dependent on the presence and cooperation of designers and developers. Despite that, the web as a medium does not prohibit a minimal team of { researcher, IxD , developer }, or even { UX omniglot, developer } from contracting for, researching, designing, implementing, testing and deploying one user scenario at a time: A user researcher can concentrate on one class of user at a time.

An interaction designer can address one user goal at a time,

So can a front-end developer,

So can a back-end developer. Granted, there would need to be considerable rearrangement of process and technical infrastructure to make that possible. Incumbent technology products assume that they're in for the entire website, or at best a section of a website. This is dumb and should probably be changed. Note: I use the specific term interaction designer on purpose to refer to the person who translates user goals into instructions specific enough to pass off to a programmer. This is merely for the purpose of disambiguation. Generate Permanent Assets Design imposes a premium, no matter how you slice it. You are always going to be more expensive than McDrupal™. That's because design is about taking the care and attention to actually solve each and every problem, shoring up every solution with research data and expert reasoning, and documenting the communication of each design decision with crisp lucidity. Then, when the final product is launched, you flush all that information down the toilet. The amount of energy spent cogitating a design problem, the research, the emails, the meetings, the hours wasted fighting with Word, Excel and Powerpoint, only to have that work lost, forgotten and re-done, frankly sickens me. The effective gelling of any design decision is money that doesn't have to be spent again until the context changes, and only then as an adjustment to the original. This is probably the biggest waste of time and money in our profession. The cost of documenting design decisions needs to be slashed by an order of magnitude, and not by slashing the act of documentation, but rather by inventing new tools to make it easier. The value of design documentation also needs advocacy, and more tools to arrange, abridge, and preserve it so it doesn't get lost and actually gets reused. Specialize along the other axis Tech is not a legitimate domain of business. What is meant by tech —the effective and efficient handling and manipulation of information, is a need which pervades all legitimate domains of business, like agriculture, mining, logistics, and medicine. The best advice, in my mind, comes from Zed Shaw, though he was specifically considering programming: People who can code in the world of technology companies are a dime a dozen and get no respect. People who can code in biology, medicine, government, sociology, physics, history, and mathematics are respected and can do amazing things to advance those disciplines. To apply that idea to UX , you could potentially go much farther in your career if you had some generational, on-the-job, or long-abandoned university knowledge in some specific domain other than tech . Double up on skills The biggest problem I see with becoming ultra-specialized in the abstract field of design is that you depend on so many other people farther down the line to realize your results. Each additional person in the chain raises the minimum cost of getting anything done. If you combined complementary skillsets, you'd have a greater chance of being able to deliver results which are actually meaningful to businesspeople, who only care about cutting costs and increasing revenue. The most obvious pairing is interaction designers who know how to code, because then they could work directly with clients. Information architecture and content strategy are also natural pairings, because they both deal with meaning and structure, and can already work with clients directly in the appropriate setting. Research, analytics and testing also fall in together nicely. The astute among you might note that heretofore I have neglected an explicit mention of user testing, while I still explicitly considered QA . I will confess that user testing is something I know about the least, with the eye-tracking gizmos and what-not. My understanding is that kind of user testing, much like user research where lengthy interviews with several actual users are conducted, is astronomically expensive. My mental model for this all along was that I was considering the web first and foremost, where remote A/B testing can be carried out cheaply, and that activity would be led by the hybrid research/analyst/tester. I don't know how representative this is in the real world as far as numbers go, but I do know people who do this for a living.