[{"data":1,"prerenderedAt":604},["ShallowReactive",2],{"sim-monitor-dashboard":3,"work-nav-all":554},{"id":4,"title":5,"body":8,"cover":509,"description":487,"details":510,"extension":531,"headline":532,"meta":535,"navigation":536,"order":25,"path":537,"role":538,"seo":539,"seoTitle":541,"slug":544,"status":545,"stem":544,"summary":546,"tags":549,"year":552,"__hash__":553},"works\u002Fsim-monitor-dashboard.md",{"zh":6,"en":7},"散熱模擬監控儀表板","Thermal Simulation Monitoring Dashboard",{"type":9,"value":10,"toc":486},"minimark",[11,270],[12,13,14,18,22,51,54,60,63,66,82,89,92,95,98,103,125,129,144,149,152,155,158,161,167,170,173,179,182,188,198,201,204,207,221,224,230,237,240,243],"zh",{},[15,16,17],"h2",{"id":17},"異常監控的設計挑戰",[19,20,21],"p",{},"散熱實驗裡的風扇、管路、散熱片等物件，各自帶著多項監控指標，設計的挑戰在於如何組織這些資訊，讓工程師一眼掌握全局。",[23,24,26,35,43],"info-cards",{"cols":25},3,[27,28,32],"info-card",{"icon":29,"title-en":30,"title-zh":31},"material-symbols:warning","Anomaly Triage","定位異常物件",[19,33,34],{},"多個物件同時受監控時，如何讓工程師第一眼發現異常，不必逐一掃描數值。",[27,36,40],{"icon":37,"title-en":38,"title-zh":39},"material-symbols:density-medium","Information Density","資訊密度",[19,41,42],{},"每個物件都有多個指標，如何呈現在同一畫面又不造成認知負荷過大。",[27,44,48],{"icon":45,"title-en":46,"title-zh":47},"material-symbols:swap-horiz","Version Switching","物件版本切換",[19,49,50],{},"處理異常的方式是更換物件的版本再重新實驗，介面要讓工程師看清換了哪個版本、前後差在哪。",[19,52,53],{},"具體的情境是：",[55,56,57],"blockquote",{},[19,58,59],{},"設計一個散熱模擬實驗的儀表板，讓工程師發現異常時能快速定位問題物件、切換版本、重新實驗。",[15,61,62],{"id":62},"資訊架構",[19,64,65],{},"首先整理資料實體之間的關係，並發想資料欄位，作為後續介面設計的基礎。",[67,68,69,73,76,79],"ul",{},[70,71,72],"li",{},"一個實驗（Experiment）底下有多個物件（Object）",[70,74,75],{},"每個物件有多個指標（Metric）與多個版本（Version）",[70,77,78],{},"指標超標會自動產生異常警報（Alert）",[70,80,81],{},"實驗過程的執行狀況另外記錄成執行紀錄（Log）",[83,84],"full-image",{"alt":85,"caption-en":86,"caption-zh":85,"src":87,":lightbox":88},"資料實體關係圖","Entity relationship diagram","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fentity-relationship.webp","false",[15,90,91],{"id":91},"佈局決策",[19,93,94],{},"資訊架構定案後，下一步是把這些實體與欄位呈現在介面上。我採用「便當佈局」的邏輯，越重要的資訊佔越大的面積，並放在最顯眼的位置。",[19,96,97],{},"在散熱實驗模擬的情境下，3D 熱圖自然成為焦點。這個大原則確定後，我評估了幾個方案：",[99,100,102],"h3",{"id":101},"方案-a熱圖關鍵指標物件三個等分區塊","方案 A：熱圖、關鍵指標、物件三個等分區塊",[104,105,108,117],"grid",{"align":106,"cols":107},"center",2,[109,110,111],"cell",{},[83,112],{"alt":113,"caption-en":114,"caption-zh":115,"src":116,":lightbox":88},"方案 A：左側熱圖、中間關鍵指標、右側物件區塊三個等分區塊","Heatmap, key metrics, and object in three equal blocks","熱圖、關鍵指標、物件三個等分區塊","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Flayout-option-a.webp",[109,118,119,122],{},[19,120,121],{},"左側是 3D 熱圖，中間為關鍵指標區塊，右側為物件區塊，三個區塊直接對應資訊架構裡的三個實體，易於理解介面架構。",[19,123,124],{},"但後續設計發現物件區塊資訊量最大，在這個方案內可能產生頻繁切換操作而降低效率，故不採用。",[99,126,128],{"id":127},"方案-b熱圖與關鍵指標合併物件區塊加大最終採用","方案 B：熱圖與關鍵指標合併，物件區塊加大（最終採用）",[104,130,131,139],{"align":106,"cols":107},[109,132,133],{},[83,134],{"alt":135,"caption-en":136,"caption-zh":137,"src":138,":lightbox":88},"方案 B：左側熱圖與關鍵指標合併，右側物件區塊加大，同時顯示列表與詳情","Option B: object block enlarged, showing the object list and detail together","物件區塊加大，有利於物件列表與詳情同時顯示","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Flayout-option-b.webp",[109,140,141],{},[19,142,143],{},"把關鍵指標併入左側熱圖區塊，讓出的空間用來放大物件區塊，同時容納物件列表與詳情，不用再頻繁切換操作，查看效率較高。",[55,145,146],{},[19,147,148],{},"監控介面的關鍵資訊應同時可見，減少切換操作，讓工程師判斷更快。",[15,150,151],{"id":151},"異常呈現",[19,153,154],{},"我定義物件的狀態為三級：正常、警告、嚴重，讓工程師能判斷處理的優先順序。",[19,156,157],{},"物件列表會標出每個物件的異常燈號與異常數量，燈號取該物件內部所有指標中最嚴重的狀態，快速掌握目前有多少物件出狀況；列表也能依欄位排序，快速把異常物件排到頂端。",[19,159,160],{},"點進物件詳情，每項監控數據都用歷時圖搭配閾值線呈現，符合監控場景持續追蹤數據變化的需求，需要細看時可展開放大查看完整圖表。",[83,162],{"alt":163,"caption-en":164,"caption-zh":165,"src":166},"左側為三色狀態燈號圖例（正常／警告／嚴重）與物件列表，以燈號標示三級狀態與異常數量；右側為物件詳情，指標以歷時圖搭配閾值線呈現","Object list and object detail metrics","物件列表與物件詳情指標","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fobject-panel.webp",[15,168,169],{"id":169},"處理異常",[19,171,172],{},"工程師發現異常後，會更換該異常物件的版本再重新實驗，若異常排除則實驗結束，沒排除就繼續回到監控。",[83,174],{"alt":175,"caption-en":176,"caption-zh":177,"src":178},"完整操作流程圖：監控、診斷、版本切換、重跑的完整循環","The full loop: monitor, diagnose, switch version, re-run","監控、診斷、版本切換、重跑的完整循環","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fflowchart.webp",[19,180,181],{},"版本更換的任務交由 Modal 處理，以列表呈現物件的各版本資訊，並標示前次實驗所使用的版本。工程師可選擇要套用的版本進行更換，更換後介面提示需要重新實驗才能取得新版本的結果，亦可回溯查看前次實驗的結果。",[183,184],"video-block",{"caption-en":185,"caption-zh":186,"src":187},"Flow for changing an anomalous object's version","更換異常物件版本的操作流程","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fversion-change-flow.mp4",[19,189,190],{},[191,192,197],"a",{"href":193,"rel":194,"target":196},"https:\u002F\u002Fwww.figma.com\u002Fdesign\u002FyKyKVcdDzVGrTWKFqAl1QL\u002FDesign-Challenge---yode?node-id=0-1",[195],"nofollow","_blank","Figma 設計稿",[15,199,200],{"id":200},"從設計到開發",[19,202,203],{},"設計稿完成後，我延伸開發成一個真的能跑的 Vue 3 原型，作為前端練習，也用來驗證這套設計邏輯的實作可行性。",[19,205,206],{},"實作階段我將重心放在架構規劃與邏輯，程式碼撰寫則透過 AI 輔助加速。架構上分四層：",[67,208,209,212,215,218],{},[70,210,211],{},"元件層：Vue 3 + Element Plus，元件不直接碰資料層",[70,213,214],{},"狀態層：使用 Pinia 狀態管理",[70,216,217],{},"服務層：模擬後端 API",[70,219,220],{},"資料層：預生成的模擬資料",[19,222,223],{},"透過服務層獨立的設計，未來只需抽換該層，即可串接真實後端。",[83,225],{"alt":226,"caption-en":227,"caption-zh":228,"src":229,":lightbox":88},"Vue 3 互動原型畫面","Vue 3 interactive prototype","實驗監控儀表板原型","\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fprototype-screen.webp",[19,231,232],{},[191,233,236],{"href":234,"rel":235,"target":196},"https:\u002F\u002Fyode0419.github.io\u002Fsim-monitor-dashboard\u002F",[195],"查看互動原型（僅桌面版）",[15,238,239],{"id":239},"學習與反思",[19,241,242],{},"做完這次的設計挑戰後，我歸納出一些在「監控場景」（不限於本次的實驗模擬監控）中，應反覆留意的設計要點，作為自我提醒：",[67,244,245,252,258,264],{},[70,246,247,251],{},[248,249,250],"strong",{},"降低認知負荷","：在龐大資訊量下，善用架構與佈局引導視覺，避免畫面擁擠。",[70,253,254,257],{},[248,255,256],{},"縮短決策時間","：將異常判斷所需的關聯資訊整合於同一視角，減少來回切換。",[70,259,260,263],{},[248,261,262],{},"避免誤觸風險","：監控系統的誤操作成本高，需要適當的防呆機制。",[70,265,266,269],{},[248,267,268],{},"思考自動化定位","：這是更深一層的思考，當監控系統自動化程度越高，使用者面臨突發狀況的反應能力可能越弱，需在設計上取得平衡。",[271,272,273,277,280,297,300,305,309,312,326,328,332,335,338,342,357,361,374,379,383,386,389,392,395,399,402,405,408,410,416,420,423,426,440,443,447,453,457,460],"en",{},[15,274,276],{"id":275},"the-design-challenge-of-anomaly-monitoring","The Design Challenge of Anomaly Monitoring",[19,278,279],{},"Objects in the thermal experiment, fans, pipes, heat sinks, each carry multiple monitored metrics. The design challenge was organizing all of that so engineers could grasp the full picture at a glance.",[23,281,282,287,292],{"cols":25},[27,283,284],{"icon":29,"title-en":30,"title-zh":31},[19,285,286],{},"With multiple objects monitored at once, how do you help engineers spot an anomaly at a glance instead of scanning every value one by one.",[27,288,289],{"icon":37,"title-en":38,"title-zh":39},[19,290,291],{},"Each object has several metrics. How do you show them all on one screen without causing cognitive overload.",[27,293,294],{"icon":45,"title-en":46,"title-zh":47},[19,295,296],{},"Handling an anomaly means switching the object's version and re-running the experiment. The interface needs to make clear which version was switched to and what changed.",[19,298,299],{},"The scenario:",[55,301,302],{},[19,303,304],{},"Design a dashboard for a thermal simulation experiment that lets engineers quickly locate the problem object, switch its version, and re-run the experiment when something goes wrong.",[15,306,308],{"id":307},"information-architecture","Information Architecture",[19,310,311],{},"The first step was mapping out the relationships between data entities and sketching the data fields, as the foundation for the interface design that followed.",[67,313,314,317,320,323],{},[70,315,316],{},"An Experiment contains multiple Objects",[70,318,319],{},"Each Object has multiple Metrics and multiple Versions",[70,321,322],{},"When a metric exceeds its threshold, it automatically triggers an Alert",[70,324,325],{},"The experiment's execution status is tracked separately as a Log",[83,327],{"alt":86,"caption-en":86,"caption-zh":85,"src":87,":lightbox":88},[15,329,331],{"id":330},"layout-decisions","Layout Decisions",[19,333,334],{},"Once the information architecture was settled, the next step was putting those entities and fields on screen. I used a bento-box layout logic: the more important the information, the more space it gets and the more prominent its position.",[19,336,337],{},"In a thermal simulation scenario, the 3D heatmap naturally becomes the focal point. With that principle set, I evaluated a few options:",[99,339,341],{"id":340},"option-a-heatmap-key-metrics-and-object-in-three-equal-blocks","Option A: Heatmap, Key Metrics, and Object in Three Equal Blocks",[104,343,344,349],{"align":106,"cols":107},[109,345,346],{},[83,347],{"alt":348,"caption-en":114,"caption-zh":115,"src":116,":lightbox":88},"Option A: heatmap on the left, key metrics in the center, object block on the right, in three equal sections",[109,350,351,354],{},[19,352,353],{},"The 3D heatmap sits on the left, key metrics in the center, and the object block on the right. The three sections map directly to three entities in the information architecture, which made it easy to understand.",[19,355,356],{},"But later design work showed the object block carried the most information. This option risked frequent switching between sections and lower efficiency, so I didn't go with it.",[99,358,360],{"id":359},"option-b-heatmap-and-key-metrics-merged-object-block-enlarged-chosen","Option B: Heatmap and Key Metrics Merged, Object Block Enlarged (chosen)",[104,362,363,369],{"align":106,"cols":107},[109,364,365],{},[83,366],{"alt":367,"caption-en":368,"caption-zh":137,"src":138,":lightbox":88},"Option B: heatmap and key metrics merged on the left, object block enlarged on the right, showing the list and detail together","Object block enlarged, showing the object list and detail together",[109,370,371],{},[19,372,373],{},"Folding key metrics into the heatmap block on the left frees up space to enlarge the object block, which now holds the object list and detail together. No more frequent switching, and it's faster to review.",[55,375,376],{},[19,377,378],{},"A monitoring interface should keep key information visible at the same time, cutting down on switching so engineers can judge faster.",[15,380,382],{"id":381},"anomaly-display","Anomaly Display",[19,384,385],{},"I defined three severity levels for an object's state, normal, warning, and critical, so engineers can judge how urgently to respond.",[19,387,388],{},"The object list flags each object's alert status and alert count. The status light reflects the most severe state among all of that object's metrics, so engineers can see at a glance how many objects are in trouble. The list can also be sorted, bringing anomalous objects to the top quickly.",[19,390,391],{},"Inside an object's detail view, every monitored value is shown as a time-series chart with a threshold line, matching the need to continuously track how the data changes in a monitoring scenario. Engineers can expand the chart for a closer look when needed.",[83,393],{"alt":394,"caption-en":164,"caption-zh":165,"src":166},"On the left, a three-color status legend (normal, warning, critical) and the object list, which flags three-tier status and alert counts with colored lights; on the right, object detail with metrics shown as time-series charts and threshold lines",[15,396,398],{"id":397},"handling-anomalies","Handling Anomalies",[19,400,401],{},"After spotting an anomaly, the engineer switches the object's version and re-runs the experiment. If the anomaly is resolved, the experiment ends, if not, monitoring continues.",[83,403],{"alt":404,"caption-en":176,"caption-zh":177,"src":178},"Full operating flow diagram: the complete loop of monitoring, diagnosing, switching versions, and re-running",[19,406,407],{},"Version switching is handled through a modal, which lists each version's information and marks the version used in the previous run. Engineers can choose which version to apply, and after switching, the interface shows that a new run is needed to get results for the new version. They can also look back at the previous run's results.",[183,409],{"caption-en":185,"caption-zh":186,"src":187},[19,411,412],{},[191,413,415],{"href":193,"rel":414,"target":196},[195],"Figma design file",[15,417,419],{"id":418},"from-design-to-development","From Design to Development",[19,421,422],{},"Once the design was done, I extended it into a working Vue 3 prototype, both as frontend practice and to verify that this design logic could actually be implemented.",[19,424,425],{},"During implementation, I focused on architecture and logic, using AI assistance to speed up the actual coding. The architecture has four layers:",[67,427,428,431,434,437],{},[70,429,430],{},"Component layer: Vue 3 + Element Plus, components never touch the data layer directly",[70,432,433],{},"State layer: managed with Pinia",[70,435,436],{},"Service layer: simulates the backend API",[70,438,439],{},"Data layer: pre-generated mock data",[19,441,442],{},"With the service layer kept independent, connecting to a real backend in the future only requires swapping out that one layer.",[83,444],{"alt":445,"caption-en":446,"caption-zh":228,"src":229,":lightbox":88},"Vue 3 interactive prototype screen","Simulation monitoring dashboard prototype",[19,448,449],{},[191,450,452],{"href":234,"rel":451,"target":196},[195],"View interactive prototype (desktop only)",[15,454,456],{"id":455},"learning-and-reflection","Learning and Reflection",[19,458,459],{},"After finishing this design challenge, I put together a few design points worth revisiting in any monitoring scenario, not just this simulation monitoring case, as reminders for myself:",[67,461,462,468,474,480],{},[70,463,464,467],{},[248,465,466],{},"Reduce cognitive load",": with a large volume of information, use structure and layout to guide the eye and avoid clutter.",[70,469,470,473],{},[248,471,472],{},"Shorten decision time",": keep the information needed to judge an anomaly within one view, cutting down on switching back and forth.",[70,475,476,479],{},[248,477,478],{},"Prevent accidental actions",": mishandling a monitoring system is costly, so it needs the right safeguards.",[70,481,482,485],{},[248,483,484],{},"Consider where automation should sit",": a deeper question. The more automated a monitoring system gets, the weaker a user's response to unexpected situations can become, and design needs to balance the two.",{"title":487,"searchDepth":107,"depth":107,"links":488},"",[489,490,491,495,496,497,498,499,500,501,505,506,507,508],{"id":17,"depth":107,"text":17},{"id":62,"depth":107,"text":62},{"id":91,"depth":107,"text":91,"children":492},[493,494],{"id":101,"depth":25,"text":102},{"id":127,"depth":25,"text":128},{"id":151,"depth":107,"text":151},{"id":169,"depth":107,"text":169},{"id":200,"depth":107,"text":200},{"id":239,"depth":107,"text":239},{"id":275,"depth":107,"text":276},{"id":307,"depth":107,"text":308},{"id":330,"depth":107,"text":331,"children":502},[503,504],{"id":340,"depth":25,"text":341},{"id":359,"depth":25,"text":360},{"id":381,"depth":107,"text":382},{"id":397,"depth":107,"text":398},{"id":418,"depth":107,"text":419},{"id":455,"depth":107,"text":456},"\u002Fimages\u002Fworks\u002Fsim-monitor-dashboard\u002Fcover.webp",[511,518,525],{"label":512,"value":515},{"zh":513,"en":514},"角色","Role",{"zh":516,"en":517},"設計師 + 前端開發（獨立完成）","Designer + Frontend Developer (Independent)",{"label":519,"value":522},{"zh":520,"en":521},"用時","Duration",{"zh":523,"en":524},"設計與開發共一週完成","Design and development completed in one week",{"label":526,"value":529},{"zh":527,"en":528},"工具","Tools",{"zh":530,"en":530},"Figma · Vue 3 · TypeScript · Pinia · Element Plus · Claude Code · Codex","md",{"zh":533,"en":534},"整理龐雜的監控實驗模擬數據，讓工程師一眼看出異常，並快速處理","Organizing dense monitoring data from simulation experiments so engineers can spot anomalies at a glance and act on them fast",{},true,"\u002Fsim-monitor-dashboard",{"zh":516,"en":517},{"title":540,"description":487},{"zh":6,"en":7},{"zh":542,"en":543},"散熱模擬監控儀表板 - 監控介面的設計決策與反思","Thermal Simulation Monitoring Dashboard: Design Decisions for Industrial Monitoring UI","sim-monitor-dashboard","published",{"zh":547,"en":548},"這是一個自訂的設計挑戰，針對散熱模擬工程師的實驗監控儀錶板，我以一週時間完成資訊架構整理、佈局決策、User Flow、以及 Wireframe，並延伸實作為 Vue 3 互動原型。","A self-directed design challenge for thermal simulation engineers. Over one week I worked through the information architecture, layout decisions, user flow, and wireframes, then extended it into a Vue 3 interactive prototype.",[550,308,551],"Design Challenge","Dev",2026,"cphvRSgxoZz5fxXLazNtpCGvwqxnosM1KKtwswXAjX4",[555,566,574,577,586,594],{"slug":556,"title":557,"cover":559,"tags":560,"order":565},"morph-inspect",{"zh":558,"en":558},"Morph Inspect","\u002Fimages\u002Fworks\u002Fmorph-inspect\u002Fcover.webp",[561,562,563,564],"AI","B2B","Mobile","Web",1,{"slug":567,"title":568,"cover":570,"tags":571,"order":107},"spin-the-wheel",{"zh":569,"en":569},"Spin The Wheel","\u002Fimages\u002Fworks\u002Fspin-the-wheel\u002Fcover.webp",[572,573,551],"Wearable","Connect IQ",{"slug":544,"title":575,"cover":509,"tags":576,"order":25},{"zh":6,"en":7},[550,308,551],{"slug":578,"title":579,"cover":582,"tags":583,"order":585},"tiger-master",{"zh":580,"en":581},"師虎來了(修繕媒合平台)","TigerMaster Repair Matching Platform","\u002Fimages\u002Fworks\u002Ftiger-master\u002Fcover.webp",[584,563,551],"B2C",4,{"slug":587,"title":588,"cover":590,"tags":591,"order":593},"yodewang-rebuild",{"zh":589,"en":589},"yodewang.com","\u002Fimages\u002Fworks\u002Fyodewang-rebuild\u002Fcover.webp",[592,561,551],"Portfolio",5,{"slug":595,"title":596,"cover":599,"tags":600,"order":603},"ai-design-system-assistant",{"zh":597,"en":598},"建立一套讓 AI 看懂設計脈絡的知識庫","Building a Knowledge Base That Teaches AI Design Context","\u002Fimages\u002Fworks\u002Fai-design-system-assistant\u002Fcover.webp",[601,602,561],"[WIP]","Design System",6,1783500312842]