profile

Soking

Soking 來信:軟體任務的本質是滿足資訊需求

Published about 2 months ago • 1 min read

哈囉,朋友

今天想與你討論軟體產品設計時,相當重要但在工作上又幾乎未被討論的基礎元素:「資訊需求」。

▋什麼是資訊需求呢? ▋

我們在買早餐的時候,早餐店老闆是怎麼知道我們想買什麼呢?

我們拿到早餐要付錢的時候,又是怎麼知道要付多少呢?

早餐店老闆辛辛苦苦的忙碌之後,下午打烊收店時,又怎麼知道今天賺了多少錢呢?

這類問題都是軟體擅長解決的事情,也是我今天想與你討論的「資訊需求」這回事。

資訊需求的意思是說,當我們要完成特定的行為目的時,必須提供的情報。

早餐店老闆需要先提供「菜單」的情報,消費者才知道有哪些選擇。

消費者要告知「點餐內容」的情報,早餐店老闆才知道要如何吩咐其他人料理。

根據點餐內容,早餐店老闆經過計算,才能告訴消費者「結帳金額」。

辛苦忙碌一整天之後,早餐店老闆統計今天所有「訂單內容的結帳金額」,才能得知「營業額」的狀況。

▋資訊需求的兩種類型 ▋

資訊需求在軟體服務的情境中,有兩種類型:內容即目的、產生新資訊。

想像我們要將早餐店的服務情境打造成一個軟體服務,就像你在麥當勞看到的自助點餐機。

內容即目的的情境有:

  • 消費者需要點餐(任務),必須知道有哪些餐點(資訊內容)。
  • 早餐店老闆要製作餐點(任務),必須知道消費者的訂單點了什麼(資訊內容)。
  • 早餐店老闆想了解今日營收狀況(任務),必須知道今天所有的訂單資訊(資訊內容)。

產生新資訊的情境有:

  • 早餐店老闆要決定店裡賣什麼(任務),必須提供出一份菜單內容(產生新資訊)。
  • 消費者想要獲得早餐(任務),必須跟老闆提出他想要吃什麼(產生新資訊)。
  • 早餐店老闆要收錢(任務),必須根據消費者的點餐訂單計算出結帳金額(產生新資訊)。

A 提供某種資訊給 B 在特定情境下使用,軟體服務往往長成這副德性。

聰明如你,應該可以發現這兩類資訊需求的情境,往往是上下游關係。

因此軟體服務在規劃的過程,本質上就是在釐清:

  • 在特定範圍的情境中
  • 有哪些角色
  • 需要完成什麼任務
  • 有什麼資訊需求
  • 滿足何種目的

▋資訊需求的前置作業:任務步驟分析 ▋

如果說資訊需求就是完成特定行為所需要的情報。

那麼辨別資訊需求的前置作業,就是任務步驟分析。(我必須先假設你已經釐清商業邏輯、服務範圍、設計目的。)

如果是在 B2B 軟體的設計情境中,通常可以找到對應領域的專家,與專家一起協作進行知識萃取,將任務步驟解析出來。

就像把早餐店老闆抓來,一步一步的盤點確認,他是如何規畫菜單、如何點餐結帳、如何出餐以及每天如何關帳。

將整體的服務脈絡釐清之後,根據相依性拆解為若干各自獨立的小任務,每個任務又可以拆解為數個可交付步驟。

到了具體的「可交付步驟」被解析出來後,資訊需求的長相才算是明朗化。

我們會意識到,如果早餐店老闆沒有規劃菜單,那消費者就會無所適從。

如果消費者沒有明確的提出點餐內容,早餐店老闆也不知道該怎麼提供餐點。

在軟體服務中,每一個可交付的任務步驟,都隱含著內容即目的(例如看菜單)或是產生新資訊(例如點餐)的資訊需求在其中。

這是我對於資訊需求這個主題的思考,分享給你。

希望能幫助你釐清我們在軟體設計的日常工作中所面對的任務本質。

by Soking

Soking

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

Read more from Soking

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

1 day 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