有了服務項目後，顧客已經可以開始預約，進入這個網站的重頭戲。上一篇文章中，眼尖的朋友們一定會發現，對比原先的 Flow Chart 後，好像少了「顧客預約當下沒有立刻填寫匯款資訊」的情境，這篇就讓我們補上，並將其他頁面的 Wireflame 一起補完吧！

續！預約服務項目之 Wireframe 線稿(顧客視角)

1. 服務項目單一詳細頁

詳 Day09：使用 Wireframe 線稿拼接網站的功能與畫面(三)

2. 開始預約後，一些特殊情境

詳 Day09：使用 Wireframe 線稿拼接網站的功能與畫面(三)

3. 完整的預約流程

詳 Day09：使用 Wireframe 線稿拼接網站的功能與畫面(三)

4. 匯款資訊當下有填寫之情境

基本上就是檢查格式，符合判斷式，則算完成顧客角色的預約流程。

5. 匯款資訊當下不填寫之情境

網站目前的設計是，顧客可以在有留下電話號碼並驗證成功的前提，先暫時性的預約佔位。這種情境是給予顧客便利與彈性的設計，當然下次再填是什麼時候 也沒人知道 ？但至少這樣店家可以在收到這樣的預約資訊時，有真實可以聯絡到對方的一種方式。在這個情境下，有兩個設計要點：

• 顧客在預約表單的最後一步，右下送出按鈕會是 disabled 狀態。算是一種前端防呆，如果填寫匯款區域都是空值，就判斷為 disabled。
• 那顧客如果很確定自己就是下次才要填，當然可以選擇左下的「下次再填」，桌機版 hover 時會有底色，讓顧客知道那是可以點擊的。
• 選擇左下的「下次再填」後，頁面會明確標示預約尚未完成，並再次顯示店家之訂金帳戶資訊。比較值得一提的是在這個情境，系統並不會讓顧客看到店家的聯絡資訊。(因為就是沒有成立)
  

預約紀錄列表(店家視角)

1. 預約紀錄列表頁，皆無資料時

程式會做判斷當店家剛成立、完全沒有開始新增服務項目或服務項目皆未開放預約時，是不會看到預約紀錄維護這個功能選單。但因為預防使用輸入網址連結至此頁之額外狀況，也會在頁面預先判斷，如果基於任何情況完全沒有預約紀錄時，會看到的畫面。

2. 有預約紀錄的列表頁

• 這個列表中，因為資訊都相對重要，所以不採用表格方式呈現，而是像是 list (清單)方式清楚列出每筆內容，也不提供詳細頁面，降低系統複雜性。
• 最上方和服務項目一樣，會有針對預約訂單之付款狀態篩選之功能。
• 針對「待查核」之預約訂單，該項目會比其他狀態訂單多一個編輯按鈕。

其實今天卡在這個畫面很久，滿猶豫狀態該怎麼編輯才會比較直覺？有想法的可以底下留言給我，非常感謝！

網站整體 Wireframe 線稿總結

我是第一次這麼認真繪製各種情境的線稿，很清楚知道可能還有很多情境是沒有考量到的、或者可以再優化的，但因為原先的時程規劃就是希望只撥10天，也就是比賽30天的三分之一的時間在規劃上，適時的設置停損點，我想也是各位軟體工程師開發的日常，如果有寶貴的建議，歡迎底下留言給我唷！我很希望經過這次挑戰，不只是完賽，更可得到客觀的建議。

接下來，就讓我們進到程式碼的世界吧！