冒著被噓爆的危險借討論串一問, 我大學是工設, 現在是那種孤單設計師啦 雖然原文用醫生律師來類推不太恰當，回文也說了相當多不同的考量，這些大約都能體會 但是想請問各位，關於設計的流程有沒有書可以學習? (書代表的只是一種容易傳播學習的方式， 到職場上學吧被刁就會了...這種方式可能不太好傳播) 看了人月神話和peopleware，感覺軟體相關流程都可以不斷累積經驗， 軟體跟設計已經有點接近了吧，也是從無到有，沒有標準寫法， http://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91 專屬於設計相關流程的模式不知道有沒有? 例如軟體會先做快速原型，當然IDEO好像也是這樣搞， 但不確定這樣有沒有用，應該很少人在做? 快速原型之外的幾種方式，是不是能照搬到設計? 更狹義的我想專指產品外觀，是不是能有幾套類似SOP看情況來應對， 踩個地雷用原文的比喻，假設醫生有流程應對，那所謂流程也是累積得來的吧? 今天我知道病人是什麼樣的症狀，根據我所學原因為何，我如何應對，結果如何， 並且把這樣的經驗讓別人也學會，讓後人知道各種方法優缺點， (雖然就算醫生有有強弱，大門做的處置都比較恰當) 另外更細節一些，有沒有基於某種問題的共識，像程式的命名法，方便維護 http://zh.wikipedia.org/wiki/%E5%B8%95%E6%96%AF%E5%8D%A1%E5%91%BD%E5%90%8D%E6%B3%95 或像 Material design 的SPEC這樣，可以有一致性 http://www.google.com/design/spec/material-design/introduction.html 上述幾種流程或模式等等用詞不太準確，然後講的也不太是同一件事， 不過就是想知道設計相關的知識，是不是可以很多人一起累積並不斷改進的? 有的話我該去哪裡找資料? 深怕別人都在上太空我還在殺豬公，懇請回答，感謝各位 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.184.59.23 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/Design/M.1420739423.A.081.html 感謝這位版友的回覆，可能因為我問題界定的不是很清楚啦， 因為也不知道是不是有這種東西， 我想的流程並不一定干涉設計這個行為本身， 設計的本質，我想人人腦中各有定論吧，都是神聖不可侵犯的一部分， 您所提到的基礎工具，但是不是能更針對如何用好這些工具，做出經驗的傳承 例如遊戲好了，我想知道如何讓團隊寫的更快更好，這是流程 不影響遊戲寫的好玩，這個類似設計本質的東西 ※ 編輯: coord (111.184.59.23), 01/09/2015 02:35:08 感謝overjoker推薦好書，設計的方法這本， 的確蒐集了許多的方法，大約解答了一部分的疑問，有時間會仔細看一下， 不過更貪心的想知道這些方法的優缺點，實務上會在哪碰到挫折XD 至於myaku524您說的大致上沒錯，我也在思考我該怎麼問這個問題， 才能得到我想要的答案，例如底下superpai版友回文，步驟 依序大概是 1. mood board 2. sketch 3. wireframe 4. mockup 5. prototype 抱歉我也是google才懂的...看起來像是UI的流程 但是就是有這個但是 http://zh.wikipedia.org/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B 對於這些流程依序上，軟體界在1970年提出了見解，瀑布式開發的缺點， 就是客戶在5才會改稿，然後就是...X 就算你每個步驟確保品質，都給客戶確認過，他照樣大改 有沒有什麼辦法可以解決這個問題? 分成大方向和小方向看，例如拉我亂舉例，例如喔， 大方向關於流程的解決，假設我將5的改稿列入必定的流程， 也就是每次都是1~5，重複2次， 這樣是不是會更貼近客戶的需求? 自己心情也比較好? 又或是這樣的方法吃力不討好?我希望的是類似這種經驗 小方向就是關於軟體的利用，目前絕大部分設計應該和軟體相關，吧? 是不是我能在軟體相關的方式上做得容易修改， 最顯而易見在網頁，都是去載入一個css，而非將css寫在每一頁， 又或是3D建模的top-down流程，這些例子， 並非會了就成為捷徑我會我超強，而是在一開始決定使用的方法之後， 可以經由前人的累積盡量避免失敗或不爽 當然是希望流程是可以針對設計本質的過程愉快的強化， 如果是整個團隊做，其他部分都有其他領域的人可以完成， 但是不是產品外觀的本質就是在美? 海報的本質在美? 建築的本質在美? 這麼天真的同時，又被要求容易使用，為客戶著想，價格等等...... 設法可以盡量更專注在所認為的本質 ※ 編輯: coord (111.184.59.23), 01/10/2015 00:37:13 是有點偷懶啦，就是想看有沒有人在累積，不想當神農嘗百草阿，我想看本草綱目XD z版友您說的草稿可能發生的缺點同superpai版友，他的草稿分的更細， 單就草稿分很細這點，或許就是一種關於流程的面對方式， 流程的改善跟我想的差不多，但我認為並非列出了公式，就只能呆呆的套用， http://0rz.tw/A0snr 軟體的設計模式，也是著重於普遍存在(反覆出現)的各種問題， 可能也要靈活運用多個模式，一定也有最好的模式就是沒有模式等說法， 我盡量都用"經驗"來代替模式這個詞，因為我覺得這更容易懂， 人類也不會照教科書生病阿XD，抽象經驗適當的歸納讓許多人可以共享， 遇到常見的問題時，不至於不失所措 ※ 編輯: coord (111.184.59.23), 01/10/2015 09:24:49