用戶體驗設計師&用研 有效求職法 (Interview Tips for UX Designer and User Researcher)

面試了許多世界500強, 1000強的企業。這兩年我的面試結果都不錯, 因此我開始回想自己到底是如何達到一定的面試水平, 換句話說, 我做對了什麼?做錯了什麼?有哪些是運氣?這篇文章想跟大家分享我的面試啟示

職務內容要求不是最重要的

在研究所最後一個學期, 每天瘋狂的找工作, 填申請表填到手軟, 然而, 如何確定找到適合自己的職位卻是個問題。在兩年前, “用戶研究員, 或是”用戶體驗設計師“的詞彙都還很新, 在職缺名稱上面找不到相對應的詞彙, 或者, 有些職務內容跟職務名稱不符合。所以如果慢慢細看職務內容, 是一件很花時間的事。為了促進找工作的效率, 我後來根本不看職務內容, 從職務名稱上就能推敲出一間公司對於該職務的理解。例如. 如果一間公司要找”ui experience designer”, 這不是業界對於ui 或ux 的慣用法, 可見這間公司可能對軟件開發和分工不是很熟悉。公司要找人才的時候, 至少要用對名稱, 才能找到對的人。之後為節省時間, 只要職缺名稱符合”正確關鍵字“, 例如, “user experience”, “user researcher”, 我就會馬上申請, 不會花時間去閱讀職務描述。等到有第一關面試通知的時候, 才會回頭細看職務內容, 因為可能跟面試問題有關聯。

職務年資要求是可以忽視的

不需要因為你只有2年年資就不敢去應徵資深的職位, 時間不代表能力。只要自己的履歷能引起面試官的興趣, 他就會想和你聊聊, 那機會就來了。我曾經在年資很輕的情況下, 得到資深階級的職缺, 這代表面試官認為我合乎資格。年資代表一定的經驗跟能力, 但是沒有年資不代表沒有能力。因此, 並要不自量力的申請總監級別的職缺, 但是絕對不要放棄可以再爬上去一點的機會。

編織自己的故事

曾經會試圖用對於公司的理解讓面試官印象深刻, 但是這兩年我不再研究面試公司, 只會在面試前一天上網搜尋公司大概介紹, 寧願把時間花在如何描述自己的經歷上。把自身的經歷編織成故事無比重要。通常我會把曾經有的工作經歷轉化成讓面試官容易了解我的小故事, 目的是突顯我的價值。故事架構遵循著固定的結構:專案背景介紹: 我的角色, 遇到了何種挑戰, 我帶出了什麼影響, 學到了什麼。 這個故事架構能以最快速的方法讓別人知道我會什麼, 是什麼樣的人, 在團隊中扮演什麼角色。 我會準備至少3個專案的小故事, 每個故事中, 我都發揮了不同的能力。我會詢問面試官對那一類的專案比較有興趣, 方便我挑選要講說的專案。

弱化缺點, 強化優點

面試的時候, 有時會被詢問不知所措的問題, 此時通常無法給面試官完整的回答。當遇到完全不會的答案, 我認為應該直接承認自己還沒有經驗, 不要隨便編造錯誤的答案, 並且跟面試官說願意學習。當遇到把握不大問題時, 即便無法說出正確答案, 但是應該迅速給出面試官相關的專業知識或經驗. 這樣, 即使沒有直接回答問題本身, 仍然能讓人感覺你的專業度。回答問題的時候, 盡量帶出自己的優點和能力, 不要一直講團隊的能力或專案的內容, 應該強調自己角色上的重要性。

自信練習

自信是一種從容, 令人舒適放鬆的感受。當面試者散發出不緊張, 從容不迫的氣場時, 會使人感到能夠放心把職位給他。因此在面試的時候, 應適度展示自己的自信, 卻不能讓人覺得太過高傲或剁剁逼人。建立自信的方式有很多種, 事前練習面試問題, 演練可能被問到的答案, 將自己的專案故事倒背如流, 這些都是能夠建立自信的方法。講述當下, 跟面試官有眼神接觸能令人感到真誠大方, 語氣應盡量避免猶豫, 用直接堅定的態度回答問題。

在經過多次面試經驗後, 慢慢地, 你將越來越了解怎麼在面試官前呈現自己, 突顯自己。最後, 面試對你來說將是小菜一碟, 甚至不需要準備。希望你我, 都找到令自己快樂又能祝福他人的工作!

