Labs 2.0 Web Redesign
專案：Labs 2.0 Web Redesign
實作時間：2016/03 ~ 2016/12
網站：https://labs.mediatek.com/
網站簡介：MediaTek Labs 聯發科技創意實驗室是一個物聯網 (IoT) 開發者計劃，專為協助您實現將 IoT 構想轉化成商業產品。在此，您可以找到聯發科技提供的各種工具資源，可穿戴式與物聯網晶片以及 HDK 用以打造您的產品雛形。除了參考資料及個開發平台的教學文件之外，您還可以透過向聯發科技的合作廠商提出商業諮詢與合作，在產品商業化的過程得到更有效的協助。要不要寫這個專案的心得文讓我猶豫了好一陣子。
猶豫的原因有幾點：
- 這個專案我並沒有百分之百的主導權。跟以往的專案相比，這個專案更需要滿足客戶需求，而客戶並不單指 end-user，還包含與我們合作的公司內部其他團隊，有點內部接案的感覺。
- 這個專案並沒有用到太先進的技術。我們採用 Bootstrap 3 的 framework 來實作，加上 Labs 2.0 偏向企業產品目錄與入口導向的網站，與 console 類型的網站相比互動成分較少，對設計師來說比較沒有挑戰性，挑戰主要在如何有效溝通、團隊合作與重整內容結構上。
但上次參加設計活動被問到：
『原來你們公司有在做設計啊？有落地嗎？有需要做出來嗎？』
讓我覺得內心受挫…。恩，的確，公司對外的公開網站大多是用外包的方式來執行，但這次 Labs 2.0 從後端、前端到設計都由內部團隊一起完成。希望跟大家分享我們在硬體公司實踐與推廣設計的過程。最後，也為了給 2016 年一個完美的結束，我決定紀錄一下這個專案的心路歷程。
Redesign 前，先發現與檢討問題
首先，先觀察既有的網站有哪些改善的空間。除了觀察之外，也訪問網站的活躍用戶，從使用者的角度來反覆驗證自己的觀察點是不是問題的所在。
我們列出幾個想改善的重點：
問題一：版面不一致、不支援 RWD 響應式網站設計
首頁版面是滿版的設計，但進到網站內部後，版面是固定寬度為 960px 的呈現，而且不支持 RWD 響應式網站設計。
這是外包的缺點之一，不論要做什麼修正，溝通和費用都是成本。直接加上新功能不改動到既有的架構是最快速也最省錢的方式，但當功能不斷疊加卻缺乏全盤的規劃時，網站容易變得四不像。
問題二：相同功能的元件重複顯示卻不一致
例如上方 main-navigation bar 與左方的 navigation bar 功能與層級是完全相同的，但左方的 navigation bar 有加上三角形 icon 提醒使用者還有下一層級，上方的 main-navigation bar 並沒有。另外，相同功能的元件是否需要重複顯示也是討論的重點之一。
問題三：複雜的 hierarchy 結構
網站整體的 hierarchy 很複雜，使用者很難記憶上次瀏覽的東西在哪一層。複雜的原因除了網站內容的 IA 沒有整理好，使用者難以吸收資訊外，
顯示不同層級的顏色沒有相關性（如上圖右，綠色展開後的 menu 為藍色，藍色展開後為粉紅色）使用者心中難以建立整個網站架構的心智模型。
問題四：Readability 易讀性
許多開發者表示在技術文件上使用官方字體 RionaSans 不太習慣。大部份的技術文件都是使用無襯線字體，例如：Helvetica neue、Open Sans 等等，但相較之下，RionaSans 的裝飾性稍微強烈一點，例如在小寫 L 會有翹腳的表現。另外就是，在 web 上使用 RionaSans 字體會有偏高的問題，這些都讓我們重新思考字體的使用。
這四個問題點變成我們 redesign 首要改進的方向。
設計網站不難，難的是讓大家有共識
這個專案帶給我最大的體悟，設計與實作不難，難的是：
- 讓不同的 team 有共識
每個 team 著重的點不同，有人著重在 marketing 有人著重在 developer 本身的需求。 - 讓每個獨立的產品有交集，找出共同點
大公司裡同系列的產品並不一定由同一個 team 完成，瞭解差異性、找出共通點，才能規劃具有彈性的模組可以重複利用。
而達成共識的第一步從 sitemap 開始，也就是整個網站的 IA (Information architecture)。之前參加 HPX88 蘇州 UF2016 心得分享會 ，Richard 提到有些企業中有資訊架構師的職位，針對使用者需求歸納、整理出所需的文件。在這一專案中，我們也扮演著這樣的角色，第一步就是先確立整個網站的架構，再來則是重整每一頁要帶給使用者的資訊。
一開始除了 sitemap 外，我也同步畫了低擬真的 UI flow，除了幫助大家將想像具象化之外，也協助歸納出有幾個可以重複利用的模組進行開發。但事情並不是那麼順利，當 sitemap 不斷的修正，其實沒有那麼多的時間好好畫 UI flow，最後決定先專心在 sitemap 上，先確定整個網站的架構。
是的，不知不覺 sitemap 就來到版本 11 了(´ཀ`)，可以發現版本 1 與版本 11 除了內容不同外，表現手法上也有蠻大的差異，統整一下歷經 11 個版本的 sitemap 洗禮的心得：
- 非設計師的人，對於橫向的 sitemap 理解度更高
sitemap v.11 中，我把 main-navigation bar 上的項目拉出來用橫向排列做說明，更容易與實際產出的頁面做聯想，清楚知道每個項目的下拉選單有哪些子項目，也比較好安排線條的動線。 - 哪一些是獨立頁面，哪些是頁面中的 content ，用符號分開說明清楚
我的習慣是將獨立頁面用框框標示，content 用純文字表示。至於 sitemap 要不要列出內容見仁見智，但對於看到頁面名稱無法第一時間聯想到內容的頁面，我會列出預計放入的內容作為參考。 - 重複的頁面或是有從屬關係的頁面可以用線條連結做說明
線條最好跟主幹使用不同顏色做區分。另外，如果有使用第三方服務的頁面框框也使用不同顏色做區分。 - 清楚說明不同顏色、符號、線條的意義
除了文字說明外，建議帶開發團隊一起看過。
以上這幾點都有助於團隊理解我畫的 sitemap。然而，制定了 sitemap 後不代表在開發的過程中不會有改動，但至少在一開始可以聚焦大家的共識，也可以讓開發人員了解整個專案的 scope ，所以這個過程是絕對不可少的。
而歷經這麼多版本的主要原因是光是 main-navigation bar 上要放什麼 item 就討論了好一段時間，每個人都想將自己覺得重要的東西放在最重要最顯目的位置。其實 main-navigation bar 要放多少 item 並沒有規範，有人建議是 7+-2 個，順序的話則是可以參考 serial position effect 原則來做排序。
以這個專案的內容量和考慮到 RWD 的表現，我認為 main-navigation bar 上的 item 最多不要超過五個會是最佳的顯示。為了解決 main-navigation bar 上要放什麼 item 以及排序的問題，我們先用 Google Analytics 查看在 Labs1.0 中 navigation bar 各個 item 點擊率，利用 data 來瞭解使用者使用的 priority 後，接著將類似的項目整理、歸納成群組，將項目縮減至六個。
首頁可想而知也是兵家必爭之地，每一次的開會我們都會利用 wireframe 或任何圖像化的文件來進行討論，討論哪些內容要放在首頁，順序又是如何。
關於設計這件小事
剛剛提到『難的是讓大家有共識』，現在來談談關於設計這件小事。由於 MediaTek Labs 是 MediaTek 其中一項服務，所以大方向要遵循 MediaTek 的 guideline，例如顏色和字體。
Color palette
官方有定義五個主色、五個副色以及字體使用的顏色。我們定義 Labs 2.0 網站的主色是橘色，其次是綠色，用於網站主要控制元件 ; 並將輔色用於產品背景圖、快捷鍵、表格等等次要元件上，不搶走主要控制元件的風頭以及不造成視覺上的負擔。網站的背景色一律使用白色和兩種淺灰色互相搭配，在一頁滾動式的瀏覽中可以感覺到不同區塊、不同段落的轉換，但不會感受到不同區塊被明顯的劃分，提升瀏覽的體驗。
Typography
一開始提到官方字體 RionaSans 並不適合用在技術類文件，因此我們調整在廣告文宣、段落 title 、 UI 控件都使用官方字體 RionaSans，讓整體風格與 MediaTek 風格一致 ; 內文則使用其他字體，以確保有良好的易讀性。
Card-style Design
卡片式設計可以讓網站看起來更有重點，針對不同螢幕尺寸也可以有好的響應式顯示。謹慎地規範卡片上的操作行為，讓使用者可以在卡片上找到關鍵的操作，不被太多的元素分心。
其他沒有定義到的部分，就看專案需求來定義，衍生出需要的元件，進而建立起專案的 guideline。就像前端制定 css style sheet 一樣，設計可以在 sketch 裡建置 symbol，以確保整體網站設計的一致性和增加工作效率。
經過這次專案，我找到了下一次 design guideline 可以加強的部分，就是更清楚的定義 space，有興趣可以參考這一篇文章。雖然設計時是按照自己規範好的 space 規則做排版，但前端實作出來的結果有些 space 就是跟設計師預期的不同。而在專案實作中，調整 space 的 priority 通常比較低，先處理完其他更重要的 task 再來調整 space，啊，最後好像也不影響專案上線，那就先這樣吧的結束了。
設計師該如何說明 space 規則，讓工程師對整體網站使用的 space 規則更有了解，以減少開發後要調整的次數，是下一次可以加強的部分。
最後，我們解決了哪些問題
我們來看看針對一開始的問題我們是如何解決的。
問題一：版面不一致、不支援 RWD 響應式網站設計
解決安案：版面模組化，重複利用適合的版型，以及利用 guideline 掌握整個網站的一致性。另外，我們使用 Bootstrap 3 的 grid system 來製作 RWD 響應式網站，開發上更為快速外同時也支援 desktop, tablet 和 mobile 。
利用 PageSpeed Insights 的工具來檢測，mobile 也得到不錯的分數，比上一個版本進步了許多。
問題二：相同功能的元件重複顯示卻不一致
解決安案：元件模組化、利用 guideline 掌握整個網站的一致性。
問題三：複雜的 hierarchy 結構
解決安案：重新整理要呈現給使用者的資訊內容，相同資訊用一樣的版面和操作元件呈現。整理內容後重新定義網站結構，讓網站主要操作在三層之內可以完成，減少轉換程序。
問題四：Readability 易讀性
解決安案：內文的部分改用 Roboto 字體。並調整為 1.5 倍行高。
結尾
這個專案讓我再次體驗了網站改版經驗、熟悉 Bootstrap 3 的 gridsystem ，提醒我除了設計之外，還有其他需要培養的軟實力，例如：
- 培養與不同團隊跨國合作的能力
英文很重要。用中文可以完整表達出自己的設計理念，面對客戶的需求時可以提出適合的解決方案，但一當語言切換成非中文時，溝通能力瞬間打折。用英文說明也許不難，難的是一來一往的討論某件事情的時候，要能快速聽懂對方的想法又要適時做出解釋或辯駁。即便不在國外工作也是必須加強的能力，因為你永遠不知道何時會用到它。 - 滿足客戶需求又不失專業的能力
只要是接案就無法避免的狀況，那就是客戶喜歡什麼，你必須要給客戶喜歡的東西。很多時候設計師要放棄自己的堅持，作出妥協讓專案可以順利完成。但設計師可以期許自己做得更多，例如幫助客戶收斂想法、提供更好更適合的解決方案、在可掌握的範圍之下提供彈性，滿足客戶需求卻又維持一致性。告訴自己『客戶提出需求是他的權力，滿足客戶需求又不失專業是你的能力』。持續累積自身經驗，讓自己可以針對不同需求給予適當且具有說服力的建議外，培養談判能力和口才也是很重要的。
更多的心得：
- 理解原因、引導討論勝於批評
常常我們看到某個設計，會先入為主的冒出許多疑問或有不同的建議，但很多設計結果都有造成的原因，也許設計師本人也束手無策，理解原因才能客觀的討論更好的做法。 - 相信專業，下放權力
我們要相信術業有專攻，尊重與理解不同角色做的決策，當然前提是自己要拿出專業來。 - 在團隊中埋下 UX 的種子
UX 不是設計師一個人的事。引導團隊從使用者的角度出發，試著讓團隊參與設計的流程和了解每一個設計決策的原因。除了幫助設計師從不同角度審視自己的設計決策，不要關在自己的小房間裡思考之外，將 UX 的種子深植人心，下一次合作甚至到不同專案，都會有正面的影響。
UI/UX 實作只是專案的一部分，其他還包含前期的技術研究一直到後期介面完成後資料的 migration 等等，最後最重要的是感謝團隊，謝謝 PM 抓緊我們的 schedule、謝謝 PO 與客戶協調溝通和整理資料、謝謝客戶的堅持讓我們不斷精進、謝謝前後端開發人員的努力，讓這個專案可以順利上線。
希望可以帶給使用者更好的體驗，有任何建議也歡迎與我們多多交流：）
