（網站) 前端與設計
如何真心合作
TonyQ
前傳
前端 vs 設計
NO
前端 + 設計
VS
客戶
困境
客戶不知道他想要什麼
企劃以為他知道
於是傳達給 VD
字體要好看
重點要凸顯
相關功能要明確
但是
使用者需要的功能
就像衣櫃缺少的那件衣服
加需求就對了
糟了沒時間
（時間就是金錢）
前端＋視覺：
前端：
教練，我也想當個好人
視覺：
對不起，你是個好人
重點在
需求
還有
Web
WEB 有極限
需求則無
...
...
正片開始
情境一
業務承接商品展示系統
客戶希望有"古典風"
視覺：.......
那是什麼？可以吃嗎？
商品有哪些資料？
供應商？產地？材質？
分類？價格？
哪些是 重要資訊
只有客戶知道
巧婦難為無米之炊
視覺困境
看到圖，才能開始談需求
客戶：這個樣板我不喜歡
可不可以換一個？
（迴圈中）
素材的供給與瞭解被忽略
視覺困境
加欄位、加操作
有限畫面空間
呈現無限資訊
青春可以留白
網頁似乎很難留白
頁面太多資訊
無法凸顯 重要資訊
只好不斷小調整
調整
改需求
最後一版-V3.jpg
最後一版-打死不改.jpg
最後一版-打死不改v2.jpg
(設計師日記：這次一定是最後一版了！......淚)
客戶：這不是我們要的
客戶：
這跟當初說好的不一樣
這跟開大決有啥兩樣
而且除了視覺以外
團隊的每個人
包括掃地阿婆
路過都可能來給你UI意見
情境 2
設計師終於出了圖
客戶勉強同意了
前端切版
字體不支援
（還好現在有中文 web font ）
後端說資料取不到
流程不順
網站好慢
facebook 說元件畫面不准改
新細明體：你已經死了。
那些 Mock 沒有告訴你的事
改需求....
設計：
前端：
教練，我想當個好人
前傳結束
在進入正文之前
先釐清工作流程
一般接案公司
跟客戶談需求 => 出圖確認
=> 切版、套版、實作後端
=> 上線
網路公司
企劃開需求 => 視覺出圖
=> 切版、後端實作、套版
=> 上線
釐清權責問題
開需求？
需求訪談、需求分析？
SA ？SD？ PM ？ 企劃？
不同公司定義
可能完全不一樣
你的 PM 可能是我的 SA
你的 SA 可能是我們的 RD
視覺設計師
有些公司不用切版
有些公司要切版
有些公司要套版
名詞導向容易造成誤會
今天我們用職務導向
小型專案生命週期
（常識上的）
瞭解 USER
初步分析、瞭解規格
決定規格
設計畫面
前端頁面設計
後端資料流與 server 設計
切版 => 套版
上線前試用
上線
事實上的困境
客戶很有可能
不認同分析的需求
資料分析錯誤
而導致出圖重作
等設計師出圖
才能讓客戶點頭
後端跟切版都在等
切版跟套版時
才發現前後端理解的
像是不同專案
發現瀏覽器的極限
上線前一個月
需求不斷改變
老闆在你背後 他非常火
老闆/客戶無法理解
出錢、出時間、出人，怎麼結果一團亂
需求一日改三回
得意的說需求很明確
我很清楚
知道我要什麼啊
只是一些小修改
要大家配合
其實他只知道
什麼是他不要的
最後
砍功能、快上線
Good End
(不) 再給你錢，趕快作
Bad End
問題之所以是問題
就是因為它可能無法解決
（廢話）
正文預告
接下來的主要是要告訴你
以下這幾件事
需求管理
擁抱變化
互相配合傳接球
休息一下
開發者跟設計師
如何真心合作
要瞭解大家重視的事情
企劃或客戶要的
一個被市場接受的產品
市場很模糊
所以會有摸索
這是他們的天性
接受它
付錢的是老大
需求分析師要的
能變動的規格
需求分析：
在有限的時間內，
取得龐複且大略的規格
雖然要變更
但是是有脈絡可循的變更
不是會轉彎的白海豚
設計師要的
主題、素材、支援
在有限的資訊內
想像出一個虛擬世界
如果在孔子時代
出現電話？
世界觀崩毀
每個環節之間都有連貫性
不只是一個按鈕、不只是一個連結
對視覺而言，
動態效果相對難以實現。
jQuery？
Html？
grid layout？
animation？
data？
呈現出畫出的世界觀
切版要的
四方形的世界
不規則形狀
必須要能以方形詮釋
操作狀態
點擊、放開、連結
不想挑戰瀏覽器極限
明確或可決定的過場效果
後端要的
明確的資料流
盡可能的高效能
資料盡可能的少一點
客戶要的
On-time
信心
覺得爽
How to Co-work ?
沒有最佳解
所以先解決能解決的
資料先行
畫面上有許多資料
網頁決定如何取用資料
框架圖 優先
(Prototyping first)
兩個重點
決定畫面元素（資料）
還有頁面跳轉流程
資料重要程度
User Experience Designer (UED)
前端
知道有多少頁面、哪些元素，
可以先作 prototyping。
後端
知道有多少頁面、哪些元素，
可以先開 DB 資料表、寫後端程式。
視覺設計
可以有更充足的素材與資訊
Protypting 四不
不要花太多時間
不要先估時程
（多一個資料欄位很可能就多一週）
不要講究畫面
框架圖做得再漂亮還是框架圖
重點在"凸顯"重要的資訊
不要認為這是作白工
改這張圖沒人會心痛，
但換成實際視覺設計畫出來的圖，
讓你改來改去就準備被翻桌。
但換成實際視覺設計畫出來的圖，
讓你改來改去就準備被翻桌。
Prototyping 後
好好讀框架圖的資訊
工程師A：「我也是看了報紙才知道」
好處！
客戶的心理
一開始怎麼看
都不會太滿意
改個十次以後發現
好像改來改去沒啥差
就不想改了。
框架圖讓客戶
快速經歷改變多次的流程
營造出擁抱改變的氛圍
"框架圖階段可以儘管改"
框架圖結束後
大家對系統都有概念
畫面可能可能會變
資料欄位則不常變動
前、後端跟設計不相依
前端可以試作 html/css/js
後端可以去寫 data query
視覺慢慢出圖
老闆有（相對）準確時程
最重要的
避免無理取鬧。
框架圖明確的
呈現出欄位資訊
無關美感、只有資料
許多新的資料需求
原本都被藏在"美感"底下
所以加新的資料欄位
絕對是客戶的問題
不是「設計沒考慮到」
或是「這還需要說嗎？」
重點
修改視覺已經出的圖
是修改 prototyping 的一百倍
prototyping
治百病
但是
還是可能會改
總是會有錯誤
沒有即時發現
( 那些 mockup 沒告訴你的事)
還是可能會改
減法哲學
以減少需求為修改方針
其他溝通問題
權責要清楚
每件事情要有主要決策者
"討論' 對象不宜超過四人
UI 意見要在明確場合
用明確方式提出改善
權責清楚後
要彼此合作
前端檢查視覺資料
視覺覆核切版結果
後端 api 前端可以幫忙檢查
彼此跨過一點去幫忙驗證
問題：後端寫好 web api
但前端根本不知道怎麼用
佈版有佈版用的 SQL 等
過版的人不知道
收尾的人倒楣
其他溝通問題 part II
別人網站的效果
有時候這站是作不出來的
像 ie only 對上跨瀏覽器支援
像 google 以圖找圖
更多的是效能問題
有時視覺會覺得前端裝死
其實多少都是有理由的
不明確的說明
不確定的時程壓力
前端覺得視覺是故意整人
table design
不規則畫面
字太長就破版
視覺思考的多是靜態世界
有時甚至是平面世界
css/html 有他的複雜度
各自提出自己困境
留下"必要的'
去除'追求完美'的
前端產業還不夠成熟
人力資源參差不齊
別要求太高
但
這不是不學習的理由
評估團隊幾個方針
視覺應該漸漸學會
Web Friendly Design
前端應該多溝通
設計對動線的想法
pixel perfect
視覺有到 1px 的畫面精度
前端應自我要求0px 誤差
新手就多請視覺 review
但
永遠記得 web 不是圖
跟圖有落差
是很正常的。
後端應該準備資料
但套版建議給前端
跑迴圈、帶變數
玄機很多的
JS 、 css ...etc
還有
跟客戶要彼此互相信任
換言之
慎選客戶
不懂尊重自己需求的客戶
認為花錢
就能要什麼有什麼的客戶
你怎麼作都沒有好下場的
讓有影響力（紅）的人
去講對的話
永遠記得
on-time 是你的武器
「加需求就延期」
十次有九次
能把需求擋下來
最後一個點
先作重要的功能
而不是"所有的"功能
因為專案到了死線
什麼事情都有可能會發生
summary
需求管理
擁抱變化
互相配合傳接球
以上見解純主觀
歡迎踢館、自由發揮！
自己要有思考的精神！