It’s now been over 10 years since I started a role where the first words uttered by a Product Owner towards me (upon meeting me for the first time) were: “Very nice to meet you, I just want you to do whatever I tell you to (when it comes to the product)”. Aside from the fact that those words were not entirely a “joke” (actually they weren’t a joke at all, but that’s not even the topic of this article), it did surface a systematic issue that continues to plague Designers in their career paths, and the Design Discipline in general: essentially being considered a subservient voice as opposed to a peer that can influence the direction of a solution in a meaningful way. This type of behavior mostly pops up in organizations where the UX Maturity level is either absent or very limited, meaning, Design is still very much seen as a service provider, not as the peer that I mentioned previously. This topic has since come up in various conversations with fellow Designers. These conversations focused on the role of Production Design in the Design Process in general, and just as importantly, how automation and AI can play a role in changing that discipline and its outputs.

Is the Production Artist role in the Design Process still a thing. For those who are probably not very familiar with the term, it’s a term that I mostly recall listening to while I worked in the Design Agency world. The Agencies I worked for (prior to 2010), usually had what were called Production Artists. Wikipedia defines Production Artists as: “…a technical and creative position in a creative profession. The job title originated at advertising agencies, assigning what was known as paste-up work (now prepress production) to the position. Production artists work closely with the designer and art director to execute the design. What distinguishes “production art” from design is opportunities to utilize prepress knowledge into creativity and design training in the work involved. The degree of technical knowledge required for some production art work may be comparable to higher skilled engineering, especially with computers.” It essentially is a position that is still deeply associated with Print Design, but that has grown to encompass what I witnessed in other organizations as a role whose responsibilities include deliverability of multiple artifacts that are typically required for various user stories to be executed by development teams. These professionals typically aren’t able to provide much value when it comes to problem solving or strategy itself, because: a) product owners have already “figured out” the solution and b) designers are meant to execute on someone else’s vision.

While there’s evident truth to the second part of wikipedia’s definition, that these professionals do have a considerable technical knowledge, the matter of the fact is, when it comes to the Design process itself, these types of responsibilities are becoming increasingly less common (as they should be). Production, or if we want to rename it as Deliverability, is indeed part of the Design process, in the sense that artifacts do have to be constructed, which includes prototypes, visual design assets, the content writing itself, essentially the soul, skeleton, organs and skin that brings something to life (let’s call the code/development as the blood that agitates and makes everything behave in an organic way). While that metaphor may be a bit Cronenbergian, my point is, Designers these days understand the role Deliverability has on the journey, but also clearly realize that there’s quite a lot more to that journey than just the deliverability of artifacts. Hopefully that is a realization that their peers also comprehend. Being a Production Artist, while a commendable position in itself, when it comes to the Design Process it opens a series of questions which bleed off to the second point of this article.

Where Does Deliverability/Production fit with Templates, Automation and AI. A series of organizations have anchored their business strategies on the premise of being able to deliver web based products in an automated way, with solutions that include a series of easily implemented components and add-ons that their clients can customize to fit their own needs. You can go to Square Space, Weebly, Wix, GoDaddy, to name but a few, but they essentially have automated the process of creating digital properties for anyone who is willing to pay a monthly stipend. The role of the Web Designer, one that was so popular in the 2000s, has had to evolve accordingly since now many of these businesses provide instant solutions, ones that can be up and running in a matter of minutes (of course these solutions fall into trappings of being generic and lacking a specific brand storytelling, but they can be further customized with the talents of Design and Development professionals). The point I’m trying to make is this: there is an inevitable aspect to the Design Process itself that involves being able to deliver artifacts consistently and efficiently, and frequently with a considerable volume of those same artifacts expected to be delivered. That’s one of the reasons Design Systems are built. The language that sustains and defines a Design System, has a series of elements which enables Designers to quickly shape and materialize a solution in order to both test and build the actual output with the collaboration of their peers in Development. These Systems include Templates, which allows for deliverables to be easily crafted without the Designers having to go through a considerable amount of research (and additional testing), every time they need to edify something. There is a certain amount of automation that should exist when going through a Design process, with the Design System providing precisely that. It’s a resource which enables scaling on top of what was previously mentioned in terms of consistency and efficiency (one of the software solutions I worked on in 2021 translated into a prototype with over 170 screens, all of which were easy to map out and build thanks to a Design System).

The reason to bring all these topics up, is directly associated with the fact that Production/Deliverability in a Design Process can’t really be dissociated from everything else that is taking place. Let me rephrase it: it isn’t sensical for a Designer to exclusively be delivering artifacts, when a Design System if mapped out correctly, can accelerate the deliverability exponentially across any type of scenario that is presented. With the introduction of AI and the opportunity to further craft elements automatically, the more efficient it becomes for Designers to leverage that tool to further cement the Design language, and therefore increase on the rate of Deliverability, without having to consume all their time exclusively dedicated to it (imagine an AI tool, where a Designer can simply ask for a chat bot to be built, and all the professional as then to do is minimal tweaks in the component itself). As AI becomes more ingrained in the way that Designers work, this will become more and more apparent (it should make the solutioning process easier and even more organically ingrained in the journey of bringing something to life). The need for Production based artifacts will remain, but readjusted in a way where the Designer will need to position itself as a strategist, problem solver and an expert in leveraging those tools to best serve their needs and those of the Design process itself.

One of the items I’m going to tackle in one of my next articles is the term “Full Stack Product Designer” and what does that entail (or should entail). I have seen professionals utilize this term in a variety of different ways, however the reason I’m referring to it now, is due to the fact that one of the aspects these professionals are responsible for is artifact deliverability and quality control of those same artifacts. These professionals fully comprehend the breadth and scope of the Design Journey, which includes the role deliverability plays, and how they can leverage Design Systems, automation and even AI to serve their needs of scaling and increasing efficiency in the process. The whole topic of myopically forcing Designers to play a role of Production Artist is something that has lost its relevance. And not just because of technological advancements, but essentially because if a Design Process is rooted in its correct principles, this need for deliverability is part of a problem solving endeavor, where Designers are an active voice in co-guiding and co-strategizing the best options for its solution.

I’ll finish this article with a quote from Henry Ford on partnership:

“Coming together is a beginning, staying together is progress, and working together is success.”


Where does Production fit within the Design Cycle was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.