<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>UX on Radical Optimist</title><link>https://radoptimist.org/en/tags/ux/</link><description>Recent content in UX on Radical Optimist</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 01 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://radoptimist.org/en/tags/ux/index.xml" rel="self" type="application/rss+xml"/><item><title>Ticketing Systems Are an Antipattern for Team Collaboration</title><link>https://radoptimist.org/en/post/ticketing-systems-are-an-antipattern-for-team-collaboration/</link><pubDate>Wed, 01 Apr 2026 00:00:00 +0000</pubDate><guid>https://radoptimist.org/en/post/ticketing-systems-are-an-antipattern-for-team-collaboration/</guid><description>&lt;h1 id="the-ticketing-system-user-interface-is-an-antipattern-for-cross-team-collaboration">The ticketing system user interface is an antipattern for cross-team collaboration&lt;/h1>
&lt;p>If your team spends most of its time managing a ticketing system — filing requests, triaging queues, waiting for answers — you have already made your collaboration legible to a machine.&lt;/p>
&lt;p>That is not a metaphor. Ticketing systems only work for the kind of work AI handles well: routine, well-defined, known destination, repeatable process. If your collaboration looks like a queue, it can be automated. And it will be.&lt;/p></description></item><item><title>📖 Nudge: Why Product Managers Should Become Proficient Choice Architects</title><link>https://radoptimist.org/en/post/nudge-why-product-managers-should-become-proficient-choice-architects/</link><pubDate>Wed, 23 Jun 2021 11:49:49 +0000</pubDate><guid>https://radoptimist.org/en/post/nudge-why-product-managers-should-become-proficient-choice-architects/</guid><description>Designing a great choice architecture should be one of your core responsibilities as a product manager.</description></item><item><title>Trifecta: How to maximize a product teams impact</title><link>https://radoptimist.org/en/post/trifecta-product-teams-and-impact/</link><pubDate>Sun, 20 Sep 2020 07:03:22 -0400</pubDate><guid>https://radoptimist.org/en/post/trifecta-product-teams-and-impact/</guid><description>&lt;h1 id="introduction--definition">Introduction &amp;amp; Definition&lt;/h1>
&lt;p>In this blog post, we’ll explore the concept of “trifecta” (also called triad in some organizations) that I have seen used successfully in the past both at start-up and even at large scale organizations (ex: Shopify).&lt;/p>
&lt;p>Let’s start with a definition. The trifecta represents a subset of a product team whose goals are to capture systematically:&lt;/p>
&lt;ul>
&lt;li>value: for the business&lt;/li>
&lt;li>usability: for the user&lt;/li>
&lt;li>feasibility: technological, ethical, legal, etc.&lt;/li>
&lt;/ul>
&lt;h1 id="valuable--usable--feasible-are-the-trifecta-goal">Valuable &amp;amp; Usable &amp;amp; Feasible are the trifecta goal!&lt;/h1>
&lt;p>I will use the term craft in this article and would also like to define it: a craft is one or more people inside the product-team with their hierarchy, rituals and specialties. Example of craft includes engineering (sometimes back-end, front-end, mobile), UX (designer, researcher, content specialist, etc.), Product (product manager, product owner, product lead, etc.), data-science (data-scientist, etc.), commercial, legal, etc. Each organization is different and has a different structure to execute its mission. In this article, I will refer to “craft” as the various specialties &amp;amp; hierarchies that exist within the organization.&lt;/p></description></item><item><title>Don't give us MVPs we want minimally enjoyable products!</title><link>https://radoptimist.org/en/post/dont-give-us-mvps-we-want-mjps-minimally-enjoyable-products-an-analysis/</link><pubDate>Fri, 01 May 2020 07:25:40 -0400</pubDate><guid>https://radoptimist.org/en/post/dont-give-us-mvps-we-want-mjps-minimally-enjoyable-products-an-analysis/</guid><description>&lt;h1 id="minimally-viable-products-are-a-myth-or-if-you-prefer-a-mental-model-always-wrong-but-sometimes-useful">Minimally Viable Products are a myth or, if you prefer a mental model. Always wrong but sometimes useful.&lt;/h1>
&lt;figure class="zoomable-img" onclick="window.__zoomImg(this.dataset.zoomSrc || this.querySelector('img').src, this.querySelector('img').alt)">
 &lt;img src="https://radoptimist.org/images/how-to-build-a-mvp.webp"
 alt="Original Image: Making sense of MVP (Minimum Viable Product) and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg"
 loading="lazy" />
 &lt;svg class="zoomable-hint" xmlns="http://www.w3.org/2000/svg" width="22" height="22" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">&lt;circle cx="11" cy="11" r="8"/>&lt;line x1="21" y1="21" x2="16.65" y2="16.65"/>&lt;line x1="11" y1="8" x2="11" y2="14"/>&lt;line x1="8" y1="11" x2="14" y2="11"/>&lt;/svg>
 &lt;figcaption>Original Image: Making sense of MVP (Minimum Viable Product) and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg&lt;/figcaption>
&lt;/figure>



&lt;script>
(function() {
 var dialog = document.createElement('dialog');
 dialog.id = 'zoomable-dialog';
 dialog.innerHTML = '&lt;img class="zoomable-modal__img" src="" alt="" />';
 document.body.appendChild(dialog);

 dialog.addEventListener('click', function(e) {
 dialog.close();
 });

 window.__zoomImg = function(src, alt) {
 var img = dialog.querySelector('img');
 img.src = src;
 img.alt = alt || '';
 dialog.showModal();
 };

 window.__zoomClose = function() {
 dialog.close();
 };
})();
&lt;/script>


&lt;p>Very much like Prometheus and the fire or Icarus and the sun they are powerful analogies and ideas that shape our view of the world. A tribute to their power is that, thousands of years after their creation, we still relate to them even if their initial context is long gone.&lt;/p></description></item></channel></rss>