Coshift

UX research / UI design / RWD

About

偶然在朋友口中得知他的前同事在小型咖啡廳排班上的難處，思考到目前大多數非辦公室類型的工作都有排班的需求，且大多數店家持續採用傳統的紙本或 Excel 進行處理，但仍然持續抱怨，因此除了我們想了解不同規模的餐飲服務業是如何進行排班作業的，同時我們也想藉由此機會找尋真正對排班感到頭痛的用戶，去了解他們對於排班上真正的需求為何？並依此進行初步規劃。

在這次專案我學到了什麼？

產品架構規劃

從訪談結果中，逐一針對訪談者的回應進行統整，一步一步精鍊內容，最終洞察使用者需求，依此轉化及羅列功能，綜看產品方向和不同操作身份會需要的功能進行整體規劃，在該架構之下規劃出需要產出的User story，確保後續繪製wireframe不會遺漏任何功能。

使用者訪談

此次專案我們對於不同規模的非辦公室類型工作進行訪談，了解企業規模不同對於排班模式的處理也不盡相同，同時也針對訪談內容進行彙整歸納，從質化的面向了解排班者的需求及困擾，期間我輪流擔任過「主訪」、「副訪」和「紀錄」，了解在訪談中如何往細節處持續追問，了解訪談者對於問題的反應，並在過程中學習如何主導談話，及適時拉回。

使用者訪談

訪談對象

依據我們當初的動機我們找尋了擁有龐大排班需求的餐飲服務產業，礙於時間我們最終僅訪問到了五位擁有排班經驗的管理者。

問卷架構

我們從訪談者數位產品偏好、店面型態、職位、店內員工配置、排班程序、排班週期、使用工具、溝通管道和排班相關經驗切入進行訪談。

問卷內容

訪談內容統整

依照訪談內容進行屬性分類

依照職位不同進行分類，並列出使用者需求

依照需求進行粗略需求屬性分類

精煉出用戶洞察，並轉化為直述句

最後，總共統整出 7 個分類，分別為：權力、人力掌控規模、溝通頻率、排班程序數量、負責工作項目、調班處理方式、新人培訓準則，最終分類出的結果為下圖，可以發現身為相對高權力的P2和P5，在分類維度上會ㄧ定程度的向其中一個維度靠攏。

人物誌 Persona

在歸納出所有訪談者特性後，我們大致分出兩種類型。

使用者旅程圖 User Journey Map

在用戶旅程圖中，我們可以針對兩者在旅程中遇到的個別遇到的波動找尋切入點，雖然情況都不可避免，但我們可以在後續規劃上減緩使用者的負擔。

產品架構 Functional Map

根據調查結果產生之產品架構，主要分為：
「班表清單」：目的為管理所有狀態之班表，並進行新增、編輯（修改）、查看、刪除，以及手動通知相關功能
「店家管理」：若店家有其他店面則可以由此新增店面，定義其基本店面資訊和人力規劃。
「員工管理」：目的為管理店家底下所有員工，可以由此為每位員工之工作能力定義，以利之後排班作業。
「技能管理」：目的為管理店面內所有所需技能，後續能力定義在新增或編輯員工時進行定義。
「通知」：主要目的為讓使用者能夠在不同情境下都能及時知曉店家內所有異動狀況。
「設定」：由此去過濾自己想觀看的資訊。