:) 

在別人的故事裡, 游泳 (Stories about user research)

深夜, 睡不著的時候, 想起了什麼; 和朋友談話的席間, 記憶裡浮現一個人 ; 地鐵上手裡端著咖啡發呆, 他的影子輕輕浮現。你, 是否曾經因為聽了太多故事, 輾轉難眠?以為自己已經忘記的時候, 故事裡的主角突然對你說話?面對無法克服的困難時, 想起某個朋友的表情身影?

如果有人問我, 做用戶體驗研究是什麼滋味?我會回答:在別人的故事裡, 游泳。

1

“水, 像一張毯子. 黑, 誘人, 又冷。”― Shannon Celebi

護士替我推開門, 我和組員進了病房, 在角落等著男孩吃藥。確切是吃藥或是打針還是做其他什麼事, 我已經記不清,然而等待的過程, 不禁讓人有點緊張。我們為這項專案準備了30分鐘的概念測試, 要進行十幾個問題, 並做記錄, 男孩的親友將會在旁看著我們。他看起來不如想像中的虛弱, 而是很高壯的一位黑人男孩, 我用帶著瑕疵的英文和他對談, 過程並不順暢。好幾次他似乎聽不清我的問題, 或是要我重複問題。我為了讓他明確理解, 花了更多時間去解釋想說的, 而他也花更多力氣去聽。這一切讓彼此都有些喪氣, 頹喪,失望的感覺在空氣中漂浮著, 悲哀是透明的, 深藏不露。他和我, 我們仍然努力著, 雖然沒有握著他的手, 但我知道這一刻, 我們彼此連結。其實所得到的答案對整個專案助益並不大. 因為男孩太虛弱, 他的回答都很簡短, 而且太過於正向性,明顯是帶有偏見的回答。他的聲音一次比一次衰弱, 好像人形和靈魂一起縮小了, 我突然非常害怕他會消失在我眼前, 因為我抓不住他。我們沒有結束所有的問題就離開病房, 他在我心底卻從未消失。

我覺得很歉疚, 為了測試一個新開發的app功能向他要生命中的一小時, 明明知道他沒有力氣, 卻要他說話, 看他努力微笑。”我只是在做我的工作。“我在心底為自己辯護著。的確, 這個項目是一個為幫助青少年癌症病患者開發的app, 如果成功, 不僅算是醫療服務的創新, 也能夠幫助為數不少的病患。但這是否給我(一位陌生人)足夠的理由, 闖入一個面臨生死邊緣的男孩的世界?我感到驚嚇,  被他懨懨一習卻努力的表情嚇壞, 也因著病房中悲哀的氣息而感到不自在。也許我, 才是弱小的那一位,持有和他對談的特權卻不夠勇往直前。在我決定投入用戶研究時, 從沒有想過自己將坐在病房這一頭。第一堂課上, 我去了芝加哥的千禧公園觀察人的行為,世界明亮美好。但病房裡寒氣襲人, 沒有足夠的溫度就跳入湖水會把人凍傷, 那種刺骨讓人心瘁, 但是你還是要跳啊!因為你已經在那裡, 因為他在等你為他發聲。

2

”漂浮在無地心引力的空無上, 我找到船緣。聽著自己的呼吸。周身非常黑暗, 我沒有重量, 我得找尋身旁的氣泡才能確定海水的起伏。我倒著游離船邊一些, 向外面游去, 藉著海水揮舞著我的雙臂。磷光追溯我的足跡如同流星的尾巴。我讓自己的身子倒過來浮著,看著水下溫柔的暴風雪舞動, 這個一直奇異存在的水底世界。“― Elisabeth Eaves

