<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Design — WkndPrjct</title><link>https://wkndprjct.id/domains/design/</link><description>Technology, history, systems, and human behavior share the same underlying patterns. WkndPrjct finds the connections.</description><language>en-us</language><lastBuildDate>Mon, 06 Jul 2026 12:05:13 +0000</lastBuildDate><atom:link href="https://wkndprjct.id/domains/design/index.xml" rel="self" type="application/rss+xml"/><item><title>The Diagram That Fixed the Room</title><link>https://wkndprjct.id/articles/the-diagram-that-fixed-the-room/</link><guid>https://wkndprjct.id/articles/the-diagram-that-fixed-the-room/</guid><pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate><category>Design</category><category>Systems</category><category>Organizations</category><description>The Diagram That Fixed the Room In 1942, engineers working on wartime logistics could not solve some problems with speeches. The system was too large: ships, ports, factories, convoys, fuel, weather, spare parts, enemy movement. The work became visible through maps, boards, flows, and status rooms.</description><content:encoded><![CDATA[<h1 id="the-diagram-that-fixed-the-room">The Diagram That Fixed the Room</h1>
<p>In 1942, engineers working on wartime logistics could not solve some problems with speeches. The system was too large: ships, ports, factories, convoys, fuel, weather, spare parts, enemy movement. The work became visible through maps, boards, flows, and status rooms.</p>
<p>The visualization did not simplify the war. It simplified the conversation enough for decisions to happen.</p>
<p>The same pattern appears in much smaller rooms.</p>
<h2 id="the-story">The Story</h2>
<p>Tom Wujec&rsquo;s TED talk uses a deceptively ordinary exercise: ask people to draw how to make toast. The drawings expose how people model systems differently. Some focus on objects. Some focus on sequence. Some include the human. Some omit the power source.</p>
<p>The point is not toast. The point is that language often hides model differences.</p>
<p>A leadership team says it wants to improve &ldquo;customer onboarding.&rdquo; Everyone agrees. The phrase feels clear. Then someone maps the current onboarding process. The map has seventeen handoffs, four duplicated data entries, two invisible approval steps, and no owner for the moment when the customer gets confused.</p>
<p>Before the diagram, the team agreed. After the diagram, they finally understood what they had agreed about.</p>
<h2 id="three-ways-this-appears">Three Ways This Appears</h2>
<p><strong>In everyday life:</strong> A couple argues about household work. Both say the division is unfair. When they map the recurring tasks, invisible planning labor appears: remembering appointments, noticing empty supplies, anticipating deadlines. The argument changes because the system becomes visible.</p>
<p><strong>In technology:</strong> A team claims the deployment process is simple. A sequence diagram reveals hidden manual checks, undocumented permissions, and one engineer who is effectively the release system.</p>
<p><strong>In organizations:</strong> A company says strategy is blocked by execution. A dependency map shows the opposite: execution is blocked by unresolved strategic contradictions.</p>
<h2 id="the-pattern">The Pattern</h2>
<p>Diagrams reduce the cost of shared attention.</p>
<p>A verbal discussion forces each person to hold a model privately while comparing it to other people&rsquo;s words. A diagram externalizes the model. Once externalized, it can be corrected, challenged, annotated, and improved.</p>
<p>The diagram is not evidence by itself. It is a negotiation surface for evidence.</p>
<h2 id="the-cross-domain-connection-cartography">The Cross-Domain Connection: Cartography</h2>
<p>Maps changed exploration because they allowed knowledge to accumulate outside any single traveler. A coastline seen by one ship could be corrected by another. The map became a shared memory system.</p>
<p>Process diagrams do the same for organizations. They let experience accumulate beyond individual memory. They also show where the official map differs from the territory people actually travel.</p>
<h2 id="the-framework-model-externalization">The Framework: Model Externalization</h2>
<div class="mermaid">graph TD
    A[Shared word] --&gt; B[Private models]
    B --&gt; C[Draw the process]
    C --&gt; D[Expose missing steps]
    D --&gt; E[Name disagreements]
    E --&gt; F[Revise shared model]</div>
