Process Theater

Process theater is the performative display of design activities offering little genuine contribution to the final product or problem solved. It is the elaborate documentation of steps either skipped, faked, or retrospectively applied to create the illusion of a rigorous design process. Think design cosplay: wearing the costume of a designer following a method, but not doing the work. This often manifests in portfolios as endless slides of generic persona profiles, stock photo empathy maps, or moodboards with no discernible connection to the shipped product. It is the "double diamond" diagram meticulously recreated on a slide, but with no specific, impactful decisions tied to each phase. The goal is to impress by quantity of documentation, not quality of outcome. It is a smokescreen, obscuring a lack of genuine insight, critical thinking, or shipping ability. In 2026, with tools like Cursor and Claude Code enabling rapid, one-session builds, process theater stands exposed as a time sink and credibility killer. It is the difference between a chef showing a beautifully bound recipe book and a chef serving a perfectly cooked meal. The book might impress, but the meal proves skill. Process theater is the recipe book when the kitchen was never used. It is the 47-screen deck detailing every theoretical step, while the actual product is a fragile prototype that barely functions, or worse, never shipped. It is the elaborate charade of design, where performance itself becomes the product, overshadowing real value creation. This is the core of the "bloated case study" problem: process artifacts become the end, not the means.

Process theater is not genuine design thinking. It is not the messy, iterative, non-linear journey of problem discovery, ideation, and validation that leads to impactful products. It is not the documentation of hard-won insights, critical trade-offs, or difficult decisions that shaped a product. True designers make choices based on research, testing, and constraints. They kill ideas, pivot, and learn from failure. Process theater, by contrast, presents a sanitized, linear, and often fabricated narrative where every step leads seamlessly to a predetermined, perfect outcome. It avoids showing the fork in the road, the alternative rejected, or the reason why. It avoids demonstrating judgment. It is not about proving you can ship something that works, or that you understood the problem deeply enough to frame it correctly. It does not reflect the "two decisions that actually shaped the product" from the article. Instead, it focuses on superficial trappings: visual artifacts, jargon, performative rituals, without underlying substance. It is not a transparent account of how a solution was reached, but rather a retrospective justification for a solution that may or may not have been effective. It is not about proving your ability to navigate complexity or deliver tangible results. It is the antithesis of the "artifact is the argument" mindset, where the working product itself provides the most compelling evidence of skill. It is not the rigorous application of methods like user research or usability testing to genuinely inform design decisions; it is the mere mention or display of these methods without demonstrating their actual impact. It is a performance, not a practice.

Imagine a portfolio review for a senior product design role in 2024. Candidate A presents a 50-slide deck. The first ten slides are "Discovery Phase" with stock photos of people collaborating. Slides 11-15 introduce "Persona Emily," a 35-year-old marketing manager who "values efficiency." Her quotes are generic. Slides 16-20 showcase an "Empathy Map" filled with obvious observations: "Emily thinks her job is stressful," "Emily feels overwhelmed by too many tools." No unique insight. Slides 21-25 display a "Moodboard" with keywords like "modern, clean, intuitive," yet the final product screens are dense and feature-heavy. The next 15 slides walk through a "Double Diamond" process, meticulously detailing "Define," "Ideate," "Develop," and "Deliver" phases, but each phase is described with vague bullet points. No specific design decisions or user feedback loops are mentioned. The reviewer asks, "How did Emily's specific pain point about tool overload lead to simplifying the onboarding flow?" Candidate A fumbles, points to a slide titled "Problem Framing," and says, "We identified user pain points through our persona work." The connection is tenuous. The final product screens are high-fidelity mockups; the reviewer cannot click, interact, or know if the product shipped or solved Emily's problem. This is process theater in full swing: a meticulously crafted narrative of how design should happen, rather than an honest account of what actually happened and what shipped. It is the illusion of rigor without the substance of impact. Contrast this with Candidate B, who opens with a live URL to a working product, then presents three slides: "We tried X, it broke trust at checkout, so we did Y," "We killed Z feature because it added cognitive load for new users," and "We chose this payment provider over that one because of better fraud detection in our target market." Candidate B wins the room.

Process theater has virtually no legitimate use in professional design where outcomes matter. It is a performance designed to obscure, not enlighten. When to use it? Almost never. Perhaps as a cautionary tale in a design school lecture, illustrating the pitfalls of superficial documentation. In highly regulated industries, a bare minimum of "process documentation" might be required for compliance, but even then, genuine traceability should be the goal, not performative fluff. If your objective is to impress someone who values the appearance of rigor over actual results, process theater might briefly serve, but such an audience is rarely worth impressing. It is a short-term tactic undermining long-term credibility. When not to use it? Always. Applying for a design role in 2026, especially one demanding shipping, impact, or genuine problem-solving, makes process theater a liability. Hiring managers increasingly look for designers who demonstrate tangible results, not just theoretical methodology. The article states: "A working thing someone can click now beats a process document nobody finishes reading." Your portfolio's job shifts from "prove I followed a process" to "prove I can ship something that works." Do not use process theater to prove taste, judgment, or problem framing. These scarce skills are demonstrated through honest accounts of decisions made, alternatives rejected, and problems understood, not generic persona slides. Do not use it when presenting to stakeholders who demand ROI or measurable impact. They will see through the performance and question your value. Do not use it if you want to be seen as a designer who makes things, not just documents things. The era of "shipping is nearly free" means the proof has moved. Your evidence should be a live URL and a concise decisions log, not a bloated deck full of process theater. It is a relic of a time when building the real thing was expensive and slow. Now, it is just bad practice.

Process theater is the performance of design, not the practice of it, and it always gets booed off the stage by anyone who actually ships.