蕭仿吟
Fiti Hsiao
Design & Practice skills： Sketch、AI、PS、Axure、Ze
1993.10.22 fitihsiao@gmail.com
SkyMirror
Dcard
BeepBar
Stranity
Product Owner
Cirple
Dcar
UI / UX Designer
UI / UX Designer
Proto-Persona
UI Flow
Flow Chart
Proto-Persona
Stakeholder Maps
Resource Map
UI Flow
Stakeholder Maps
MVP
Wireframe
Wireframe
Flow Chart
User Journey
Mock up
Mock Up
UI Flow
Hypothesis
UI System
UI System
Wireframe
Assuming
Landing Page
Google Analytics
Mock Up
Release Icon、Screen Shot
Release
User Story Fuctional Map Flow Chart
eplin、Books、User-centered Design
InfoPlat d
HU HU Studio
InfoPlat
GIS Taiwan
3D Movie - ZOO
Global Initiatives Symposium in Taiwan
Intern UI Designer
Designer
Intern Modeler
Designer
UX Dcard Search Rule
UI Recruit Landing Page
3D Modeling
Graphic Design
UI Introduction Page
UI Blog
Texture
UI Friend Board UI Member Center UI Mail
Project 1
BeepBar
菜嗶吧 BeepBar 是一款以剛性需求所發想及計畫的 APP，整合文化層面的推薦菜色， 使商家與用戶間用餐、點餐的流程更為流暢。 BeepBar可以解決許多用餐流程上的困擾，譬如：傳統紙本菜單 每桌分配數量不夠、與朋友聚餐，有人遲到導致餐點延後上桌， 以及辦公室團體點餐，店家菜單無法及時反映原料短缺相關問題…
負責項目 Proto-Persona
Assuming
Resource Map
Stakeholder Maps
User Story
Wireframe
MVP
Fuctional Map
Mock up
User Journey
Flow Chart
UI System
Hypothesis
UI Flow
Landing Page
Project 1 Assuming (1/3)
BeepBar 假設： [ 美食搜尋 ] 目前的狀態主要聚焦於 [ 美食介紹及評分 ] 。 [ 競爭對手 ] 未能解決 [ 用餐、點餐，外送流程以及菜單總匯 ]。 我們的 [BeepBar ] 將透過 [ 即時訂單、菜頭家(店家) ] 來解決這項落差。 我們最初的重心會放在 [ 學生族群 ] 。
Hypothesis 假說敘述(將假設轉換成易於測試的格式)： (1/5)
我們相信 [ 用餐、點餐，外送流程以及菜單總匯 ]，此需求。 當從市場看到 [ 三個系學會中，一個月成立 500筆訂單 ]。 就知道是 [ 正確及可行的 ]。 假說：策略與測試 只要 [ 剛入學新生 ] 利用 [ 即時訂單這項功能 ]，成功實現 [ 訂餐 ( 可將餐點數量統計到商家 ) ]， 就能達成 [ 讓商家願意為菜頭家支付統計功能月費 ]。
Proto-Persona
住在學校附近
Jakie
三餐外食 Age：18~23 (大學生年齡)
常揪團一起吃飯 手機重度使用者 無信用卡，只有VISA金融卡
揪團吃飯的時候需要排隊看菜單很麻煩 常常忘記自己吃過什麼好吃的 覺得每次吃完飯要算服務費的金額很麻煩
自己是個挑食的人，每次叮嚀過店家 不要放青蔥，但店家還是常常忘記
設計核心 流程設計需求： 除了最基本的使用流程外，加入Gamification 增加目標用戶黏著度 須注意用戶訂單之相關規則與實際店家菜單規則 須注意相關利害關係人之功能需求與收費模式 必須和實地推廣流程與數位推廣相結合 風格設計： 會有大量的圖片資訊，色彩配色系統需與之食物照片配合 目標用戶為年輕族群，視覺應用上須為活潑、較搶眼
Project 1
BeepBar
User Story 身為一個看菜單的使用者，點開菜單後有菜色的圖片方便我知道那道菜的樣子。
身為一個看菜單的使用者，我希望能在菜單上面看到吃過這道菜的人一些簡單的想法，或者可以看到
身為一個看菜單的使用者，在菜單上點選了一道菜後可以看到大家的簡短的評論，比如"很鹹"或者" 身為一個看菜單的使用者，我希望可以知道一起聚餐的朋友點了什麼。 身為一個看菜單的使用者，我想要在正式點餐前就知道今天有些餐點是否沒有提供或已銷售完。 身為一個看菜單的使用者，我希望服務費在 Go Dutch的時候也能簡單的知道。
User Juorney
Jakie未使用 BeepBar的一天，以及使用後與菜頭家 ( 店家系統 ) ，與 Skymirror 的旅程圖
到很多人推薦的菜色，也希望可以在菜色上面做一些簡單評論。
"很辣"又或者"建議不吃辣的人不要點"。
Project 1
BeepBar
Stakeholder Maps 因為菜單資料是由店家所提供，所以在終端使用者與店家間的利 害關係必為重要的討論方向與重點。
Minimum Viable Product
在 2017年 7月，以 Version 1.0.0的 MVP參加了軟體應用展，在展中驗證了終端使 用者以及店家的需求，同時先以散播力強、接受度較高的大學生為之後目標族群， 也與店家確認了業務需求和簡單的商業模式。
Project 1
BeepBar
Landing Page 虛擬的軟體 APP與實體的菜餚實物作結合，為主要的風格走向。
Project 1
BeepBar
Resource Map 以 CRUD 和 Flow作結合的 resource map可以協助 RD與 設計師資料庫相關的溝通。
UI Flow
Project 1
BeepBar
Mock Up
使用者可以在美食探索頁，經由相關條件 搜尋後， 找到自己喜歡的菜餚或店家，瀏覽其他顧 客的評論知道基本的相關資訊， 更可以切換到菜單頁， 直接做點餐的動作，如果需要多人一起訂 餐也能進到同桌點餐的訂單模式， 只需在最後做此筆訂單是屬於需人外送， 還是自取的模式，就能和好友一起享受美 味菜餚。
Project 1
BeepBar
Mock Up
使用者可以在美食探索頁中看到自己喜 愛的菜餚， 將他珍藏起來到收藏頁中， 而在美食足跡列表中， 則可以看到自己之前造訪過的店家與吃 過的美食， 甚至連與哪位朋友同桌點餐都可以在此 觀看。
Project 2
Stranity
負責項目
策略無限 Stranity 是一款機器人理財策略平台， 提供的是各種策略運算， 使用者可以經由月租方式，利用策略專屬特性， 在期貨市場取得高品質的投資報酬率。
Flow Chart
Mock Up
UI Flow
UI System
Wireframe
Google Analytic
設計核心 流程設計需求：
盡量在符合法規的前提下流程簡單
透明資訊，提高金融性產品信任度
金融憑證銜接第三方 API將有更多
在不同平台購買系統貨幣將有手續 風格設計：
每個策略將有不同的特性：風險高 金融商品特定顏色之使用
區分理論和已租用策略的下單記錄
Release Icon、Screen Shot
cs
單而順暢
度
多特殊狀態以及權責區分
續費抽成相關問題
高低與類型
錄
Project 2 UI Flow
Stranity
Stranity
UI System Color Palette
Cards
- $ 88,000
Titles
padding:[2,10]
Tags
padding:[1,1]
shadow:#000000 A: 30 [0 / 1 / 3 / 0 ]
$ 888,888
Navigation
Strategy Color Code
Project 2
Stranity
Mock Up
Overview 打開 App的 Overview可以瀏覽到最重 要的資訊： 今日的所租的策略總報酬、歷史總報 酬，以及總策略圖像化的統計圖表。 在中間部分使用者可以知道現在所租 用的策略狀態以及個策略的分別累積 報酬。 進到內頁後則可以改變策略的使用狀 態和知道此策略的特性與專屬於此策 略的每日每月的下單記錄。
Project 2
Stranity
Mock Up
Strategy 在策略列表頁中，為了幫助使用者能 在將近三十個策略中找到適合自己的 策略，設計了一個小測驗幫助他們租 用策略。 在進入策略詳細頁中，即可租用策略 ，但在租用和運行策略前，必須先滿 足上傳金融憑證和擁有系統貨幣才能 正確的租用策略。
Project 2
Stranity
Mock Up
Menu 在選單頁中，可以直接看到擁有的系 統貨幣數量，以及進入各個較細項功 能頁，如：憑證上傳頁、虛擬幣紀錄 、通知設定、常見問題......
Project 3
Cirple
果果家庭 Cirple
是一款關於家庭生活與社區功能的 APP，社區住戶可以經由果果家庭預約公 登記瓦斯、繳交社區、生活費用，等等相關功能，讓生活更加的便利。
設計核心 流程設計需求： 從 v.2.0.0 Kiosk裝置情境，轉為個人 Mobile使用情境 通知需適當不過度干擾 須注意相關利害關係人之功能需求與收費模式 必須和實地推廣流程與數位推廣相結合 風格設計： 遵循家庭溫和的配色 Redesign 原有以顏色為功能區分
負責項目 Proto-Persona Stakeholder Maps Flow Chart UI Flow Wireframe
公共設施，以及收取包裹、
Mock Up Release
Project 3
Cirple
Proto-Persona
普通的朝九晚五的上班族
李爸爸
擁有一個上高中的兒子，以及一位在外地求學的女兒 Age：35-50
有二十年的房貸 住在一個有警衛及總幹事的兩百戶社區 與爸爸媽媽同住，是一個三代同堂的家庭
覺得繳交社區管理費用很麻煩，需要與總幹事紙本簽收 曾因忘記填寫紙本瓦斯繳費單，而與社區總幹事產生糾紛 之前預約公共設施時，發現遺失了公共設施預約點數卡
專職的家庭主婦
林媽媽
擁有兩個正在上小學的小孩 Age：30-45
在另外一個社區有另外一間房子 住在一個有警衛及總幹事的一百戶社區 喜歡網路購物 熱衷參與社交、社區活動
上網購物寄來的包裹數量較多，曾與警衛拿錯包裹的經驗 曾經因為遺漏公告，而沒參與到社區活動
Stakeholer Map
果果家庭是與物業公司部分綁在一起的，所以平衡客戶與用戶之間的關係，是在 設計過程中需要一直被探討的問題。
Project 3
Cirple
Wireframe 公設預約通知改善
在社區公共設施中，比較複雜的是每個社區有著 不同的扣點方式與規則，和取消預約的方式。
瓦斯登記
在社區各種服務中，將傳統都需要到同一地方做紙本 的登記瓦斯紀錄數位化，結合到果果家庭中。
Project 3 Mock Up 版本切分、接環境API、合作方生活繳費 API
此階段，新增了與合作方的生活繳費 API頁面，和政府開放的 空氣品質與紫外線 API，以及為果果家庭去做版本切分，開放 不同部分功能為切分版本的主要方式。
版本切分、價格揭露、關於果果
除了切分版本，新增了價格揭露頁面，此 頁面主要用意在於終端用戶與物業公司 (總 幹事 ) ，和天鏡三者間的權責區分。
Project 3 Mock Up 版本切分、接 環境API、合作方社區繳費 API 此版本已有開放部分社區功能；須考慮合作方繳費 API提供 的資訊、資料格式，以及相關限制。
“ Cognition attempts to make sense
of the world: emotion assigns value. � - Donald A. Norman, The Design of Everyday Things