<h2 id="why-this-matters-outside-technology">Why This Matters Outside Technology</h2>
<p>Any repeated argument may be a mapping problem. People are often disagreeing not about values but about the system they believe exists. Until the model is externalized, the disagreement stays personal.</p>
<p>Drawing is not childish. It is one of the fastest ways to make hidden structure accountable.</p>
<h2 id="the-memorable-sentence">The Memorable Sentence</h2>
<blockquote>
<p>A diagram is where vague agreement goes to become useful disagreement.</p></blockquote>
<h2 id="closing-question">Closing Question</h2>
<blockquote>
<p>What process in your work is still being debated in words because nobody has forced the system onto a page?</p></blockquote>
]]></content:encoded></item><item><title>The Statistic That Changed Shape</title><link>https://wkndprjct.id/articles/the-statistic-that-changed-shape/</link><guid>https://wkndprjct.id/articles/the-statistic-that-changed-shape/</guid><pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate><category>Technology</category><category>Design</category><category>History</category><description>The Statistic That Changed Shape In 1854, John Snow&amp;amp;rsquo;s cholera data mattered because it had a shape. Deaths plotted on a map told a story that a table could not. The same numbers, arranged differently, made a different inference possible.</description><content:encoded><![CDATA[<h1 id="the-statistic-that-changed-shape">The Statistic That Changed Shape</h1>
<p>In 1854, John Snow&rsquo;s cholera data mattered because it had a shape. Deaths plotted on a map told a story that a table could not. The same numbers, arranged differently, made a different inference possible.</p>
<p>Data did not become more true when mapped. It became more usable.</p>
<p>This distinction still decides decisions.</p>
<h2 id="the-story">The Story</h2>
<p>Hans Rosling&rsquo;s TED talk became famous not merely because it showed statistics, but because it animated them. Countries moved. Time became visible. Assumptions about wealth, health, and development could be watched changing instead of argued abstractly.</p>
<p>The lesson is larger than presentation.</p>
<p>A product team reviews churn by segment in a spreadsheet. Enterprise churn is low. Small business churn is high. The conclusion seems obvious: focus retention work on small business customers. Then an analyst displays churn over account age. A different pattern appears: small businesses churn early or become stable, while enterprise accounts quietly decay after year three.</p>
<p>The statistic changed shape. The strategy changed with it.</p>
<h2 id="three-ways-this-appears">Three Ways This Appears</h2>
<p><strong>In everyday life:</strong> A person tracks spending by category and sees restaurants as the problem. When they plot spending by mood and day of week, the pattern changes: exhaustion drives delivery orders after late meetings. The budget issue is a calendar issue.</p>
<p><strong>In technology:</strong> A reliability team tracks incidents by service. One service looks worst. When incidents are mapped by dependency chain, the real problem is a shared library that never appears as the failing service.</p>
<p><strong>In organizations:</strong> A company measures attrition by department. One department looks unhealthy. When attrition is plotted by manager tenure, the signal moves: the risk is not the department but the handoff period after leadership changes.</p>
<h2 id="the-pattern">The Pattern</h2>
<p>Every data display is an argument about what relationships matter.</p>
<p>Rows emphasize individual records. Lines emphasize change. Maps emphasize place. Networks emphasize dependency. Cohorts emphasize time since entry. Each representation reveals some truths and hides others.</p>
<p>The danger is believing the first useful representation is the true one.</p>
<h2 id="the-cross-domain-connection-architecture">The Cross-Domain Connection: Architecture</h2>
<p>A building directs attention through walls, doors, and sightlines. A museum can make one painting feel central and another incidental by where it places them. The paintings have not changed. The interpretive path has.</p>
<p>Data environments do the same thing. They build corridors for thought. A dashboard is not a neutral surface. It is an architecture of attention.</p>
<h2 id="the-framework-representation-rotation">The Framework: Representation Rotation</h2>
<div class="mermaid">graph TD
    A[Question] --&gt; B[Table]
    B --&gt; C[Trend]
    C --&gt; D[Cohort]
    D --&gt; E[Map or network]
    E --&gt; F{Same conclusion?}
    F --&gt;|Yes| G[Higher confidence]
    F --&gt;|No| H[Investigate hidden relationship]</div>
