Craft vs Industry: Separating Concerns

Reconciling the differences between the craft of making websites and the industry that has grown around it.

Table of Contents:

This post is probably too long, but I need someplace that I can refer to. As is often the case, I am writing this to sort my thoughts, primarily. But I am hoping to give voice to what I am observing in other people in our field but is rarely spoken about. I am not attempting to postulate a solution to a complex problem; instead, I am trying to provide words in the hopes that they resonate with what other people are experiencing, if nothing else just to let them know that they are not alone with it.

Every good post starts with a quote, right?

[Industry means] something that is produced or is available in large quantities and makes a lot of money.

(Quote from the Cambridge Dictonary)

We have long referred to our niche on the web as the "web industry," but never has the term been more congruent than it is right now. I believe this throws us into some conflicts that we are left to deal with alone. Because what we've learned in the decades before, what mattered to the craft of making websites, seems to sometimes not be compatible with what is asked of us from our jobs. This throws us into significant conflict, and resolution seems to be left to our own devices. In this post, I am trying to tackle this conflict that has been on my mind for so long.

Welcome to the Age of Industrialisation

Section titled Welcome to the Age of Industrialisation

I think it is very clear for most of us to see that our little corner of the world has reached the age of industrialization. With this "little corner", I am referring to the community of people who make websites. Designers, developers, and everything in between and beyond alike

There are many signs that we have irreversibly entered a new era, one that is determined by industrial practices. We constantly hear that we're not supposed to reinvent the wheel; websites are now being derogatorily called MPAs (multi-page apps), and we're generally referring to websites as software. UI is now coming in the form of self-contained, composable pieces of single sources of truth, "components", and the question "Will it scale?" is the number one differentiator for "maturity" in the tooling surrounding our craft.

