Latest / The Feed & The Thread / The Feed & The Thread - November 3, 2026

Transcript

The Feed & The Thread - November 3, 2026 · The Feed & The Thread

• 0:00
  Design systems are just rigid caches of past decisions. So
• 0:03
  they stop working the moment requirements change? Exactly,
• 0:06
  and Puhakka argues that's why they fail, so we're asking who
• 0:09
  owns the next step.
• 0:14
  Welcome to The Feed and The Thread, brought to you by
• 0:16
  Chicago Camps. The Feed & The Thread is available online at
• 0:19
  feed and thread dot com to submit your feeds, or download
• 0:22
  our app for all the feeds and threads delivered right to your
• 0:24
  pocket.
• 0:32
  The tools we use to build products are changing faster
• 0:35
  than the frameworks we use to govern them. We're seeing a push
• 0:38
  to replace static documentation with dynamic logic, and a
• 0:41
  warning that speed might be eroding the very thinking skills
• 0:44
  we need to design well. Pekka Oskari Puhakka at UX Design.cc
• 0:48
  argues in "State of a system" that traditional design systems
• 0:51
  fail because they act as rigid caches of past decisions. As
• 0:54
  requirements evolve, manual documentation and component
• 0:57
  libraries struggle to maintain coherence, especially when
• 1:00
  consolidating multiple business units into a single company-wide
• 1:03
  system. The core thesis proposes that governing an LLM skill
• 1:06
  could be a more effective basis for an evolving design system
• 1:10
  than relying solely on static components or code. This shifts
• 1:13
  the maintenance burden from updating files to updating the
• 1:16
  logic itself. Daniel Schwarz at CSS-Tricks marks the final issue
• 1:19
  of the series in "What’s !important #20: GTA 6 Scroll
• 1:22
  Effects, Scrollspies, random()", highlighting how the GTA 6
• 1:25
  website uses advanced scroll effects and modern CSS features.
• 1:28
  The piece also covers practical implementations like building
• 1:32
  scrollspies and using the random function for visual effects,
• 1:35
  alongside Lea Verou's deep dive into icon implementation and new
• 1:38
  features like scope and text- box. This curation serves as a
• 1:41
  bridge to future-proofing design systems, showing that modern CSS
• 1:45
  is increasingly capable of handling complex, state-driven
• 1:48
  interactions without heavy JavaScript. Jay Aragones at UX
• 1:51
  Design.cc reflects on teaching AI prototyping in "What I
• 1:54
  learned teaching AI prototyping at university", revealing a
• 1:57
  critical pitfall where students confused the capabilities of the
• 2:00
  building tools with the features of the resulting product. While
• 2:04
  using AI tools like Lovable gave students genuine confidence in
• 2:07
  building functional web applications, it risked eroding
• 2:10
  the conceptualization and foundational design skills
• 2:13
  necessary for high-quality UX. The speed of production is
• 2:16
  accelerating, but it may be outpacing the deep thinking
• 2:19
  required to define what should actually be built. Other reads
• 2:22
  available from UX Design.cc on virtue ethics in interfaces,
• 2:25
  color palette failures, and the pole and the stake.
• 2:35
  Today's discussions circle a core friction point, where the
• 2:38
  tools we use to build products are shifting faster than the
• 2:41
  frameworks we use to govern them. We're seeing a push to
• 2:44
  replace static documentation with dynamic logic, alongside a
• 2:47
  warning that speed might be eroding the very thinking skills
• 2:50
  we need to design well. Over on r/UXResearch, someone is trying
• 2:54
  to decode a standard hiring signal from a major tech
• 2:56
  company. They received a request for transcripts and
• 2:59
  questionnaires, and they're asking if this is a positive
• 3:02
  step or just a procedural dead end. The opacity of these
• 3:05
  pipelines is a real source of anxiety for early-career
• 3:08
  researchers, and the ambiguity of the process makes it hard to
• 3:11
  know where you stand. It's a reminder that the process itself
• 3:14
  is often the first barrier, not the interview. In
• 3:17
  r/ProductDesign, a user is asking how anyone navigates the
• 3:20
  complete inconsistency of clothing sizes across different
• 3:23
  brands. This is a significant friction point in e-commerce,
• 3:26
  where standardization fails and users are forced to rely on
• 3:29
  trial and error or inconsistent charts. It highlights a broader
• 3:32
  gap where digital interfaces try to impose order on a physical
• 3:35
  reality that refuses to be standardized. The so-what's
• 3:38
  clear: if we can't solve this low-level data consistency