電話那端的人問我, “你有沒有看過我們的產品呢?”“有的”我回答。“你覺得怎麼樣呢?”對方問。“這個產品幫助祖孫兩代一起同樂, 我覺得很有潛力, 但是我認為我們必須突出這個產品與眾不同的地方, 現在看來市面上有許多競爭對手都有相似的功能。”我忍住沒有說出口的是, 我實在不看好這個產品呀!但是誰能在面試時說出這種話呢?我得到了工作, 即將負責一個app的全部用戶體驗和用戶研究, 好險當初沒有說實話。捫心自問, 我實在對這個產品沒有任何感覺。我跟爺爺奶奶的關係是非常疏遠的, 每次見面時, 總覺得他們就像兩株植物一樣安靜地走路, 吃飯, 不多話。我從來沒有感覺需要他們的疼愛, 也實在沒有話跟他們說, 偶爾的探望如同按時給他們澆水。也許就是這樣, 這款app, 一個讓祖父母和孫子一起在線上玩遊戲, 閱讀的平台才難以打動我吧!勉強自己愛上這個app的情況持續了好一陣子,我覺得它既醜, 又難用, 我的負面態度一直持續到做完第一輪產品易用性測試。”怎麼可能幾乎100%的用戶都極度願意把這個app推薦給親友?而且用戶還是在易用性中低的情況下表示產品極有吸引力!” 我們找了已經有孫子孫女的爺爺奶奶來使用我們的app, 結果出乎我意料的好, 只有一位用戶表示不想使用此app。

測試實驗室像一個詭異的基地。研究員將用戶測試的房間偽裝成舒適的客廳, 有沙發, 花, 木桌子, 等等讓人放鬆的擺設,其實卻在好幾個角落暗藏了攝影機。另一個我坐的房間裡, 四面都是大螢幕。一面播放著用戶的臉部表情, 一面播放用戶手跟螢幕互動的樣子, 另一面可以看到用戶全身。爺爺奶奶的身影在我眼前放大, 一張張充滿皺紋的臉部特寫, 還有老人才有的獨特嗓音, 暖暖地, 一點點站滿了我的思緒。皺紋的臉本身有種讓人平靜的特質, 我凝視著他們, 他們卻看不見我, 好像在平行時空裡, 我站在時間的對面, 緩慢的將心游向彼方。一場場的對談互動, 向我透露著內心的獨白,好像看電影一樣, 卻是真人實境演出, 我坐在40-50個易用性測試的訪談中, 最後已經能將爺爺奶奶們的回答倒背如流。

“我喜歡跟我的孫子有真正的互動。”

“我喜歡說故事給我的孫女聽。”

“有時候也不知道要說什麼, 但是這些遊戲讓我們兩個都玩得很開心, 可以有話題, 聊更多。”

”我現在有癌症, 如果孫子的父母不讓我跟他們用這個app, 我就用我的癌症威脅他們!“

”我覺得這個產品很棒。我有三個孫子孫女在肯亞, 我們很少見面, 我一定會跟他們一起試用這個app。“

原來我從來, 從來沒有以這群爺爺奶奶的角度想事情, 替他們解決問題。更把許多刻板印象釘在他們身上。好像你經歷過一些事情後, 那些事情會改變你一樣, 在近50個用戶測試後, 我突然打從內心深處生出一種使命感, 覺得自己有責任去改變什麼, 因為 “這個產品可以帶給一群人快樂。”

後來, 老闆給我很大的壓力, 一度面臨如果沒有達到業績, 就要將這個app砍掉的危機。在那段時期, 我只要閉上眼睛, 就可以看見這些爺爺奶奶們的臉, 可以聽見他們說的話。那種狀態幾乎是非自願的, 他們的皺紋已經深深烙印在我內心, 我逃不走, 不得不凝視著他們。

3

”她帶著勇氣和無視旁人態度成長, 高估自己的力量。她想游得更遠, 游到沒有人游過的地方。“― Kate Chopin

那些聲音不太有自信, 幾乎是鱉腳地向我做解釋, 又像用平靜的音調來抑制自己的驕傲一般, 這讓我更好奇地想認識他們。幾乎所有我訪問過的極限運動者, 都給我同一種感覺:在把自己鍛鍊到最強的同時, 他們都有一個最脆弱的秘密。也許在一小時的談話中, 他們在語句的空隙裡, 不知不覺地向你透露了一點點這個秘密的開頭, 然而又馬上把門關閉, 你只能臆測, 因為強迫他人分享秘密是無益的。

