{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigavb553uwufyhtbcjkk4jc6ns5uch37pzyz5r25td4rtv4p3guty",
    "uri": "at://did:plc:wbakieni5lec2yyexu3i7rct/app.bsky.feed.post/3mfjw4joiyq22"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreigcuabinlgcsme265jjz7lbi2wvrvvyvjmbbgmdmvhss2oegazui4"
    },
    "mimeType": "image/jpeg",
    "size": 377707
  },
  "description": "There's a tool for easily detecting AI generated content, the old design process is no longer valuable, and you really should never say you’re sorry (in design).",
  "path": "/designy-digest-002/",
  "publishedAt": "2026-02-23T14:59:17.000Z",
  "site": "https://www.designy.com",
  "tags": [
    "Design is Dead Final, FinalDesign is dead (again) and AI does all the heavy thinking for you—is that true? Yet, there is a fundamental framework that applies to any design process regardless the tool.DesignyDarrell Estabrook",
    "Our entire process was designed around one fear: Building the wrong thing is expensive. PRDs existed to make sure we build the right thing.\nDesign existed to make sure we build it right.\nReviews… | Matt Przegietka | 13 commentsOur entire process was designed around one fear: Building the wrong thing is expensive. PRDs existed to make sure we build the right thing.\nDesign existed to make sure we build it right.\nReviews, approvals, sign-offs,...\nall risk reduction layers because building was slow and costly. That made sense when a prototype\ntook a dev team 3 weeks.\nIt doesn’t when it takes 30 minutes. When the cost of building drops to near zero,\nthe entire process built around avoiding building... breaks. PRDs are already becoming a bottleneck.\nDesign is next. The role is flipping.\nFrom gatekeeping before the build to shaping after it. Instead of: Think → Specify → Design → Build\nIt’s becoming: Build → Evaluate → Refine → Document We used to need 3 layers of protection\nbefore writing code. Now we need taste, speed, and judgment after. The designers and PMs who thrive will be the ones\nwho stopped doing their jobs in the wrong order. ✌️ What do you think about this?\nHow will our work evolve? Let’s discuss. | 13 comments on LinkedInLinkedInMatt Przegietka",
    "Know purpose, know design",
    "Making messy design clear",
    "referral link to try GPTZero.",
    "There’s a phase in almost every design career where you start apologizing for the work. You overexplain.\nYou justify spacing, padding, component decisions.\nYou walk people through every pixel like… | Tyler WhiteThere’s a phase in almost every design career where you start apologizing for the work. You overexplain.\nYou justify spacing, padding, component decisions.\nYou walk people through every pixel like you’re asking for permission to exist in the room. I did that early on. A lot. I thought being collaborative meant making everyone comfortable. So I led with craft. With design language. With the how instead of the why. And every time I did that, I made design feel optional. What finally clicked for me was watching other disciplines.\nEngineering never apologizes for constraints.\nQA never explains why tests are necessary.\nTheir process is assumed to be required to do the job properly. Design is the only function that keeps trying to earn the right to do its work. And when you do that long enough, people start treating design like a nice-to-have. Something you include if there’s time. Something you skip when deadlines get tight. The shift wasn’t about being louder or more assertive. It was about changing the frame.\nStopping the pixel tour.\nStopping the jargon.\nAnd talking about consequences instead. What breaks if this isn’t tested.\nWhat risk we’re taking on by skipping this step.\nWhat it costs to fix after launch instead of before. Once design is framed as protection instead of preference, the dynamic changes. You’re no longer defending your process. You’re explaining the tradeoffs the business is about to make. That’s when the apologies stop. Not because you toughened up, but because the work finally sounded like what it is. Necessary.LinkedInTyler White",
    "get feedback that's productive and actionable."
  ],
  "textContent": "## Not just is design dead, but can it ever die?\n\nThere is so much clamor around the design process being dead. Really, after all these millennia?\n\nI walk through the a fundamental design process that underlays everything you ever hope to create, and how it works with communicating design to stakeholders. Check it out on The Daily Sprint, Episode 6.\n\nDesign is Dead Final, FinalDesign is dead (again) and AI does all the heavy thinking for you—is that true? Yet, there is a fundamental framework that applies to any design process regardless the tool.DesignyDarrell Estabrook\n\n## Oh well, the old product design process doesn’t work now\n\nOur entire process was designed around one fear: Building the wrong thing is expensive. PRDs existed to make sure we build the right thing.\nDesign existed to make sure we build it right.\nReviews… | Matt Przegietka | 13 commentsOur entire process was designed around one fear: Building the wrong thing is expensive. PRDs existed to make sure we build the right thing.\nDesign existed to make sure we build it right.\nReviews, approvals, sign-offs,...\nall risk reduction layers because building was slow and costly. That made sense when a prototype\ntook a dev team 3 weeks.\nIt doesn’t when it takes 30 minutes. When the cost of building drops to near zero,\nthe entire process built around avoiding building... breaks. PRDs are already becoming a bottleneck.\nDesign is next. The role is flipping.\nFrom gatekeeping before the build to shaping after it. Instead of: Think → Specify → Design → Build\nIt’s becoming: Build → Evaluate → Refine → Document We used to need 3 layers of protection\nbefore writing code. Now we need taste, speed, and judgment after. The designers and PMs who thrive will be the ones\nwho stopped doing their jobs in the wrong order. ✌️ What do you think about this?\nHow will our work evolve? Let’s discuss. | 13 comments on LinkedInLinkedInMatt Przegietka\n\nThis particular post came out as a mixed AI generated by GTPZero, but I was more interested in the graphic showing the _Old process_ and the _New process_ we’re encouraged to adopt.\n\nI go in depth on this on The Daily Sprint episode 6, Design is Dead Final, Final\n\nInteresting, but this is simply rearranging the deck chairs.\n\n“Thinking,” “Specifying,” and “Designing” are more relevant than ever and will be differentiator skills in the world of AI. Well, they've already been differentiators for decades of product design. Actually, for millennia of human history. It’s how we’re made.\n\nAI is short-circuiting the concept of design if it simply starts with building.\n\n> Defining purpose and discovering context is **critical** if any product will be designed to fulfill an **outcome**.\n\nYou can read more about what I mean by reading Know purpose, know design, and listening to the podcast on Making messy design clear.\n\n## Something’s up on LinkedIn\n\nThis week, I noticed something odd about certain LinkedIn posts. I suspected they were written by AI, but now I know. How?\n\nI stumbled upon a service called GPTZero.\n\nWhen you analyze text, it creates a report with the percentage chance the text was written by AI. The web app goes into extreme detail and lets you investigate sentence by sentence and why it was classified as _human_ or _AI._\n\nThere's a Chrome link which makes scanning LinkedIn posts, or any webpage content, very easy.\n\nGPTZero assessed this LinkedIn post with a 100% chance of being AI-generated. It sounds great, but by definition it’s not an original thought from the author. That is, even if we assume this was content based only on a library of the author’s own work, the output is contrived in such a way as to be detectable as being AI-generated.\n\nScreenshot of a LinkedIn post in February 2026 and GPTZero summary report\n\nI went to the web app and played around with running my own text through it and it comes back as 100% human. Even more, running text I generated with AI, even though it sounded great, came back as 100% AI. Editing that text came back with mixed percentages.\n\nIf you're trying to figure out if a post is AI only because it uses _em-dashes_ that's not going to cut it—believe me, I love em-dashes because they're so typographically interesting.\n\n> **Authentic writing** is a cornerstone of building **genuine relationships**. So, it's a shame to post something one didn't actually write. You can be sure **I'm writing this** and all the content at Designy and for The Daily Sprint podcast\n\nEven so, here’s the caution—this is an AI analysis and _AI can make mistakes!_ Even so, it’s fascinating to see there are so many uses of AI embedded in our everyday communication, but it doesn’t need to be.\n\nI’m including a referral link to try GPTZero. I'm happy for you to try it with or without the referral because it can come in handy during everyday browsing.\n\n## Do you say, “I’m sorry” in your design reviews?\n\nThere’s a phase in almost every design career where you start apologizing for the work. You overexplain.\nYou justify spacing, padding, component decisions.\nYou walk people through every pixel like… | Tyler WhiteThere’s a phase in almost every design career where you start apologizing for the work. You overexplain.\nYou justify spacing, padding, component decisions.\nYou walk people through every pixel like you’re asking for permission to exist in the room. I did that early on. A lot. I thought being collaborative meant making everyone comfortable. So I led with craft. With design language. With the how instead of the why. And every time I did that, I made design feel optional. What finally clicked for me was watching other disciplines.\nEngineering never apologizes for constraints.\nQA never explains why tests are necessary.\nTheir process is assumed to be required to do the job properly. Design is the only function that keeps trying to earn the right to do its work. And when you do that long enough, people start treating design like a nice-to-have. Something you include if there’s time. Something you skip when deadlines get tight. The shift wasn’t about being louder or more assertive. It was about changing the frame.\nStopping the pixel tour.\nStopping the jargon.\nAnd talking about consequences instead. What breaks if this isn’t tested.\nWhat risk we’re taking on by skipping this step.\nWhat it costs to fix after launch instead of before. Once design is framed as protection instead of preference, the dynamic changes. You’re no longer defending your process. You’re explaining the tradeoffs the business is about to make. That’s when the apologies stop. Not because you toughened up, but because the work finally sounded like what it is. Necessary.LinkedInTyler White\n\nThis was 100% written by human Tyler White according to GPTZero. He makes a great point about apologizing for your designs. Although his point is to turn the conversation to making the observer think about consequences of the design.\n\nI have a more collaborative approach.\n\nTyler is correct—you never should defend your designs. However, you should always explain them. What's the difference?\n\nDefending weakens your position as the lead designer. It's admitting you didn't design it well. That makes the design subjective.\n\nInstead, explaining the design reveals the reason for every design decision you made. That's leadership and that's objective.\n\nThe trick, though? You have to have a clear understanding of what the intended outcome was for the feature or app you're designing before you begin. If the outcome was vague and you never clarified it, then those design decisions will come across as a miss.\n\nEven so, there's a clear way to get feedback that's productive and actionable.\n\n* * *\n\nThanks for reading. Have a great day designing with a _why._",
  "title": "Designy Digest / 002",
  "updatedAt": "2026-04-28T12:43:31.900Z"
}