profile

Soking

Soking 來信:定義一個好問題,問題就解決了一半

Published 10 months ago • 1 min read

哈囉,朋友

最近我在研發新的產品設計師課程,找了我們家的實習生來當白老鼠試教,沒想到在討論「設計目的」的時候,就足足花了一個小時,讓我發現了自己的知識詛咒。

原來,定義一個足夠好的設計目的,真不是容易的事情。

設計目的就是描述一個需要被解決的設計問題,在撰寫設計目的的時候,需要以終為始的想像,如果這個問題被解決了,會帶來什麼樣的價值,以此作為我們出發的理由。

我想要透過本文整理三個幫助自己定義好問題的小技巧:

1. 好問題幫你增加選項

2. 問題本身決定了答案的形式

3. 挖掘隱藏的前提

▋好問題幫你增加選項 ▋

定義一個需要被解決的問題,有許多陷阱,糟糕的問題描述可能長這樣: 「我在挑選下午茶的點心,正在考慮雞排跟蛋塔要選哪一個?」 「我想要買下午茶的點心,這間店有特價優惠,我應該進去看看嗎?」

像這類「膝反射」的問題描述方式如果是在日常生活中,或許只是讓我們多花一些錢吃進本來應該避免的熱量,或是買了不知道要幹嘛的東西,但是在工作之中卻會造成盲目的無效率努力。

在工作中出現糟糕的問題描述形式,例如這樣: 「我在尋找合作的廠商,我應該要選 A 廠商還是 B 廠商?」 「市面上出現了新的工具,我應該導入工作流程嗎?」

不論是選擇 A 廠商還是 B 廠商,以及是否該導入新工具,這都屬於封閉式問題。依據這樣的思考方式容易陷入細節規格的比較,即使最後勉強做出了決定,但最終可能不確定該如何評估成效。

當我們不知道該如何評估成效,那做出任何選擇,有意義嗎?

如果我們把問題描述的方式換成: 「我在尋找合作的廠商,這次的專案複雜度高,需要尋找經驗豐富的團隊。」

這個時候我們要評估的就不是 A 廠商還是 B 廠商,可能這兩個廠商都只做過難度低的簡單專案,優點在於快速套用重複的模版,如此一來,我們就知道不能拘泥於眼前的選項,而是要重新尋找適合解決我們問題的合作對象。

當我們定義了一個好問題的時候,可以防止自己跳入膝反射的選項中,並且建立評估的標準來確保最後成果能符合需求。

▋問題本身決定了答案的形式 ▋

當我們腦袋想著:「我在挑選下午茶的點心,正在考慮雞排跟蛋塔要選哪一個?」的時候,其實就已經決定要吃下午茶了。

當這件事情變成下意識的選項,壞習慣的養成就出現了,而這個壞習慣雖然可能滿足短期需求,但卻有損長期的健康,而這可能不是我們想要的結果。

在這個情境中,「下午茶」這個需求描述已經定義了解決方案的範圍,但沒有揭露真正想滿足的目的是什麼。

例如我們可能是因為工作坐太久,希望可以站起來走動透透氣,因此出去買杯咖啡晃一圈,順便帶點吃的也不錯。

在這個情況中,真正的需求可能是轉換心情適度的放鬆,而下午茶點心只是其中一種選擇。

但例如我在舉辦一整天的訪談工作坊時,也會幫學員準備下午茶點心,這個時候我背後的需求是:「學員進行高強度的演練很燒腦,需要適度的補充糖分讓腦袋維持能量,以及適度的休息,才能表現良好的完成課堂內容。」

我們在描述問題的時候,就決定了答案的形式。

當我們在問題之中不小心加入了解決方案的描述時,就侷限了答案的範圍,這樣的答案也有可能是錯誤的範圍,帶我們走入死胡同。

▋挖掘隱藏的前提 ▋

前面提到一個情境的問題描述是: 「我在尋找合作的廠商,這次的專案複雜度高,需要尋找經驗豐富的團隊。」

乍聽之下似乎像是個合理的說明,然而這個描述背後隱藏的問題是,為什麼要冒風險去做複雜度高的專案?為什麼不使用自己的人而要去外面找團隊?

如果我們不清楚問題背後隱藏的前提,也很容易用錯誤的方式來定義問題。

