profile

Soking

Soking 來信:任務步驟分析不是流程介紹,而是模組化思考

Published 11 months ago • 1 min read

哈囉,朋友

在規劃產品服務的過程中,使用者流程( Userflow )的任務設計是相當重要的工作項目,然而任務設計的顆粒度該如何拿捏,一直是相當難說清楚的事情。

糟糕的任務步驟描述,可能會如流水帳一般缺乏重點,例如:

煎蛋餅:取出蛋餅皮→鍋子開火預熱→倒油→煎餅皮→準備蛋→把蛋攪拌均勻→預煎的蛋餅翻面→蛋餅起鍋→倒入蛋液→放上蛋餅→蛋餅翻面→摺疊蛋餅→起鍋→剪裁成適合入口大小→完成

上述這類任務步驟的描述方式,充滿了瑣碎的細節,乍看之下似乎是一份詳實的記錄,但對於觀看者來說很常迷失在細節中,不容易掌握整體。

我們重新整理一次這個煎蛋餅的任務:

  1. 預備材料:餅皮、蛋液
  2. 預煎餅皮:餅皮兩面煎至微焦黃,起鍋備用
  3. 組合:將蛋液入鍋,覆蓋上餅皮,雙面煎至微焦
  4. 起鍋:將蛋餅摺疊,剪裁成適合入口大小

上面流水帳記錄用了十五個步驟來描述,經過整理其實只需要四個步驟即可歸納出煎蛋餅這個任務的重點。

問題在於,我們該如何切割出適當顆粒度大小的任務步驟呢?

有三個參考原則可以幫助你做出很好的判斷:

  1. 可獨立:依賴別人才能完成的,不是明確的任務
  2. 可交付:每一個完整的任務都會有明確成果
  3. 可置換:每個任務都是一個問題,同一個問題可以有不同的解決方案

▋任務分析原則一:可獨立 ▋

如果有一個任務你必須與其他角色合作才能完成,那這個任務至少可以拆解成好幾個小任務。

例如你今天要申請加入某個社團,需要填寫申請單並且通過審核才能加入。

那麼這個任務就不僅僅是「加入社團」就結束,而是需要 A 填寫申請單,然後 B 審核,才能夠完成「加入社團」的整件事情,因此至少需要兩個任務才能描述清楚。

可獨立原則的判斷重點在於角色,一個任務過程如果需要依賴他人才能完成,就必須拆分成幾個適當的小任務各自描述角色應該完成的行為。

▋任務分析原則二:可交付 ▋

如果你在任務步驟描述中沒辦法交代這個任務達成的驗收標準,那這個步驟描述是沒有意義的,因為你沒辦法判斷是否達成。

可交付的原則可以很好的幫助你評估「一個任務步驟」應該包含的顆粒度大小。

有些任務步驟看似複雜,然而你如果只完成部分,對整體任務進度來說是沒有推進的意義。

以煎蛋餅任務的描述為例,我們再複習一次流水帳版本:

煎蛋餅:取出蛋餅皮→鍋子開火預熱→倒油→煎餅皮→準備蛋→把蛋攪拌均勻→預煎的蛋餅翻面→蛋餅起鍋→倒入蛋液→放上蛋餅→蛋餅翻面→摺疊蛋餅→起鍋→剪裁成適合入口大小→完成

如果你只拿出了餅皮就結束行動,從整個煎蛋餅的任務角度來看,材料只蒐集了一半。例如你是廚房中負責備料的人,而你只拿餅皮給負責煎台的人,對方是沒有辦法繼續任務的。

因此從煎蛋餅的整體任務目的來看,必須要湊齊所有的食材(餅皮與蛋),一起交付出去,對於後續的任務流程來說才有辦法推進。

即使你為了拿這個餅皮找遍了冰箱、出去採買、與五十個殺手搏鬥、被狗追,只要缺少了蛋,從煎蛋餅的任務目的來看,任務的進度就會卡住。

可交付原則幫助你從整體目的來明確的定義任務進度,而不是被眼花撩亂的行為細節蒙蔽。

▋任務分析原則三:可置換 ▋

如果你今天的任務是要從家裡移動到公司,那麼走路、騎腳踏車、騎機車、開車、搭捷運等等選擇,都可以滿足這個任務的要求,只是你會付出不同程度的代價。

可置換原則在產品服務規模化的過程相當重要,它讓你的產品服務具備更大的彈性、承受風險以及發展空間。

例如你在電商購買東西,在「收貨」這個任務上,你可能選擇超商取貨,或者直接宅配到家,這些方案可能滿足不同用戶的情境需求,因此能擴充服務的彈性。

只要「收貨」這個任務可以被明確的模組化,順利銜接整體服務的前後步驟,持續擴充不同的收貨方式,也就能符合不同階段商業模式發展的需求。

如果你在評估可置換原則的時候發現了困難,例如某一個任務或工序只能由特定的人或工具來處理,這通常也是你的產品服務發展的瓶頸。

換句話說,只要你的產品服務某一流程綁定在特定的人或工具上,如果某一天這個特定的人消失,或是該工具沒有人能夠提供或維護,你的產品服務也就會跟著瓦解。

在軟體產業來說,可能是過度依附於某個大型服務的生態系,例如以前過度仰賴臉書的遊戲公司。