他說曾經跑到最後鞋都破了, 腳上都是血, 只能走到終點。他告訴我他決定在澳洲赤腳行走230公里, 打破世界紀錄。他想要引人注意登上頭版, 因此他拖著14公斤的輪胎跑完整場馬拉松。他每天跑, 早上一次, 晚上一次當作練習。這些話觸動了我, 我不是一位跑者, 也並沒有因此開始跑步, 但是我記住了他說的話。他如同向我開啟一扇門, 好像告訴我路的終點在哪裡, 叫我明白盡頭的孤獨。也讓我了解, 如果有一天, 決定踏上和他相似的路, 也許不是跑步, 可能是極致的做其他事情, 我不是孤身一人。因此, 我一直關注著他的世界,  以一種仰望的姿態, 又以無法理解的態度去猜測他的行徑, 然後逐漸接受這個世界的形形色色。他說他為自己形塑出一個街頭混混的傳奇故事, 這個混混因著跑步而改變了一生。我問他 ”你編造的這個角色, 和真實生活中的你差距多少?“他吱吱嗚嗚的避而不答, 如同以往保持神秘。他既高調又卑微, 不只要你看到媒體前的他, 還要你看見他腳上的傷與血, 不得不正視他的行為, 不得不對他進行評論。“他到底是個瘋子還是超人?” 

“每個人都有一點太陽和月亮。每個人都有一點男人, 女人和動物。黑暗和光明。每個人都屬於互相連結的宇宙系統。有著土地和海洋, 風和火, 有著鹽和塵埃在他們裡面游泳。我們內在都有一個宇宙, 模仿著外在的宇宙。沒有一個人是黑或白, 總是錯的或總是對的。沒有一個。沒有一個人存在於兩極以外。每個人都有善與惡之力在他裡面互斥互生。 (Suzy Kassem)“ 如果每個人都屬於互相連結的宇宙, 那在一小時的對話中, 他彷彿將自己的一點點的能量傳給了我。

UX Practice - Multi-Factor Authentication for Bank Mobile App

I enjoy solving problems in different areas by user experience design. Bank security is an important issue in today's world, everyone values security when it comes to finance. How can I design something that ensure user information privacy, facilitate easiness of use and efficiency? Here is a practice of Multi-Factor Authentication for Bank Mobile App.

 

 

Take a closer look about the wireframe flow: (click on the images to view the details)

 
 

Thank you!

