MediaTek Cloud Sandbox Design Share

物聯網裝置的雲端資料服務平台

Abby Chiu
Abby Chiu
May 21 · 10 min read
MediaTek Cloud Sandbox
嗨,大家今天過得好嗎?好久不見了MediaTek Cloud Sandbox(簡稱 MCS)是我進 MTK 第一個負責的專案。目前已累積了12000+ 位的開發者,並衍伸出許多 Side projects。每完成一個階段後總是想好好介紹它,但專案不斷的成長,總是找不到好的切入點。目前專案已達到成熟的階段,加上這份工作滿四年多了,決心要好好記錄一下這個過程。而這篇文章其實早在去年六月就已經寫完 80% 了,無奈後來人生開始一連串的忙碌,一直延宕。本來也想放棄不寫了,但每次收到 Medium 通知說有人開始追蹤的時候,內心還是無比激動,沒想到自己的經驗可以持續引起別人的共鳴,也或許能帶給別人一點幫助?誰知道呢?於是又整理了一下,分享給大家。

好久好久以前,在我加入團隊前,團隊裡並沒有設計師的角色。工程師們先買了一套 UI Kit 後將功能套上。隨著功能越來越多、需求越來越複雜,需要有設計師針對客製化功能設計 UI、掌握整體使用流程,並提供使用者良好的操作體驗,我才加入團隊 😉

MCS 對我來說是一個很重要的專案,除了它是我第一個設計的 Console 類型網站外,也包含了 Landing page、Desktop app、Mobile app 以及各類 Marketing 文宣的設計。經歷了 MCS 專案後,提升了我對網站各類元件的熟悉度、敏銳度,也讓我設計了第一套 Design system,衍生出屬於我們的 UI Kit: MTK UI,並應用在公司內外部各個 Project 中。

MCS Design Guidelines

由於專案運行已久,很久以前的想法或是決定的過程現在已經無法考究,所以主要會以介紹 MCS ,以及如何開發各項功能的過程及方法,來記錄它。


What is MCS?

MCS

MediaTek Cloud Sandbox (MCS) 提供您打造準備商業化的穿戴式和物聯網裝置,所需要的數據和裝置管理服務。它支持您專心的開發產品原型,不必煩惱建立一套自己的雲端基礎設施。

您可以在我們提供的強大的網頁儀表板介面上,看到使用我們提供的 RESTful API 從裝置蒐集回來的圖形化的資料。之後,您可以通過從儀表板發出命令控制您的穿戴式和物聯網裝置。此外,我們提供附屬的手機應用程式讓您能查看蒐集到的數據,並從任何地方控制您的裝置。

讓開發者可以專注在開發上是 MCS 的核心價值

主要流程示意

精簡的說,MCS 是開發者的雲平台,讓開發者可以將裝置的數據收集到平台上,提供視覺化的呈現,並且利用平台遠端操控自己的裝置以及管理裝置。

Why do we develop MCS?

MTK 本身是晶片設計公司,前幾年物聯網當道,站在巨人肩膀上的我們思索著除了晶片本身外,有沒有額外的附加價值可以嘗試。於是我們一邊觀察市面上已有的產品或類似服務,一邊接觸各類小型開發團隊,從中摸索出 MCS 的初步型態。接著透過 MVP( Minimum Viable Product 最小可行產品)的發佈,累積使用者後,再從使用者身上得到更多使用需求,陸續發展出 MCS Lite 以及 MCS Enterprise。

Who is our target user?

最一開始設定的使用者是獨立開發者以及開發團隊 → MCS
針對小型私人場域所設計輕量的 → MCS Lite
目前已推出適合企業用的 → MCS Enterprise

When to use?

當,想專注於開發產品原型,不想煩惱如何建立自己的雲端基礎設施時
當,開發過程中,想要即時驗證並且快速測試時
當,開發完成,想要產品化並作管理時

Where to use?

可以在我們的雲上使用 MCS
在私人網域使用 MCS Lite
或是在自己的雲上使用 MCS Enterprise。

