如何真心合作

TonyQ

前傳

前端 vs 設計

NO

前端 + 設計

VS

客戶

困境

客戶不知道他想要什麼

企劃以為他知道

於是傳達給 VD 

字體要好看

重點要凸顯

相關功能要明確

但是

使用者需要的功能

就像衣櫃缺少的那件衣服

加需求就對了

前端＋視覺：

前端：

教練，我也想當個好人

重點在

需求

還有

Web

WEB 有極限

需求則無

...

...

正片開始

情境一

業務承接商品展示系統

客戶希望有"古典風"

視覺：.......

那是什麼？可以吃嗎？

商品有哪些資料？

供應商？產地？材質？

分類？價格？

哪些是 重要資訊

只有客戶知道

巧婦難為無米之炊

視覺困境

看到圖，才能開始談需求

客戶：這個樣板我不喜歡

可不可以換一個？

（迴圈中）

素材的供給與瞭解被忽略

視覺困境

加欄位、加操作

有限畫面空間

呈現無限資訊

青春可以留白

網頁似乎很難留白

頁面太多資訊

無法凸顯 重要資訊

只好不斷小調整

調整

改需求

最後一版-V3.jpg

最後一版-打死不改.jpg

最後一版-打死不改v2.jpg

客戶：這不是我們要的

客戶：

這跟當初說好的不一樣

這跟開大決有啥兩樣

而且除了視覺以外

團隊的每個人

包括掃地阿婆

路過都可能來給你UI意見

情境 2

設計師終於出了圖

客戶勉強同意了

前端切版

字體不支援

後端說資料取不到

流程不順

網站好慢

facebook 說元件畫面不准改

新細明體：你已經死了。

那些 Mock 沒有告訴你的事

改需求....

設計：

前端：

教練，我想當個好人

前傳結束

在進入正文之前

先釐清工作流程

一般接案公司

跟客戶談需求 => 出圖確認 

=> 切版、套版、實作後端

=> 上線

網路公司

企劃開需求 => 視覺出圖 

=> 切版、後端實作、套版

 => 上線

釐清權責問題

開需求？

需求訪談、需求分析？

SA ？SD？ PM ？ 企劃？

不同公司定義

可能完全不一樣

你的 PM 可能是我的 SA

你的 SA 可能是我們的 RD

視覺設計師

有些公司不用切版

有些公司要切版

有些公司要套版

名詞導向容易造成誤會

今天我們用職務導向

小型專案生命週期

（常識上的）

瞭解 USER

初步分析、瞭解規格

決定規格

設計畫面

前端頁面設計

後端資料流與 server 設計

切版 => 套版 

上線前試用

上線

事實上的困境

客戶很有可能

不認同分析的需求

資料分析錯誤

而導致出圖重作

等設計師出圖

才能讓客戶點頭

後端跟切版都在等

切版跟套版時

才發現前後端理解的

像是不同專案

發現瀏覽器的極限

上線前一個月

需求不斷改變

老闆在你背後   他非常火

老闆/客戶無法理解

需求一日改三回

得意的說需求很明確

我很清楚

知道我要什麼啊

只是一些小修改

其實他只知道

什麼是他不要的

最後

砍功能、快上線

(不) 再給你錢，趕快作

問題之所以是問題

就是因為它可能無法解決

（廢話）

正文預告

接下來的主要是要告訴你

以下這幾件事

需求管理

擁抱變化

互相配合傳接球

休息一下

開發者跟設計師

如何真心合作

要瞭解大家重視的事情

企劃或客戶要的

一個被市場接受的產品

市場很模糊

所以會有摸索

這是他們的天性

接受它

付錢的是老大

需求分析師要的

能變動的規格

需求分析：

在有限的時間內，

取得龐複且大略的規格

雖然要變更

但是是有脈絡可循的變更

不是會轉彎的白海豚

設計師要的

主題、素材、支援

在有限的資訊內

想像出一個虛擬世界

如果在孔子時代

出現電話？

世界觀崩毀

每個環節之間都有連貫性

不只是一個按鈕、不只是一個連結

對視覺而言，

動態效果相對難以實現。 

jQuery？

Html？
grid layout？
animation？
data？

呈現出畫出的世界觀

切版要的

四方形的世界

不規則形狀

必須要能以方形詮釋

操作狀態

點擊、放開、連結

不想挑戰瀏覽器極限

明確或可決定的過場效果

後端要的

明確的資料流

盡可能的高效能

資料盡可能的少一點

客戶要的

On-time

信心

覺得爽

How to Co-work ?

沒有最佳解

所以先解決能解決的

資料先行

畫面上有許多資料

網頁決定如何取用資料

框架圖 優先

兩個重點

決定畫面元素（資料）

資料重要程度

User Experience Designer (UED) 

前端

後端

視覺設計

Protypting 四不

不要花太多時間

不要先估時程

不要講究畫面

不要認為這是作白工

Prototyping 後

好好讀框架圖的資訊

好處！

客戶的心理

一開始怎麼看

都不會太滿意

改個十次以後發現

好像改來改去沒啥差

就不想改了。

框架圖讓客戶

快速經歷改變多次的流程

營造出擁抱改變的氛圍

"框架圖階段可以儘管改"

框架圖結束後

大家對系統都有概念

畫面可能可能會變

資料欄位則不常變動

前、後端跟設計不相依

前端可以試作 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 不是圖

跟圖有落差

是很正常的。

後端應該準備資料

但套版建議給前端

跑迴圈、帶變數

玄機很多的

還有

跟客戶要彼此互相信任

換言之

慎選客戶

不懂尊重自己需求的客戶

認為花錢

就能要什麼有什麼的客戶

你怎麼作都沒有好下場的

讓有影響力（紅）的人

去講對的話

永遠記得

on-time 是你的武器

「加需求就延期」

十次有九次

能把需求擋下來

最後一個點

先作重要的功能

而不是"所有的"功能

因為專案到了死線

什麼事情都有可能會發生

summary 

需求管理

擁抱變化

互相配合傳接球

以上見解純主觀

感謝大家

https://www.youtube.com/watch?v=tPF3pxe6XOg