用戶訪談初學者常犯的3個錯誤(Beginners' three mistakes in a user interview)

no 1 : 要求用戶回憶曾經發生的事, 並回答確切的數字和答案

身為研究員, 常常面對其他團隊的壓力, 需要得到精確的用戶資訊. 例如, 研發團隊想知道用戶從得到產品後, 使用了幾次主要功能。剛入行的研究員可能因此就直接把這個目的轉化成問題” 請問你用了幾次X功能呢?“ 用戶想了一想, 回答:“5次吧.” 結果研發團隊想當然得認為這個用戶用了5次某功能。以上的敘述乍聽之下好像很合理。實際上, 這透露出了初學的研究員常犯的兩個錯誤:

  

  1. 以直化研究來解決量化研究才能夠回答的問題, : 少數用戶的量化資訊並不能幫助研發團隊解決問題, 因為直化的訪談研究大部分只介於5-20人之間, 如果產品的用戶人數是一萬人, 那麼只去了解20人的量化行為並不具代表性。應該用量化的研究方式來蒐集數據。
  2. 忽略了人的本性是”健忘“。在訪談中要求用戶回憶曾經發生的事晴時, 研究員必須做好準備, 知道用戶必然”不小心地“對你說了謊。這不代表用戶故意浪費你的時間, 而是人沒有辦法準確記住曾經發生的事。因此建議如果研究員要求用戶描述一段回憶, 應把研究目標設立在”了解用戶對於事件的態度, 情緒及認知上”, 不要將目標設計在了解用戶真正的行為細節。如果研究員想要客觀了解的用戶行為, 最準確的方法是透過從旁觀察以及量化數據。

no 2 : 強迫用戶回答 ”為什麼“

  1. 用戶:“我第一直覺會按這個按鈕”. 訪談者問:“為什麼?” 用戶:”...就是感覺“ 訪談者問:“為什麼會這樣感覺?用戶:”...不知道“ 
  2. 用戶:“我早上起床時總是想不起來做了什麼夢.“ 訪談者問:“為什麼?” 用戶:(沈默很久)”...不知道.“ 

這些用戶的反應是否曾經出現在你的訪談對話裡?用戶是否常常以”不知道“回應你?如果有, 代表你可能問錯了問題。 ”為什麼“是用戶研究員常常問用戶的問題. 這個問題本身沒有錯, 因為如果只問了用戶問題, 而沒有問背後的原因, 對議題的態度, 那麼研究員只能得到片面的答案, 而沒有辦法給予解釋。例如:研究員問:”最營養的早餐對你來說什麼?“ 用戶答:”稀飯吧。再加顆蛋還有肉鬆“ 如果研究員停止在這裡, 那麼他就沒辦法得知為什麼稀飯會出現在用戶的腦海中, 用戶對稀飯的營養判斷是從何而來的。以上種種, 說明問”為什麼“ 的確很重要,但是有時候研究員卻在用戶回答不出”為什麼“的時候, 一定要用戶作答。這不僅危害了研究結果, 也說明研究員在現場沒有足夠觀察或經驗去判斷如何問”有效的問題“。另外, 你也會發現, 以”為什麼“來追問, 有時候導致用戶不停重複剛說過答案, 卻沒有得到新的資訊。

 

如何判斷用戶的態度:

  1. 觀察用戶肢體語言, 判斷用戶是否經過思考才回答”不知道!“:在例子1當中, 用戶在回答第一個問題的時候說”...就是感覺.“ 這時候訪談者應該知道用戶無法確切描述理由, 也許這個用戶比較不善表達, 但是就算是口條清晰, 滔滔不絕的用戶也有回答不出來的時候. 最簡單的判斷方法是觀察用戶的表情肢體動作, 如果用戶明顯已經經過思考, 仍然無法回答問題時, 他也許真的答不出來。 
  2. 只想拿錢走人的用戶:凡事都有例外, 有些用戶因為受訪有酬勞, 是為了想賺錢才來受訪, 那麼可能目的只是想要拿到酬勞, 而不願意對研究做貢獻. 你會發現這類用戶很容易就放棄回答問題, 或是答案沒有邏輯性. 似乎連問題都沒有搞清楚就回答了. 

為什麼強迫用戶回答會危害研究結果?答案很簡單, 許多時候如果研究員對用戶施壓, 讓用戶覺得他非得說話, 甚至說一些無意義的話也行, 那麼用戶便會胡亂回答.

如何問有效的問題?在第一個例子中, 研究員發現用戶答不出來時, 應該能用其他問題來得到資訊. 例如, 如果想要知道為什麼用戶沒有案另一個按鈕, 而按了跟預期不一樣的按鈕, 可以問:”那剛剛有注意到旁邊這個按鈕嗎?“ 用戶可能回答:”沒有耶, 第一眼只看到中間的按鈕.“ 以此研究員就能得到按鈕的的位置會影響用戶的使用直覺性.

no 3 : 沒有驗證用戶所說的話

有些用戶研究員把用戶說的話當成唯一, 沒有經過自己的消化思考就接受用戶說的每句話, 會使研究數據缺少可信度。剛剛說過了, 訪談時用戶的回答, 常常是反映一種態度, 態度跟事實總有一些差距。用戶研究員需將兩者區分, 才能以客觀的角度看待得到的資訊。

如何驗證用戶說的話呢?

  1. 問一個“上一次”的問題:用戶說:“我每個月都在網路買很多書。” 研究員問:“那你上一次購物買了什麼?”用戶答:“恩...上次在xxx買了一兩本, 因為xxx。” 詢問用戶關於“上一次發生”的經驗, 能夠幫助研究員驗證用戶的真實經驗。“上一次”的提問法, 雖然也是要用戶回憶事件, 但是它將用戶思考限定在一個確切的時間概念中, 並且提供研究員一個例子(上次在x因為x買了一本書), 而不是一個宣言(我買很多書)。  因此, 使用“上一次”提問法, 能提供研究員有效的資訊。
  2.  請用戶演示給研究員看:“說得容易, 做起來難”這話表明了, ”說“跟”做“ 其中總有差異。如果你問一個舞者如何跳舞, 得到的答案可能永遠不比請他跳一支舞給你看。用戶研究員如果想要得到“用戶場景”的全面了解, 最快的方法就是請用戶既說也做。例如, 想要知道媽媽如何準備一份便當, 不如請媽媽當著研究員的面做一份便當。研究員不只能了解便當準備過程的長度, 食物選擇的方式, 還有工具, 容器等等全面的資訊。

 

Quotes from "Handbook Usability Test"

In large part, what makes something usable is the absence of frustration in using it. As we lay out the process and method for conducting usability testing in this book, we will rely on this definition of ‘‘usability;’’ when a product or service is truly usable, the user can do what he or she wants to do the way he or she expects to be able to do it, without hindrance, hesitation, or questions. (p.4)

To be usable, a product or service should be useful, efficient, effective, satisfying, learnable, and accessible. (p.4)

Most usability professionals spend most of their time working on eliminating design problems, trying to minimize frustration for users. This is a laudable goal! But know that it is a difficult one to attain for every user of your product. And it affects only a small part of the user’s experience of accomplishing a goal.  (p.6)

Five Reasons Why Products Are Hard to Use (p.6)

1. Development focuses on the machine or system.

2. Target audiences change and adapt.

3. Designing usable products is difficult.

4. Team specialists don’t always work in integrated ways. 

5. Design and implementation don’t always match. 

The International Organization for Standardization (ISO) in standard 13407 says that UCD is ‘‘characterized by: the active involvement of users and a clear understanding of user and task requirements; an appropriate allocation of function between users and technology; the iteration of design solutions; multidisciplinary design.’’ (p.13)

(Usability Test)The intent is to ensure the creation of products that: (p.22)

1.Are useful to and valued by the target audience
2.Are easy to learn
3.Help people be effective and efficient at what they want to do Are satisfying (and possibly even delightful) to use

An important aspect of surveys is that their language must be crystal clear and understood in the same way by all readers, a task impossible to perform without multiple tested iterations and adequate preparation time. Again, asking people about what they do or have done is no substitute for observing them do it in a usability test. (p.18)

Usability testing is most powerful and most effective when implemented as part of an iterative product development process. That is, a cycle of design, test and measure, and redesign throughout the product development lifecycle has the greatest probability of concluding with a usable product. Even if important product flaws or deficiencies are missed during one test, another testing cycle offers the opportunity to identify these problems or issues. (p.28)

We feel very strongly that such an approach provides the value when resources are limited, and that one will obtain the best results by conducting a series of short, precise tests that build one upon the other. (p.28)

 

Exploratory or Formative Study (p.30)

Some typical user-oriented questions that an exploratory study would attempt to answer might include the following:

What do users conceive and think about using the product?

Does the product’s basic functionality have value to the user?

How easily and successfully can users navigate?

How easily do users make inferences about how to use this user inter- face, based on their previous experience?

What type of prerequisite information does a person need to use the product?

Which functions of the product are ‘‘walk up and use’’ and which will probably require either help or written documentation?

How should the table of contents be organized to accommodate both novice and experienced users? 

 

Assessment or Summative Test (p.35)

The user will always perform tasks rather than simply walking through and commenting upon screens, pages, and so on.

The test moderator will lessen his or her interaction with the participant because there is less emphasis on thought processes and more on actual behaviors.

Quantitative measures will be collected

 

Verification or Validation Test (p.36)

It only makes sense then that the validation test itself can be used to initiate standards within the company for future products. Verification can accomplish the same thing. For example, if one establishes that a setup procedure for a software package works well and can be conducted within 5 minutes with no more than one error, it is important that future releases of the product perform to that standard or better. Products can then be designed with this benchmark as a target, so that usability does not degrade as more functions are added to future releases. 

Still another objective of the validation test, or really any test conducted very late in the development cycle, has become known in the trade as ‘‘disaster or catastrophe insurance.’’ At this late stage, management is most concerned with the risk of placing into the marketplace a new product that contains major flaws or that might require recall. If such a flaw is discovered, slipping the schedule may be preferable to recalling the product or having to send out ‘‘fixes’’ to every user.  

 

Because you are measuring user performance against a standard, you also need to determine beforehand how adherence to the standard will be measured, and what actions will be taken if the product does not meet its standards.   (p.37)

 

Quotes from "The Innovator's Dilemma"

  • Organizations capabilities reside in their processes and their values -  and the very processes and values that constitute their core capabilities within the current business model also define their disabilities when confronted with disruption.
  • The ultimate users or applications for disruptive technologies are unknowable in advance. Failures in an intrinsic step toward success.
  • Good resource allocation processes are designed to weed out proposals that customers don't want. When these decision-making processes work well, if customers don't want a product, it won't get funded; if they do want it, it will. This is how things must work a great companies. They must invest in things customers want - and the better they become at doing this, the more successful they will be.
  • Typically, senior managers are asked to decide whether to fund a project only after many others at lower levels in the organization have already decided which types of project proposals they want to package and send on to senior management for approval and which they don't think are worth the effort. Senior managers typically see only a well-screen subset of the innovative ideas generated.