How do we develop MCS?

專案運行方法:Scrum,為期兩週一次的 Sprint
團隊成員:PO、BD、Scrum Master、Backend Developers、Front-end Developers、Designer、QA

Step 1: PO 與 BD 收集需求後,寫 User Story
工具:Confluence

需求由誰決定、如何決定,我們試過很多方法。例如在最一開始專案剛起步的階段,為了快速擁有 MVP,PO 或內部成員會直接提出自己的想法與團隊討論 。當擁有了 MVP 後,隨著團隊人數的增加與經驗的累積,我們大致發展出下方的做法:

PO 與 BD 拜訪用戶談進一步的需求、Designer 做使用者訪談與觀察發現需求、QA 測試後發現 bug 需要改進等等,將這些需求通通收集起來放進 Confluence 的 Backlog 裡,再由 PO 整理寫出完整的 User Story。

As a (role of user), I want (some feature) so that (some business value).

Step 2: Scrum master 與 PO 與 BD 排定開發時程,與團隊討論 User Story
工具:Confluence、Jira
Scrum master 最了解團隊目前的開發進度與狀況,所以擁有了 User Story 後到底哪個要先做?Scrum master 會與 PO 與 BD 進行討論,依據需求的緊急度做規劃,同時也提供 PO 與 BD 這項新功能團隊何時可以完成的資訊。

接著 PO 與 BD 會跟整個團隊進行 User Story 的說明與討論,Designer 與Developer 可以在這階段提出各自的疑問與建議。直到團隊成員都了解 User Story 實作的意義、大致實作的方向、已經預想到的問題互相確認後,才開始實作。這時候就會利用 Jira 這套工具,列出各自有多少 Task 需要完成,Scrum master 也會用這套工具來追蹤個別的進度。

我們曾經使用估點數 (Planning Poker) 的方法來排定每個 Sprint 每個人要完成多少 Task,但使用一段時間後,估出來的點數差距越來越小,代表的意義不大,到最後流於形式,就不再採用了。

不再採用後,就是採用自由心證法,自己寫上預計完成的時間。

Step 3: Designer 畫草圖或 Wireframe 確認使用流程與大致畫面配置
工具:紙筆或 Balsamiq 或任何工具
每個 Designer 習慣的工具不同,我個人還是最喜歡紙筆:)除了喜歡筆刷在紙張上的觸感外,這樣修改是最快速的。但如果是已經很確定的內容,例如既有功能的延伸,或是要在比較正式的場合上露出,也有可能直接用 Sketch 或是像 Balsamiq 這樣的軟體繪製。

MCS 草稿

圖畫完掃描後會歸檔到 Confluence 上讓團隊成員審閱,通常在畫圖的過程中可能會發現當初沒有設想到的問題,一並列出讓大家可以在同一個空間上討論並記錄最後討論的結論。

有經驗的設計師會在這階段體現他的價值,甚至在一開始聽到 Story 後,就可以預先設想到設計上會遇到哪些問題、有哪些事情必須先跟前後端討論好,大幅減少後續溝通以及修改的次數。如果 Step 2 和 3 做得很好,例如大家都很認真開會、通靈能力大增能預知到會發生什麼問題提出並解決,那這一階段會很有效率的結束,不然就會陷入無限修改的輪迴中。

Step 4: Designer 畫 Mockup,Developer 做基礎工程
工具:Sketch、React.js、Node.js、Go

如何避免無限修改的輪迴呢?坦白說沒有一定可以避免的辦法。專案的複雜度不一樣、合作的人不一樣、對專案的理解不一樣,多少會影響到。修改是無法避免的,所以前兩個步驟更為重要,它能有效降低修改的次數,盡量在 畫 Mockup 階段前,凝聚好大家的共識。

MCS 主要功能頁面

Designer 畫 Mockup 的同時,Developer 可以先架設環境或先開發一些基礎工程。畫 Mockup 我覺得是相對單純的階段,除了事前視覺提案外,確定風格後,這是我在執行上花最少時間的階段。