A single difference that allows us to sort something into a dichotomy—that is what a "Leitdifferenz" refers to (I am using the German word directly here to refer to Niklas Luhmann's concept, because I cannot find a semantically fitting translation). We have been obsessed with this scalability as the single differentiating factor that will tell us how well something will adapt to the changing requirements of an organization and increasing, diverse technical demand. But for businesses, scaling means that output remains the same or only slightly degrades while production costs lower.

Scalability has become the leading differentiator, the Leitdifferenz, of almost everything in our industry. From the tech we develop with, for, and on to what, how, and who we design for It's almost like a trance that we keep repeating to ourselves."But will it scale?" is first and foremost a matter of business. But in development and design, it also refers to other factors. Yet when it comes to matters of industrialization, these factors remain secondary.

For example, a course is a scaling product. Because you are investing time into its production, and then all you have to do is maybe every now and then generate a promotional advertisement for it, but the price remains the same while your initial expense disappears entirely. Your margin has increased; your product value has scaled. The purpose of industry in general is to achieve scale by reducing production costs. Create a "streamlined" (another term that we have become very familiar with) manufacturing process and automate it as much as possible to generate a product that will sell to as many consumers as possible.

Configured, Consumed & Composed: Components and Design Systems

Section titled Configured, Consumed & Composed: Components and Design Systems

We can consider design systems themselves as an answer to the question of scalability for design. And even here, scaling is still the leitdifferenz by which we categorize. Design work is being compartmentalized into "components", small, self-contained deliverables that can then be composed together by someone who is not a designer. The idea is that this will allow for a more efficient and scalable design process. But obviously, design is more than just that. And design is still happening by the person who puts components together, just without the skills necessary. So the reaction is to create an even more restrictive set of rules, so that instead of applying systemic principles to design work in order to enable design work, it is being reduced to a set of consumable components and rules.

That is not the premise of design systems as a way of working, but it is what some designers are postulating because that is what sells them to industry. The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:

[...] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.

So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality. And it is also reflected in the way that people are entering the industry. Lately, we've seen a lot of bootcamps popping up that, for the most part, educate people just enough so that they can get a job, at least that is the premise. But they rarely know the principles, values, and philosophies that constitute the web platform. But they can create a fully functioning "web app" with Next. JS in React! Of course, they don't learn how to manage CSS for this type of site; instead, they just use Tailwind. But at least they know how to specify TypeScript interfaces!

And of course, they learn that design comes from UI libraries. Gone are the days where we used to tell people that bootstrapping was just for prototyping and otherwise would quickly turn into technical debt! Nowadays, designers are sometimes even told to start with one of these libraries. Just, they're not called bootstraps. Instead, they're called Material UI, Headless UI," or Chakra UI. But they bear every necessary resemblance. But it's fine, because it's just the components, right?

What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the "output" is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce "free" iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!

Seats at the Capitalists Table

Section titled Seats at the Capitalists Table

The larger premise of design has degraded over the years, in my opinion. As it got more embraced into the industrial process, it did so by devaluing the perspective of the people for whom the discipline used to design and replacing it with the perspective of companies. This is the price that design continues to pay for its seat at the capitalist table. In my opinion, the cost is too high to be worth it. This was also one of the reasons why I decided to not pursue it as a career any longer, in 2022.

When we referred to ourselves as Web designers, we were constantly struggling to find companies that took our profession seriously enough to integrate us into their processes. But design was not considered valuable. So we started to call ourselves UX designers because we were designing experiences, not websites. And slowly but surely, we got our oh-so-desired seat at the table. But only if we demonstrated our worth by demonstrating a number-go-up linear-causal relationship to our work, which would necessitate extensive monitoring of our users.And thus, companies have successfully forced us to degrade the merit of our work to quantifiable markers of increased conversions and clicks and the firing of whatever other random KPI we could somehow pull off our asses—all to appeal to the growth-at-any-cost mindset.

This often happens with important values in our craft. The recent increase in attention on accessibility is already taking a similar path. Accessibility advocates and experts are often forced to "sell" (see what I did there?) accessibility work to companies by showing them how much more revenue, conversions, or users they could be having by making their sites accessible. But our craft, on the other hand, clearly dictates this as a primary focus—a Leitdifferenz to judge the merit of our work. If what we do isn't accessible, it's to a certain degree broken or incomplete at best.

The problem with this angle is that, inevitably, industry will respond industriously. And now we're having to explain to companies why they cannot just install an overlay and see it done. But that is the price of putting a number on marginalized groups. Unfortunately, that is the language that businesses speak, so experts and advocates are not to blame. They are doing the best that they can because they know that, in the end, the removal of barriers for people who rely on them is what matters. They are, in their own way, navigating ambivalence and finding their way through the conflict of craft vs. industry.

UX Design used to stand for "User Experience", but in order to get our seat at the table, we had to degrade it so much that it has long since shifted its meaning to "User Exploitation", as Mark Hurst writes. The practice of UX, removed so far from its subject that it now considers the company itself the subject of their work, is now being used for bad-faith manipulation to increase capitalist numbers.

This is reflected in another marker in language. Just as we were once web designers and then UX designers, we now call ourselves "product designers." As designers, our relationship to what we design and for whom we design it has changed. We used to design websites for people, then experiences for users, and now we are designing products for companies.

This coincides with the fact that we are now broadly regarding websites as software, but we're not calling them websites. We're calling them "Apps". And it makes sense—we have entirely normalized the practice of having our websites controlled by JavaScript from server to client because JavaScript is mature now and thus appealing to traditional programmers, who used to shun it fiercely.

This change in the demographics of those who write code has made it easier to hire for these positions. A website entirely rendered in JavaScript can be worked on by someone with a University Degree, in which they are rarely taught about the special relationship between HTML, CSS, and JavaScript, but are instead told that CSS and HTML are not real programming languages. And with these capital-P programmers, their language is long, as are their world view and their heuristics.

The Craftsperson vs The Factory Worker

Section titled The Craftsperson vs The Factory Worker

People who make websites and are also working in what we refer to as "the web industry" are often forced into a difficult conflict. In their position as an employee or freelancer, they sometimes have to work on technology that they know isn't compatible with the values that they learned to hold dear in their craft. Designers are asked to implement dark patterns, even though they know that it is unethical. Developers are asked to work with React, even though they are aware that it is maintained by Facebook, a company profiting and and enabling genocide. And the list goes on.

It is also expressed in what I think is best summarized as "Industry Fomo". Developers know full well that using next.js to create a relatively simple website is overkill, inappropriate at best, but they see themselves required to use industry-grade technology because job requirements are not listing skills anymore, instead they are listing tools and frameworks.

I consider this a conflict between two identities: the craftsperson and the factory worker. The craftsperson wants to do what honors the values of the craft, but the factory worker needs to do what will keep them employed or employable. A conflict that we are being left alone with, often lacking the words to conceptualize what is really happening here.

Postulating to know a solution to what I consider would be hubris on so many levels. But what I can do is access a little trick from my work as a systemic counsellor. Systemic counseling operates on many different principles, one of them being second-order cybernetics, in which cybernetic principles are applied to cybernetics itself—recursive cybernetics. We know a thing or two about recursion, right? We can apply some of the principles that we usually use as a guide in our craft to our own situation: Separation of Concerns.

While this integer design principle of HTML is usually referred to in order to justify the separation of concerns for content (markup, HTML), presentation (styles, CSS), and behavior (scripting, JavaScript), it is also a general design principle in computer science, and we can also use it to separate the concerns of the craftsperson and the factory worker.

If we separate the demand into independent concerns, made by independent parties, we get the chance, instead of having to decide, to hold the ambivalence and complexity of the situation. Industry of course would force us to reduce complexity, another religious mantra of programming. But complexity means possibility, and with possibility comes the ability to decide. Do we go with what the industry demands, or do we go with what the craft demands? The conflict is the oscillation between both possible decisions. Not only can we not decide, but we are also uneasy with the fact that we cannot decide. Fritz B. Simon calls this a "double negation,", and it becomes the constitutive marker of conflict, described systemically.

But what if, instead of oscillating between both positions in an attempt to make a decision, we just stay in this ambiguity for a while?A room emerges that we are holding. In this room, both positions aren't changed, but it may allow us to not experience them in conflict with each other. If we understand them as a conflict of concerns and not a conflict of identity, we may even see where both concerns align. Or we can give voices to both parts.

At the very least, it may help us to not experience this as a personal conflict but instead leave it to the job, which has to find a way to utilize craft in a way that makes it compatible enough with industrial processes—another different concern reveals itself here, the concern of the business, not the concern of the employee.

Failing to reconcile competing Identities

Section titled Failing to reconcile competing Identities

This isn't always possible, though. And sometimes, people may decide to leave not only the industry but also the craft all together to protect themselves from this conflict. Not because they couldn't hold the ambivalence of the craftsperson and the factory worker as is, but because they don't want to degrade themselves or their view of the craft—or maybe because they weren't able to see two separate concerns but instead saw a personal conflict that they were left to deal with on their own.

But if we somehow manage to conciliate those two competing identities, we may find some personal relief from trying to find a common ground between two competing sides within ourselves. I have to work with technology that I find deeply offensive and politically abhorrent all day. But at some point, I found great relief in understanding myself as an employer who works with this technology, not as a craftsperson working on the web. I understand that it is not people who want to create SPAs; it's an industry—businesses.

Many people are not differentiating here, and so they just repeat the capitalist programmers mantras. But that says much more about how they relate to others and how they define themselves. Do they even consider themselves craftspeople? Do they even see the craft that is there?

Ultimately, the fact that we see a conflict here can be considered a good sign. As I said before, systemically, we can understand a conflict as an oscillation between possibilities. That means that in order to experience conflict, we first need to see possibilities. So if you are currently battling this conflict, you may find some relief in knowing that you are experiencing it because you see possibilities and are not submerged in the trance of the factory worker, induced by industry.

AI: The Penultimate of Dehumanisation

Section titled AI: The Penultimate of Dehumanisation

We do need to talk about AI because it is an inevitable part of industrialization and there is no escape for any of us. The desire to reduce manual labor by automation and reduction of complexity is the seed that gave birth to programming in the first place, and AI is a tangible premise of endless scaling. I think it would be incredibly unwise and hubristic to assume that the broad majority of us who are employed at this time will remain employed in the next years.

Apologists often claim that "we will move on to other things", but that is not true. Some of us will divorce further from craft and appeal to business desires in managing or other administrative jobs, but these jobs are given, not earned. The value of our work will inevitably reduce massively, and few of us will be able to do what we do now and get paid for it.

The groundwork for this has already been laid. Take a look at dribbble, and you'll find one interchangeable site after another. And this is the dataset that AI is being trained on because it can't look at an actual website; it only looks at pixels for the most part. But even if it were looking at real websites, they have long since started to look so similar that they are often only differentiated by their themes.

In order to protect ourselves from this inevitable reality (again, programming was invented to make human labor in weaving redundant; this is the leitdifferenz of the entire profession), we can learn to understand employability does not make us craftspeople.

Because the craft will remain even after most of it is automated. You can order mugs online, yet there are still potters out there. We can go into C&A and buy a dress, but there are still seamstresses making bespoke garments. This is the craft's unavoidable final destination - where it all began.

Handcrafted websites are made by humans for humans. This is what differentiates our craftsperson from the factory worker—what the craftsperson does is valuable to people, not businesses.

And until that time comes, we can be both at the same time. We can hold both perspectives as important voices with different concerns. We can switch between them, look for common ground, or side with one or the other in a given situation.

So the next time you are approaching a website, ask yourself, "What would the craftsperson do?" And also ask yourself, "What would the factory worker do?" See what answers you come up with!

Thank you to Hidde de Vries, who in a conversation we've had, helped me to see the potential value, that a post about this topic could have.

Proof Readers & Feeback-Givers

Section titled Proof Readers & Feeback-Givers

I feel especially grateful for these individuals, who not only took the time to read through this post, but also came up with fantastic and extensive feedback, which I've incorporated into this post. Thank you so much!