或者過度仰賴 Google 地圖、LINE chatbot 的某個 API,當這些被你視為基礎建設的服務改變了使用規則,你的產品服務就危在旦夕。

對於不同產業的產品服務來說,仰賴單一供應商的風險也非常清楚。

即使在產品的發展初期不得不仰賴特定的對象,但是如果能在任務步驟分析的時候就適度的抽象化,保留可置換的空間,你還是有機會尋求不同的解決方案來抵消產品服務斷炊的風險。

以上三個原則分享給你,希望能幫助你更好的判斷任務步驟分析該如何模組化思考。

by Soking

Soking

千綺創意設計 Co-Founder / 產品設計總監,目前經營軟體領域的體驗設計顧問公司,也從事 UX 教學,喜歡以工作坊形式,引導你體驗 UX 領域的專業知識。 工作聯絡:service@soking.cc

Read more from Soking

哈囉,朋友 你如何評估一件事情做得好呢? 直接聽聽顧客的聲音如何? ▋聽取顧客聲音,就要照單全收嗎? ▋ 我曾經在自己舉辦活動的時候,收到參加者的回饋,希望多聽一些實際案例。 太棒了,我下次就加碼加料,多講三十分鐘客戶案例的經驗談。 但是別的參加者抱怨了,他們說:只聽經驗談不知道該如何落地。 又有參加者問,這些東西該怎麼樣才能變成作品集? 如果我每聽見一種類型的聲音,就在活動裡面多添加一個元素,很快就會發現,原來的規劃變成了四不像。 更糟糕的是,明明是聽取顧客回饋作的調整,結果還讓大家都不滿意了。 難道聽取顧客意見不對嗎?該怎麼辦呢? 我們的確需要聽取顧客的聲音,但是不能只憑感覺。 一來,人都會有偏見,很容易只看見自己想看見的事情。 二來,所有的意見都照單全收,只會迷失自己。 那些顧客的聲音沒辦法讓我們知道怎麼樣才是對的。 我們需要的是相對客觀的蒐集顧客聲音的方式,並且能攤開來檢視證據,跟夥伴一起合理評估。 如果你已經有實際在運作的產品服務,但平常都是盯著廣告觸及以及訂單數量在檢討。 我想與你分享運用「滿意度問卷」來聆聽顧客聲音的方式。 ▋辨別客群的常用題型:人口特徵 ▋...

about 23 hours ago • 1 min read

哈囉,朋友 相信沒有人會反對越多顧客越好。 許多時候「閃電擴張」甚至被視為萬靈丹。 但很多時候不是擴張就可以解決一切商業問題。 如果我們把產品服務想像成開一台公車上路。 你可能會在沒有客群的地方開拓新路線,這是資源上的浪費。 你可能會在擴充車隊的時候發現沒有司機以及後勤保養不足,這是缺乏增長的條件。 你可能會想經營觀光路線,卻發現因為缺乏方便的外國人支付方式以及公車路線的 GPS 動態,外國客群沒辦法透過 Google Map 輕鬆方便的使用,導致願意嘗試的人很少。 若是要專門為觀光路線投資這些技術,其他一般路線又看不見效益。 這些「用戶增長」上會遇到的問題,都可以燒錢解決。 但我們的資源會在哪些事情上面燒掉呢? 以下我想列出幾個評估重點,用來與你一起思考用戶增長: 產品是否 PMF 現有目標客群的 LTV 獲客成本的結構 目標族群的增長環境 新羊群與第二隻羊 ▋產品服務是否 Product-Market Fit ▋ Product-Market Fit 是指,我們的產品是否有符合市場需求? 認真的說,有許多產品在沒有 PMF 的情況下,開始想著要放大。...

8 days ago • 1 min read

哈囉,朋友 我在與人討論 ABZ 計畫時,經常聽到一個困擾,類似這樣:「除了正職的工作以外,我假日再去兼差,一開始收入提昇了不少,但發現越來越沒有自己的休息時間。直到後來正職工作產生變動,連假日都要去支援,害我不能進行兼職工作,收入馬上變少,但又不能用兼職工作取代正職,感覺做了很多事情但沒有任何累積。」 像這樣明明很努力,但卻滿盤皆輸的局面,動輒以年為單位白白浪費我們的歲月年華。 問題到底發生在哪邊呢? 相信你應該可以察覺,在這樣的故事中,兼職工作本身並不具備當 A 計畫不可行的時候,隨時能夠以人生備案的姿態頂替上去的可行性。 以致於當 A 計畫變得更加消耗人生餘裕時,變成要捨棄兼職工作,於是人生選項減少,不僅僅是回到原點,狀況還更加糟糕。 在思考如何擴充人生選項的 ABZ 計畫框架中,有三個評估方向可以幫助我們檢視自己的計畫,是否具備未來可行性,我將這個概念稱為「最小單位的可行性」,包括: 可獨立執行 可明確交付 可轉移情境 ▋可獨立執行:每個計畫都是獨立的一人部門 ▋ 我們常常聽說過「一人公司」的概念,除了是自僱者以外,也可以把自己的人生當做公司來經營。 但在 ABZ...

about 1 month ago • 1 min read
Share this post