• 3:41
  problem, we're building a facade of convenience. A practitioner
• 3:44
  in r/UserExperienceDesign shares a case study about a service
• 3:48
  blueprint that was ignored until operations staff filled in the
• 3:51
  backstage lanes themselves. The initial, polished diagram was
• 3:54
  discarded, but the co-created version became a permanent
• 3:57
  fixture in weekly meetings. The key difference was shifting from
• 4:00
  presenting a static artifact to facilitating a workshop where
• 4:03
  the actual workers defined the process. This is a powerful
• 4:06
  lesson in agency; the blueprint wasn't the problem, the
• 4:09
  ownership was. In r/ProductDesign, someone is
• 4:12
  introducing an open-source agentic development environment
• 4:15
  that bridges the gap between designers and engineers. The
• 4:18
  claim is that these roles are becoming more tightly coupled,
• 4:21
  with designers shipping code and engineers refining designs. This
• 4:24
  tool aims to support that convergence by providing a
• 4:27
  shared workspace. It's an interesting bet that the future
• 4:30
  of product work lies in collapsing the handoff, rather
• 4:33
  than managing it. Finally, in r/UserExperienceDesign, a
• 4:36
  student with a healthcare background is using a physical
• 4:39
  pill dispenser as a navigation metaphor for their portfolio.
• 4:42
  They're asking if this tangible, domain-specific model aids
• 4:45
  intuition or creates cognitive friction. It's a bold choice to
• 4:48
  ground digital architecture in a physical object, and it raises a
• 4:51
  valid question about how much context we can transfer from one
• 4:55
  medium to another. What ties these threads together is the
• 4:58
  tension between the speed of our tools and the depth of our
• 5:01
  thinking.
• 5:08
  The Feed and The Thread is brought to you by Chicago Camps.
• 5:11
  For a weekly and monthly exploration of the patterns and
• 5:14
  signals across UX, you can also check out Patterns and Signals
• 5:17
  at the website patterns and signals dot com. Chicago Camps
• 5:20
  will have more events in 2027. You can submit to be a speaker
• 5:23
  at a future event at Chicago Camps dot org.
• 5:32
  Puhakka's argument that we should govern design systems
• 5:35
  with LLM skills instead of static files is the most
• 5:37
  significant shift I've seen this week. It suggests that the logic
• 5:41
  itself becomes the source of truth, rather than the code or
• 5:43
  documentation we maintain. That's a bold claim, but I hear
• 5:46
  the frustration underneath it. We're spending more time
• 5:49
  updating Figma libraries and writing component docs than
• 5:52
  actually designing new interactions. If the system can
• 5:54
  infer the correct state from context, that removes a massive
• 5:57
  layer of administrative drag. The risk is that inference isn't
• 6:00
  governance. A static file is a contract, and a contract is
• 6:03
  enforceable. An LLM skill is a suggestion engine, and
• 6:06
  suggestion engines are probabilistic. You lose the
• 6:08
  ability to audit why a specific decision was made because the
• 6:11
  reasoning is hidden inside the model's weights. But
• 6:14
  auditability isn't the same as clarity. I look at the CSS-
• 6:17
  Tricks piece on GTA 6 scroll effects, and you see modern CSS
• 6:20
  handling complex state without JavaScript. That's
• 6:22
  deterministic. It's logical. If we can express that logic in a
• 6:25
  way an LLM can parse, we get the benefit of automation without
• 6:28
  losing the precision of the code. That's where I part ways
• 6:31
  with you. CSS is a language with strict syntax. LLM skills are
• 6:34
  natural language. Natural language is ambiguous. If you
• 6:37
  hand an ambiguous instruction to a model and it produces a
• 6:40
  component that looks right but breaks edge cases, who's
• 6:43
  accountable? The model? The prompt engineer? The system is
• 6:45
  too fragile to replace the structural integrity we get from
• 6:48
  explicit code. I'd argue that fragility is already here. We
• 6:51
  have brittle CSS, broken JS, and docs that are six months out of
• 6:54
  date. The new way offers greater resilience than the current
• 6:57
  mess. We need to treat the logic as the product, not the
• 7:00
  documentation. So the question is whether we can make the
• 7:03
  intent explicit enough that any tool, human or machine, can
• 7:06
  execute it without guessing. Exactly. The value lies in the
• 7:09
  clarity of the rules we build. If our logic is clear enough for
• 7:12
  an AI to follow, it's clear enough for a human to
• 7:14
  understand.
• 7:17
  That's The Feed and The Thread for today. We'll catch you next
• 7:20
  time!