<h2 id="why-this-matters-outside-technology">Why This Matters Outside Technology</h2>
<p>Public debates often fail because the same data is trapped in the wrong shape. Averages hide distribution. Rankings hide uncertainty. Totals hide per-capita differences. Percentages hide base rates.</p>
<p>Better judgment begins by asking: what shape would this information need to take for the pattern to become visible?</p>
<h2 id="the-memorable-sentence">The Memorable Sentence</h2>
<blockquote>
<p>Data does not speak for itself; it speaks through the shape we force it to take.</p></blockquote>
<h2 id="closing-question">Closing Question</h2>
<blockquote>
<p>What important metric in your work has only ever been seen in one shape?</p></blockquote>
]]></content:encoded></item><item><title>The Architecture of Decisions</title><link>https://wkndprjct.id/articles/the-architecture-of-decisions/</link><guid>https://wkndprjct.id/articles/the-architecture-of-decisions/</guid><pubDate>Sat, 27 Jun 2026 00:00:00 +0000</pubDate><category>Design</category><category>History</category><category>Systems</category><description>Between 1929 and 1968, Robert Moses shaped the physical infrastructure of New York City more than any elected official. He built highways, parks, bridges, and housing projects with an authority that derived not from election but from control of obscure public authorities that were largely invisible to political oversight.</description><content:encoded><![CDATA[<p>Between 1929 and 1968, Robert Moses shaped the physical infrastructure of New York City more than any elected official. He built highways, parks, bridges, and housing projects with an authority that derived not from election but from control of obscure public authorities that were largely invisible to political oversight.</p>
<p>Robert Caro, in <em>The Power Broker</em> — the 1,162-page biography of Moses published in 1974 — documented one specific decision that illustrates how architectural choices function as policy. The Southern State Parkway on Long Island, built in the 1920s and 1930s, connected New York City to Jones Beach and other recreational areas. The overpasses on the parkway were built to a height of nine feet.</p>
<p>Public buses required twelve feet to pass beneath an overpass. Private automobiles required about six.</p>
<p>The height limitation — which Caro documents as deliberate — effectively restricted access to Jones Beach to people who owned private automobiles. In 1920s and 1930s America, that meant people with sufficient income. African Americans, who were largely excluded from automobile ownership by economic discrimination, were also excluded from the beach — not by any statute, but by the height of an overpass.</p>
<p>Moses&rsquo;s overpasses remained at nine feet for decades after his power ended. The policy — expressed not in law but in concrete — outlasted the policymaker.</p>
<hr>
<p>The mechanism Moses exploited — or discovered, or invented — is the same across contexts: <strong>physical and structural design shapes behavior without requiring enforcement, and persists without requiring maintenance</strong>. A law must be enforced. An architecture simply is.</p>
<p>Software default settings operate on the same principle at vastly greater scale. When Facebook changed its default privacy setting from &ldquo;friends only&rdquo; to &ldquo;friends of friends&rdquo; in 2009, the behavioral change across millions of users was immediate and did not require any user to make a decision. The default was the decision. Most users never encountered the choice at all.</p>
<hr>
<p>Organizational structures are architectural decisions that shape every decision made within them. A technology company structured with engineering reporting to product management will make product decisions differently than one with product reporting to engineering — not because of any directive, but because the structure determines whose priorities are treated as constraints and whose are treated as goals.</p>
<p>The structure changes. The people change. The decisions shaped by the structure change. The mechanism — architecture as invisible policy — remains constant.</p>
<h2 id="the-memorable-sentence">The Memorable Sentence</h2>
<blockquote>
<p>A law must be enforced; an architecture simply is.</p></blockquote>
<h2 id="closing-question">Closing Question</h2>
<blockquote>
<p>What decisions made in the past are currently shaping the behavior of your organization, your product, or your city — without any living person having made a recent choice to maintain them?</p></blockquote>
]]></content:encoded></item><item><title>The Difference Between a Rule and a Principle</title><link>https://wkndprjct.id/articles/the-difference-between-a-rule-and-a-principle/</link><guid>https://wkndprjct.id/articles/the-difference-between-a-rule-and-a-principle/</guid><pubDate>Wed, 10 Jun 2026 00:00:00 +0000</pubDate><category>History</category><category>Organizations</category><category>Design</category><description>The Difference Between a Rule and a Principle In December 1944, Allied forces in Belgium faced a situation that no military manual had anticipated. German troops, dressed in American uniforms and driving captured American vehicles, had infiltrated behind Allied lines. The standing rule for challenging unknown soldiers — &amp;amp;ldquo;halt, who goes there?&amp;amp;rdquo; — had become useless. The Germans spoke English. They knew the passwords. They had the right equipment.</description><content:encoded><![CDATA[<h1 id="the-difference-between-a-rule-and-a-principle">The Difference Between a Rule and a Principle</h1>
<p>In December 1944, Allied forces in Belgium faced a situation that no military manual had anticipated. German troops, dressed in American uniforms and driving captured American vehicles, had infiltrated behind Allied lines. The standing rule for challenging unknown soldiers — &ldquo;halt, who goes there?&rdquo; — had become useless. The Germans spoke English. They knew the passwords. They had the right equipment.</p>
<p>Field commanders improvised. Instead of asking soldiers to identify themselves, they asked them questions that no German spy could be expected to answer: Who won the 1942 World Series? What is the name of Mickey Mouse&rsquo;s dog? What city is Soldier Field in?</p>
<p>The rule (&ldquo;ask for the password&rdquo;) had broken down because circumstances had changed. But the principle behind the rule — <em>establish whether this person is who they claim to be</em> — survived perfectly. The commanders who understood the principle adapted immediately. Those who followed only the rule were paralyzed.</p>
<p>In the Talmudic tradition, legal scholars understood this distinction long before military commanders needed to apply it. Every ruling in the Talmud is accompanied by its reasoning — not because the rabbis wanted to be thorough, but because they understood something about how knowledge travels across time: the ruling without its reasoning can only be applied to cases identical to the original. The ruling with its reasoning can be applied, modified, or distinguished in situations the original decision-maker never anticipated.</p>
<p>Rules without principles are single-use tools. Principles expressed through illustrative rules are generative.</p>
<h2 id="the-story">The Story</h2>
<p>A software company has a rule: no deployments on Friday afternoons. The rule came from a painful incident in 2019 when a Friday deployment caused an outage that lasted through the weekend, with no senior engineers available to fix it. The rule was correct.</p>
<p>In 2023, the company has a new deployment infrastructure with automated rollback, 24/7 on-call coverage, and a response time measured in minutes rather than hours. The conditions that made Friday deployments dangerous no longer fully apply.</p>
<p>A new engineer, seeing an important hotfix that would benefit customers if deployed immediately, asks why it cannot go out on Friday. &ldquo;It&rsquo;s our rule,&rdquo; she is told. No one can explain why the rule exists. The rule was preserved without the reasoning that made it sensible, and without the reasoning, it cannot be evaluated against changed conditions.</p>
<p>Meanwhile, at the same company, a different rule is being applied. The company has a principle about deployments: &ldquo;Minimize the blast radius of any change — deploy when the ability to monitor and respond is highest.&rdquo; A senior engineer uses this principle to evaluate the Friday hotfix: the on-call coverage is good, the rollback is automated, the change is small. She approves it.</p>
<p>One company has two things that look like rules. One is a rule. One is a principle wearing a rule&rsquo;s clothing. They behave very differently in novel situations.</p>
<h2 id="three-ways-this-appears">Three Ways This Appears</h2>
<p><strong>In everyday life:</strong> A family has a rule: no screen time before homework is done. The principle behind it: schoolwork requires full cognitive attention that screens deplete. A child asks to watch an educational documentary related to their homework topic. The rule says no. The principle, applied, says yes. A family that can only apply the rule is poorly equipped for the novel situation. A family that understands the principle has a basis for judgment.</p>
<p><strong>In technology:</strong> A security team has a rule: all external API calls must go through the approved gateway. A developer building a new tool encounters an edge case where the gateway adds unacceptable latency for a non-critical internal process. Without understanding why the gateway exists (security audit trail, rate limiting, credential management), the developer cannot evaluate whether the edge case justifies an exception.</p>
<p><strong>In organizations:</strong> A procurement policy requires three competitive bids for any purchase above $10,000. The policy exists because unbid procurement historically produced overpaying and favoritism. A manager needs to renew a contract with a specialized vendor who is the only qualified provider in their space. Three bids are not possible. Without understanding the principle (ensure competitive pricing and prevent favoritism), the manager cannot apply it intelligently to a situation the rule did not anticipate.</p>
<h2 id="the-pattern">The Pattern</h2>
<p>Every rule was once a decision. The decision was made in response to a specific situation, by a person using their best available judgment at the time. The rule is the crystallized form of that decision — a prescription for future situations that the decision-maker recognized would be similar.</p>
<p>Rules transmit the conclusion. Principles transmit the reasoning. Both travel forward in time. Only one of them adapts.</p>
<p>When the future situation closely resembles the original, the rule performs well. When the future situation diverges — when context changes, when conditions evolve, when edge cases appear — the rule either fails rigidly (it prescribes the wrong action) or is ignored arbitrarily (people work around it without understanding it). The principle, by contrast, can be applied to the novel situation: not by asking &ldquo;is this case covered by the rule?&rdquo; but &ldquo;does the reasoning that produced the rule apply to this case?&rdquo;</p>
<p>The institutions that transmit principles with their illustrative rules maintain adaptive capacity across time and personnel change. The institutions that transmit only rules lose the ability to handle situations the rule-makers did not anticipate. They become rule-followers without judgment.</p>
<h2 id="the-cross-domain-connection-the-common-law-tradition">The Cross-Domain Connection: The Common Law Tradition</h2>
<p>Common law legal systems (England, the United States, Commonwealth countries) have a distinctive approach to law: rather than codifying all rules in advance, they build the law through the accumulation of decided cases. Each decision becomes a precedent — a rule. But the precedent travels with its reasoning (the ratio decidendi), which tells future courts why the rule was made.</p>
<p>This allows common law to evolve. A court facing a new situation does not simply ask &ldquo;is there a rule for this?&rdquo; It asks &ldquo;what principles do the relevant precedents embody, and how do those principles apply here?&rdquo; The precedents provide rules; the reasonings provide principles; the combination allows the legal system to address situations no legislature or prior court anticipated.</p>
<p>Civil law systems (France, Germany, most of the rest of the world) work differently: the rules are codified in advance. When a genuinely novel case arises, there may be no directly applicable rule. The judge must interpret the code&rsquo;s principles, which is harder when the principles are embedded in the code&rsquo;s structure rather than articulated in accompanying reasoning.</p>
<p>Both systems are functional. They handle the rule-principle transmission problem differently, with different tradeoffs for adaptability and predictability.</p>
<h2 id="the-framework-rule-principle-transmission">The Framework: Rule-Principle Transmission</h2>
<div class="mermaid">graph TD
    A[Decision made] --&gt; B[Rule extracted]
    B --&gt; C{Transmitted with?}
    C --&gt;|Rule only| D[Future: apply rule or ignore rule]
    C --&gt;|Rule &#43; reasoning| E[Future: apply principle to novel cases]

    D --&gt; F{Novel situation?}
    F --&gt;|Similar to original| G[Rule works]
    F --&gt;|Different from original| H[Rule fails or is bypassed]

    E --&gt; I{Novel situation?}
    I --&gt;|Similar to original| J[Rule works]
    I --&gt;|Different from original| K[Principle guides judgment]

    H --&gt; L[Rule becomes obstacle or dead letter]
    K --&gt; M[Adaptive institution]</div>
<h2 id="why-this-matters-outside-technology">Why This Matters Outside Technology</h2>
<p>Professional education, organizational culture, family wisdom, legal systems — all face the same transmission problem. How do you convey not just what to do but why, in a way that allows the recipient to apply the why to situations you never anticipated?</p>
<p>The answer is always some version of the same thing: carry the reasoning alongside the rule. Make the decision&rsquo;s origin visible. Connect the prescription to the problem it was designed to solve. Give the recipient enough of the original judgment that they can exercise judgment, not just compliance, when the original situation no longer exactly applies.</p>
<h2 id="the-memorable-sentence">The Memorable Sentence</h2>
<blockquote>
<p>A rule without its reasoning is a tool for yesterday&rsquo;s problems — the reasoning is what makes it applicable to problems that haven&rsquo;t happened yet.</p></blockquote>
<h2 id="closing-question">Closing Question</h2>
<blockquote>
<p>What are the most important rules in your organization or team — and could you explain, for each one, what problem it was designed to solve, and whether that problem still exists?</p></blockquote>
]]></content:encoded></item></channel></rss>