當然,有時也會遇到某些元件或圖片一直決定不了要如何呈現,也可以先將既有的 Mockup 提交給 Developer,讓對方先開工確定的部分,避免延誤到對方的開發時間,自己再慢慢刻畫。簡單來說,要記得這是團隊合作,不是自己個人作品秀,不是每一次都能將作品做到一百分才提出,有時必須做出取捨,對於團隊來說,開發時程是最重要的。

Step 5: Designer 提交 Mockup、Spec & Assets,Developer 進行開發
工具:Sketch Measure

My project folder

Designer 的工作不是交付完設計檔案後就結束了。除了交付設計外,也要協助 Developer 解決開發上遇到的設計問題。例如一些平面圖無法呈現的互動效果,Designer 需要找些範例或是準備 prototype 來說明要達到怎樣的效果,而不是讓 Developer 自己通靈。

Principle 做的示意小動畫

有時也會遇到提交的設計圖,Developer 在有限的時間無法完成的情況。這時我們會先討論其必要性及重要性。是不是真的必要?是不是有其他方式可以取代?開發後能否重複利用?如果沒有結論,再請 PO 來做出決定。

Step 6: Developer 開發完後推到 io 環境, QA 測試,Designer 協助檢查操作流程及介面完成度
開發完成後自己一定要使用看看,看看自已的設計是否合理、使用流程是否流暢,這也是對自己的設計負責任的態度。

噢對,Designer 的眼睛跟別人不一樣,這是真的,你看得到別人看不到得細節,相信自己。自己把關後的產出一定加一百分喔 💯

Step 7: 發佈新功能到 .com 正式環境
在正式發佈新功能的前後,我們會準備好相對應的文案做宣傳的準備。例如發佈電子報通知目前用戶、臉書粉絲團發佈消息,如果剛好有遇到參展需求,也會準備海報、宣傳單等等。

歷年的 DM 與 海報

以上就是我們開發的大致流程。


後記

經歷這個專案後,除了提升自己的專業技能、對網站各類元件的熟悉度、敏銳度外,還有一點值得提出的是:學會問對問題

關於這一點,我想起了我之前看到的一篇文章,裡頭分享:

『從一位 UX 設計師的角度來看,對產品經理問對的問題,能幫助你的設計,確切滿足商業目標;對工程師問對的問題,能幫助你在已知的技術限制下,提出創新的方案;對使用者問對的問題,能幫助你深入了解使用者的渴望,提出不僅可用(Usable)且有用(Useful)的產品。』

我當時看到這篇文章時,點頭如搗蒜,非常建議大家看看。除了設計專業的培養,問問題也是很重要的技能:

如何清楚地表達自己的問題
如何在對的時機點問問題
如何找到對的人問對的問題

最後最後,因為這個專案我認識了很多好朋友、好同事。這些年有些人離開,也持續有人加入。謝謝參與過此專案的大家,我真的從大家身上學到非常多東西:)

僅以此文紀念那些年,我們曾經開發的 MCS(怎麼這麼悲傷的結束XD)

AAPD — As A Product Designer

AAPD 專注於分享數位產品設計的相關資訊,並且致力在平台上創造更多的交流與互動,我們關注UI設計、UX設計、設計師的個人成長、設計趨勢與產業動態等,希望透過這些知識的傳遞,能夠降低每位設計師成長的過程中所遇到的阻礙。歡迎來信投稿:aapdgo@gmail.com

Abby Chiu

Written by

Abby Chiu

UI/UX Designer at MTK.

AAPD — As A Product Designer

AAPD 專注於分享數位產品設計的相關資訊,並且致力在平台上創造更多的交流與互動,我們關注UI設計、UX設計、設計師的個人成長、設計趨勢與產業動態等,希望透過這些知識的傳遞,能夠降低每位設計師成長的過程中所遇到的阻礙。歡迎來信投稿:aapdgo@gmail.com