DITLTALK 2014.Oct.9 趨勢科技陳俊宇先生演講記錄

本次非常榮幸請到趨勢科技蒞臨 DITL,上半場我們邀請到 Staff UI Designer──陳俊宇先生來分享。陳先生畢業於成大工業設計系、交大應藝所,曾於 iNSIGHT 臺大智慧生活科技整合與創新研究中心擔任 Information Designer UX Researcher,這樣豐富的設計背景將在演講中告訴我們他如何在上千人的大組織下和專案團隊溝通與合作,還有設計是怎麼樣在企業用戶產品的需求中介入和執行。

trendjumyu01.jpg

瞭解User是成功的一半

設計的價值源於是否觸動到使用者內心的需求所在,所以認識使用者是非常重要的。陳先生從以往的研究工作經驗發現:設計師必須要分析用戶行為、找到其行為背後隱藏的動機,才能精確切入問題並改善之,讓產品達到最大的效益。透過訪問、蒐集回饋來佐證設計在解決問題上提出的假設。

企業用戶產品 vs. 一般消費性用戶產品

一般消費性用戶產品的需求走向偏為生活或娛樂方面的服務,強調的是情感設計(Emotional Design)。以社交軟體 Line 為例,它發掘人對社交的需求和渴望,除了透過軟體介面與他人產生互動,並提供各式週邊服務、給予活潑的形象風格等手法,增加使用者對產品的使用黏著性。而企業用戶的產品規模與一般個人或家庭用戶不同,企業型用戶強調的是產品服務的高效性、穩定度、安全性,陳先生談及趨勢科技對於企業資訊安全的保護,在產品規劃上如何整合企業跨區域(雲端、行動裝置、Local 端)的資料防護,讓防護系統成為容易部署的解決方案,並有效率地讓使用者得到想要的資訊等,皆是企業資安系統的設計要點。

trendjumyu02

系統開發生命週期

系統開發生命週期 (Software/System Development Life Cycle; SDLC),又稱瀑布模式 (Waterfall Mode),為一種組織性的企業資訊系統開發方式。從需求分析 (Requirement Analysis)、設計 (Design)、執行開發 (Implementation)、測試 (Test)、改善 (Evolution),每次循環依不同開發需求,各階段時程會因應調整;以大型的系統開發為例:開發到釋出版本的時程可能為半年到一年,中間經過每次測試版本的釋出,需求分析跟設計要在這樣的循環中不斷地重新調整跟修正,而其中過程皆有相對應的職位角色各司其職。

專案開發中不同的角色

目前新創公司盛行,許多是3-10人的小型工作室,每個人在產品開發過程可能經常會身兼多職:產品企劃、研究分析、設計、開發、行銷等,但一人諸葛在大型企業的產品開發是可行的嗎?

陳先生隸屬於 HIE 部門(Human Interface Engineer),在開發團隊中扮演與其他成員溝通設計的重要角色。他分享在產品開發組成的團隊成員會有:

  • Product Manager:產品經理。定義產品需求功能、目標使用者和時程規劃與計劃下次版本的產出。
  • Project Manager:專案經理。專案最核心的人物。他們必須控制專案的進度、人力分配,並在開發階段決定各種重要的決策。 
  • Architect:系統架構師。程式在開發之前必須先有對整個系統的架構雛形,討論各系統間的資訊是如何交流。
  • Development Manager:開發經理。帶領開發團隊,除了撰寫程式之外,他們還必須評估效能、程式的維護性和穩定度等。
  • Quality Assurance Manager:品保經理。帶領品保團隊,確保產品到最後的品質是否符合設計預期、給予開發團隊測試結果與回饋,讓開發單位能及時修正。
  • UI Designer:介面設計師。與各方溝通設計需求、提出概念設計、產出介面wireframe

在開發過程中,設計單位的角色與其他單位的關係是十分密切的;和PM討論需求是否切入使用者的問題、和工程師一起研究介面的優使性與互動性、歸納QA的問題報告並找出背後使用的癥結點,讓使用者的回饋能快速的進入產品的設計考量。在這個團隊之外的另外兩個角色──Sales和Support,扮演著反映使用者回饋的角色,因為他們面對是最前端的用戶,當設計師無法直接面對使用者時,Sales和Support將會是研究使用行為最好的參考對象。

而這樣一個龐大的團隊中充滿了各式各樣領域的人才,他們是怎麼樣瞭解彼此在說什麼呢?

Communication is the key  跨領域合作的溝通

每個不同的開發角色都帶著他們不同的觀點,心裡想的事情都是不一樣的。如果沒有良好的溝通,容易誤解對方的想法並且無法有同理心去認同他們的立場。陳先生笑談說,工程師在看設計師提出的構想時,心裡可能是想著:這個根本是天方夜譚、像小孩子在隨意亂畫一樣,沒有去考慮到開發的可能性;而設計師看工程師就有可能會覺得這些 Geek 根本不懂使用者想要什麼。團隊中的每一個人都有各自的觀點和立場,設計師常常會陷入這樣的囹圄當中;我們雖然是設計單位,但還是花了非常多的時間開會,去瞭解各方在開發上的想法與考量,並試著讓團隊都認同設計想要做什麼。設計也是一種策略的推廣,在讓使用者信服以前,必須先讓自己的團隊也相信你的設計。

最後希望設計師們除了增進設計能力之餘,同時也要訓練溝通技巧,提升自我的軟實力。

Note: Jar

DITL