談戀愛的時候，愛一個人，你可以找 100 個理由說愛他/她；討厭一個人，只要 1 個理由就夠了。
你所設計產品或服務，如果有人想用、會用，乃至於愛用，那麼用戶可以告訴你 100 個理由；但要厭棄你的產品或服務，只需有 1 個缺點超過用戶可忍受的臨界，就‧成‧了。
兩條路：
一、幫用戶找 100 個愛上你的理由；
二、避開那 1 個讓用戶離開你的原因。
一個擅攻擊，一個擅防守，沒有好壞對錯，就看你和團隊怎麼搭配。別忘了回頭看看你的設計策略，是不是整個設計方向偏離軌道：該搞那個 1 的時候卻花時間找那 100；該衝 100 的時候卻築牆堵那個 1。
「知先行後」是常態，尤其是越複雜、越不瞭解的主題，越需要在行動前瞭解狀況。
但企業往往以沒有足夠的資源 (時間、金錢和人力) 為由，在不甚瞭解時就開始採取行動，有時候會「賓果」「正中紅心」，更多時候卻是「白費功夫」「打水漂」。即便如此，也要能做到「行先知後」，不要只行動而忽略檢討行動的成敗。
如果當下的限制條件更多，採用「邊知邊行」也是一種方法，知與行頻繁地對焦，確保方向趨近一致。
如果是限制條件多，參與方也多，那麼採取「行先知輔」(臺北體育館品牌空間再設計案的經驗) 也是可以的。
實務上總歸一句話：「知行合一」是我們追求的最高境界，若力有未逮，「知先行後」、「行先知後」或「行先知輔」都是可行的，保持彈性向前行。
你相信在英國，「女人需談 7 次戀愛才能結婚。要親吻過 15 個男人，有過 2 段穩定的感情，心碎過 2 次才能找到真愛。一生中有 4 次一夜情、7 個性伴侶」嗎？有多少時候我們查也不查，看了標題就「分享」，並「相信」這些沒有根據、樣本偏差、或分析方法大有問題的「研究報告」，殊不知讀了不但無益，反而有害….
昨天才說我不是電動咖，今天我又必須說我不是小提琴咖。 但…
《Payback，創新怎麼兌現？》Overview Many comp…
學習描述披薩本體，不需要額外專業知識就能理解，很適合當作第一個練習題。
我先用 Markdown 和 JSON 的描述性語言讓你看見這個結構，之後再繼續擴展 OWL 和 Python 程式碼。
比賽結束那晚，我回到家，放下電腦，打開 Spotify。 耳機戴上去的…