The Pudding 公開的三部教學，作者 Ilia Blinderman，2017 年起陸續寫成，原標題是 How To Make Dope Shit on The Internet。三部依序處理資料、設計、敘事。
寫這套東西的理由是讀者一直來信問怎麼學會做這種東西，而這個領域既沒有定形，也沒有制式工具，資源又散——不是只講資料分析，就是只講視覺化，湊不出完整的路徑。
貫穿三部的一個主張
作者在第一部開頭就把話講明：人有一種奇怪的傾向，會假設那些做得到我們做不到的事的人，天生就有比較好的才能。他的反駁很直接：
把新手和站上研討會講台的人分開的，只有時間與練習。
這條在三部裡各出現一次。第一部說學程式之所以讓人抓狂，是因為它要學的不是一組指令而是一種思考方式；第二部引 D3 作者 Mike Bostock 的說法，品質是投入時數的函數，不是天賦；第三部則把技術焦慮直接指認為讓更多人卻步的最大障礙。
第一部的結語只有兩句，第二句是：感到害怕、覺得爛透了，然後硬撐過去。這與Vibe Coding記的「做了之後就會了」是同一件事的兩種語氣。
第一部：資料
團隊的背景橫跨商業、資訊工程、心理學、海洋生物學與新聞。作者的描述是大體上他們都是通才，各有偏好但都同時使用一種通用程式語言、一組資料分析工具，以及 JavaScript。這一句與通才優勢主張的跨域交集是同一個現象的內部視角。
工具全部免費且開源。作者刻意強調這點，因為他要證明的是進入這行的最大門檻是時間與毅力，不是工具的價格。
團隊內部的分工也不統一：作者偏好 Python，Russell 用 JavaScript／Node 處理資料，Amber 用 R，Matt 用 MySQL 做大量數字運算，而基本分析用 Excel 或 Google Sheets 也可以。原文的立場是看任務挑工具，沒有正確答案。
這一部給的最實用的一條不是工具，是提問能力：最重要的技能是能自在地說出「我不會做這個，請幫忙」，並且把問題問對。
第二部：設計
先看別人做的。 想知道什麼可以被視覺化、可以怎麼做，得先看過前人的東西。他們的固定靈感來源包括紐約時報的互動作品與 The Upshot、華盛頓郵報、衛報、r/dataisbeautiful，以及 Information Is Beautiful Awards 的檔案庫。
把喜歡的東西存起來。 作者的作法是一份長期開著的 Google 文件：截圖、加一段註記寫下自己喜歡它哪裡、附原始連結。這個作法的結構與 commonplace book 完全一樣——摘錄、標註為什麼值得留、可以找回來。差別只在存的是視覺而不是文字。
先想訊息，再選圖表。 動手之前先問要傳達的重點是什麼：一個變數隨時間成長？兩個量之間的落差？某個值的變異程度？還是地理上的分布？確定了要讀者理解什麼，才去挑哪一種圖表最能表達。
不要在程式裡做設計。 這是這一部最可移植的一條。少數人可以在餐巾紙上畫幾筆就直接寫程式邊寫邊設計，但對多數人來說，在 JavaScript 裡即興設計會變成陷在 bug 與語法裡、掉進 StackOverflow 的兔子洞，而不是在設計視覺。
他們的替代作法是用簡單工具先把靜態版本畫出來。Matt 多年來用 Keynote 畫圖表草稿，作者被他說服後也改用；團隊後來也開始用 Figma。理由是 Keynote 內建的形狀、遮罩、漸層就足以做出資料驅動的圖表，學習曲線又比 Illustrator 低得多。
這一條與醜草圖的低完成度主張方向相同但目的不同：Eppler 要低完成度是為了邀請別人動手，這裡要低完成度是為了讓自己能快速判斷這張圖到底有沒有把話說清楚。與圖像思考的「繪圖本身就是思考的過程」則完全同向。
設計對專業的人也是苦工。 這一部結尾舉了三個例子：《科學美國人》Jen Christiansen 團隊為懷孕階段圖做的大量草稿、Matt 為新聞編輯室多樣性專案從白板一路做出九種設計變體、以及 Mike Bostock 的多次迭代。原文的說法是如果那種等級的人都要試一百種方法看哪個成立，其他人就別想省。
第三部：敘事
作者自陳這一部卡了很久，原因是他一直把它想成「寫作」。想通的那一刻是發現只談寫作而不談敘事結構，對讀者根本沒有幫助。前兩部處理技術的 how，這一部處理的是敘事的 why。
第一問：讀者是誰。 為自己做的專案容許最大的創作自由與風險，作者自己第一批作品之一就是出於好奇而做，他明說不想做一個編輯會想要的東西。為別人做則帶來限制，而限制經常讓成品更好——它逼你砍掉那些原本會糾結的枝節。原文引同事的話是「ship it」，並主張採取「先做出最小可行版本，其他之後再說」的敘事觀。為別人寫還有第三個好處：替他人組織資訊，會逼出比自己記筆記時更清楚的表達。
第二問：範圍是寬還是窄。 寬是先有一批本身就有趣的資料，探索著看能長出什麼；風險是把海煮乾之後發現裡面沒東西，而如果連自己都沒被勾起好奇心，讀者更不會。窄是先有一個核心問題，再去找資料回答它——這是他們常用的路。判準寫得很具體：一個讓你興奮、或能在朋友同事之間引起爭辯的問題，通常就是值得投入的訊號。
第三問：結論有多複雜。 檢驗方法是跟朋友喝酒時被問到最近在忙什麼，你是能三言兩語講清楚，還是得先說一句「這個嘛，有點複雜，不過」。
簡單的結論可以用當頭棒喝的數字開場，把最有意思的發現直接放在最前面。看似會讓後面沒戲唱，實際上相反：先講出龐克樂手票選第一名是 Blink-182，讀者才會對後面的次類型與年齡效應感興趣。
複雜的結論則需要脈絡。作者的參照是《紐約客》的長篇報導——它們都從一個人物開始，因為統計數字在缺乏脈絡時只有個人經驗的一小部分力量。視覺敘事很少寫個人，對應的作法是從單一資料點開始：談再訓練就先談卡車司機，談名人過世後的維基百科聲量就先看碧昂絲。那個點不必貫穿全文，它只是把讀者領進門的裝置。
第四問：論證怎麼推進。 三種結構各有代價：
| 結構 | 作法 | 好處與代價 |
|---|---|---|
| 一點一圖，往下堆疊 | 每段一張圖，讀者往下捲 | 好寫好做，靜態圖也成立，工具不拘；結構直覺 |
| Scrollytelling | 捲動觸發單一圖表的變化 | 體驗流暢，讀者有動力往下；但要同時處理手機與桌機高度、每一步的狀態都要寫死、瀏覽器負擔重、迭代耗時 |
| 點擊分步 | 一步一畫面，可用網頁也可用 Instagram 輪播 | 簡單、結構性強，且因為畫面塞不下太多字而強迫精簡；桌機體驗略遜於手機 |
第五問：你怎麼得到這個結論的。 他們多數作品在結論之後附一段方法說明，交代資料來源與計算方式。理由是讀者夠精明會批判性地看待作品，而對結論有疑慮的人，只要看得到資料哪裡來、數字怎麼算，就會比較願意相信。
對劉亮的用處
「不要在程式裡做設計」對應到簡報是「不要在投影片軟體裡想內容」。 簡報教學的核心教學原則第二條是「先有文字，才有視覺化」，這一部給的是同一條在資料視覺化領域的版本，而且更硬——它連工具都指定了：先用 Keynote 畫，不要先寫程式。這條對那門課的下午場是可以直接講的類比。
三問結構可以搬進課裡。 讀者是誰、範圍寬窄、結論多複雜，這三問與簡報教學三階段框架的「構想」階段重疊，但補上了它沒有的一項：結論複雜度決定開場方式。簡單就當頭棒喝，複雜就從單一具體案例進入。
方法說明那一節是學術寫作的習慣被搬進大眾內容。 碩士論文的認識論防禦處理的是同一件事，差別在一個是為了通過審查，一個是為了讓讀者願意相信。
相關原始筆記
Clippings/Making Internet Things, Part 1 Working with Data.md— 資料，來源https://pudding.cool/process/how-to-make-dope-shit-part-1/Clippings/Making Internet Things, Part 2 Design.md— 設計，同系列第二部Clippings/Making Internet Things, Part 3 Storytelling.md— 敘事，同系列第三部