有些企業之所以冒風險去做複雜度高的專案,可能是因為想要擺脫更高的風險,例如我們曾經有遇過客戶本來是購買套裝軟體,但過去的套裝軟體廠商可能技術上二十年不變,甚至已經無法提供更新或調整,如此一來所有新的數位環境的服務體系,都跟該客戶使用的套裝軟體格格不入,中間的斷層就仰賴大量無效率的人力在填補,以致於所有商業模式上的想法都卡死在這個環節。

對於決策者來說,就面臨著「做了是找死,不做就等死」的情況。

許多時候一些難解的問題如同房間裡的大象,每個人都知道大象存在,但下意識認為這是無法解決(或不願意解決)的問題,因此後續在做任何問題決策的時候,就產生了各種扭曲的規則,只為了繞過那頭大象。

我們在聆聽合作對象描述需求的時候,就需要耐心的去挖掘背後隱藏的前提,避免這些無形的限制成為未爆彈,直到誤觸之後才被炸得渾身是傷。

總結一下,我們在定義一個好問題的過程,有三個小技巧:

1. 好問題幫你增加選項,防止自己跳入膝反射思考

2. 問題本身決定了答案的形式,注意問題描述是否太快指定了解決方案

3. 挖掘隱藏的前提,了解問題形成的原因,發現沒有說出來的限制

以上三個關於定義問題的小技巧,分享給你,希望能讓你有所收獲。

by Soking

Soking

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

Read more from Soking

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

25 days ago • 1 min read

哈囉,朋友 今天想與你討論軟體產品設計時,相當重要但在工作上又幾乎未被討論的基礎元素:「資訊需求」。 ▋什麼是資訊需求呢? ▋ 我們在買早餐的時候,早餐店老闆是怎麼知道我們想買什麼呢? 我們拿到早餐要付錢的時候,又是怎麼知道要付多少呢? 早餐店老闆辛辛苦苦的忙碌之後,下午打烊收店時,又怎麼知道今天賺了多少錢呢? 這類問題都是軟體擅長解決的事情,也是我今天想與你討論的「資訊需求」這回事。 資訊需求的意思是說,當我們要完成特定的行為目的時,必須提供的情報。 早餐店老闆需要先提供「菜單」的情報,消費者才知道有哪些選擇。 消費者要告知「點餐內容」的情報,早餐店老闆才知道要如何吩咐其他人料理。 根據點餐內容,早餐店老闆經過計算,才能告訴消費者「結帳金額」。 辛苦忙碌一整天之後,早餐店老闆統計今天所有「訂單內容的結帳金額」,才能得知「營業額」的狀況。 ▋資訊需求的兩種類型 ▋ 資訊需求在軟體服務的情境中,有兩種類型:內容即目的、產生新資訊。 想像我們要將早餐店的服務情境打造成一個軟體服務,就像你在麥當勞看到的自助點餐機。 內容即目的的情境有:...

about 1 month ago • 1 min read

哈囉,朋友 最近我在一些社群潛水的過程,發現許多人想知道如何了解自己的目標受眾。 例如想成為講師的人,希望知道該如何了解學生,才能掌握日後開課的方向。 或者持續在網路上創作的人,希望知道該如何了解讀者。 當然也有累積了多年實戰經驗的專家,想發展自己的專業服務等等。 我想根據「認知程度深淺」作為光譜,跟你分享如何認識目標受眾的切入點。 ▋專業玩家的身分認同 ▋ 認知程度深的族群,通常代表已在特定領域發展一段時間。 可能擁有某種技術,像是掌握程式開發能力、掌握烘焙技術、擅長廣告投放等。 或者接受過特定領域的專業培訓,如健身教練、芳療師、營養師等。 通常具備標籤鮮明的身分,能夠作為一種明確的自我認同。 例如衝浪玩家、手作愛好者、露營玩家等等。 認知程度深又具備身分認同,代表他們已經養成某種習慣。 這類族群有以下特色: 通常很善於辨認產品服務的優缺點 很熟悉相關的解決方案,反應問題時較犀利 只要獲得族群內的領頭羊認可,相當於拿到通行證,一路開綠燈 有明確身分標籤的人群,長年投入該主題領域,多半已經踩過大大小小的雷。...

about 1 month ago • 1 min read
Share this post