在工作幾年後，才發現原來以前從沒認真設計過軟體。
如果我們把需求比喻成戰場上的敵人，而你是要去與其作戰的勇士，我想你應該也會覺得多做一些準備，再去與敵人作戰的勝算會比較大。
準備什麼？
前面的文章有提到，在開始設計、開發軟體之前最重要的是把需求弄清楚並做成文件，這份文件說明了敵人有哪些特性，會用哪些技能，該怎麼克制。
所以要設計什麼？該怎麼設計？
首先，這邊指的設計最少涵蓋兩種面向
策略面向：跟需求方一起討論，或是自己想。
技術面向：跟 IT 的夥伴們一起討論，或是自己想。
你所具備的技能如果只是讀過某一本程式語言的書(教你某個語言的那種)或是看過一些線上的教學影片，那你就像是新訓後菜鳥阿兵哥，還是要透過下部隊後去學習更專業的作戰技巧才真正有作戰能力，新訓階段只是體驗的階段而已。
在有能力設計問題的解決方案之前，你必須要先學會一些東西，把裝備盡可能的湊齊，努力的去理解各個裝備的用途以及使用時機。
以網站來說，主要由三個領域組成
雖然現在職缺上時常將這三個領域分開找人，但想要做出成熟的網頁應用，你不能是只懂其中一個領域，你可以專精其中一個領域，但對另外兩個領域也要有一定程度的了解，且懂越多越好。
在補強裝備、工具的同時，也要開始學習一些簡單的繪圖操作，這讓你能夠把想法簡單的畫出來跟其他人討論，有圖片的輔助對於溝通是很有幫助的，因此繪圖成了設計中很重要的一個環節。
有了一定的裝備以及簡單的繪圖技巧後，你可以開始畫流程圖、物件互動圖甚至是製作 Prototype 來表達解決方案(必須基於文件做設計)，你的方案以現實具體的方式呈現並且被審視過後才實作的關鍵點是，這個動作事實上已經在交付解決方案給使用者，而這時候需求端發現問題需要做修改的話，對開發者而言成本相對於實作後再改是小的多的。
文件、設計圖中的用詞最後都會變成程式的一部分，必須謹慎的使用。
設計通常不會一次就定案，過程中可能需求方也需要確認某些東西才能繼續，這時候你應該要跟需求方有共識，看看哪些設計是可行的，哪些是需要再討論、修改的，針對那些比較確定的部分可以開始寫程式，不需要等整個設計階段完成後才開始寫程式。
整個軟體開發過程就是不停的釐清需求、提出設計、寫程式，過程中當某些特定功能完成時，盡快給需求方看過，以最快的速度交付出一個 MVP，並繼續迭代下一個功能。
整個流程大概會是這個樣子
然而現實是殘酷的，很多時候事情沒辦法照著計畫那樣順利，不過開發者們可以努力把握原則：設計解決方案前要先有文件，開發程式前要先跟需求方確認設計，交付之前要做足夠的測試。
雖說這是軟體的開發流程，但只要稍微思考就能發現，文件化是在確認流程，所以如果需求方做不出流程，代表他們本來就無法解決問題；設計是為了確認接下來要做的東西符合期待，如果這一步無法確定，那之後做出來的東西不適用的風險也就很大；交付前的測試做得越好，使用者遇到的 Bug 就越少。
雖說軟體一定會有 Bug，但成熟的軟體要有能力在交付前解決已知的 Bug，而不是上線後讓用戶 Debug。
關於繪圖工具，這邊推薦幾個給大家
這幾款工具各有各的優缺點， YouTube 也已經有很多不錯的教學影片。
iThome鐵人賽
看影片追技術