<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:cc="http://cyber.law.harvard.edu/rss/creativeCommonsRssModule.html">
    <channel>
        <title><![CDATA[MZ-UXUI - Medium]]></title>
        <description><![CDATA[MZ UXUI Digital - Medium]]></description>
        <link>https://medium.com/mz-uxui?source=rss----6b297ffa0342---4</link>
        <image>
            <url>https://cdn-images-1.medium.com/proxy/1*TGH72Nnw24QL3iV9IOm4VA.png</url>
            <title>MZ-UXUI - Medium</title>
            <link>https://medium.com/mz-uxui?source=rss----6b297ffa0342---4</link>
        </image>
        <generator>Medium</generator>
        <lastBuildDate>Tue, 19 May 2026 04:00:28 GMT</lastBuildDate>
        <atom:link href="https://medium.com/feed/mz-uxui" rel="self" type="application/rss+xml"/>
        <webMaster><![CDATA[yourfriends@medium.com]]></webMaster>
        <atom:link href="http://medium.superfeedr.com" rel="hub"/>
        <item>
            <title><![CDATA[給 UX 設計師的訪談實戰 12 招（下）]]></title>
            <link>https://medium.com/mz-uxui/12ways-to-improve-ux-designers-user-interview-skills-vol2-f58f70af780e?source=rss----6b297ffa0342---4</link>
            <guid isPermaLink="false">https://medium.com/p/f58f70af780e</guid>
            <category><![CDATA[user-interviews]]></category>
            <category><![CDATA[ux-design]]></category>
            <category><![CDATA[product-design]]></category>
            <category><![CDATA[ux]]></category>
            <category><![CDATA[ux-research]]></category>
            <dc:creator><![CDATA[Zac, Tong-Yueh Yang]]></dc:creator>
            <pubDate>Wed, 19 Apr 2017 07:43:42 GMT</pubDate>
            <atom:updated>2017-04-19T07:46:42.170Z</atom:updated>
            <content:encoded><![CDATA[<h4>讓我從零開始，急速貼近用戶想法的 3 原則＋ 12 招</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*83B7sKZE6SNeYKjUDwTXXw.jpeg" /><figcaption>Image Curtesy: Unsplash.com</figcaption></figure><p>在上集我們談到訪談的目的、原則，還有<strong>如何提高資訊採收量</strong>的訣竅。需要回顧的朋友由此入。</p><p><a href="https://medium.com/mz-uxui/12ways-to-improve-ux-designers-user-interview-skills-vol1-82829a2087a0">給 UX 設計師的訪談實戰 12 招（上）</a></p><p>好，正文馬上開始！</p><blockquote>這一切的忙碌，都是為了打包現實回到會議室</blockquote><h3>如何提高採收的資訊價值？</h3><h4>第 8 招，利害關係試金石</h4><p>如果訪談的目的是理解用戶對產品或服務（尤其是市面還沒有的）的評論，我們就擺明跟人類規避社會衝突的慣性在對抗，負面的評論會被中性化才表達，中性的觀點會被歸為有趣新奇。有實作過 Customer Development 或 Market Validation 的人，都必須接種預防的疫苗。<em>「噢，這好酷。我喜歡！」＝ 這一題沒搞頭了，下一題！</em></p><p>身為研究員的我們，是也不用為了敬業而變成疑心病重的混蛋。面對湧來的稱讚，我們只需適時要求用戶承擔利害關係，來判斷他們的稱讚是否出於禮貌或廉價。<strong>利害關係表現的型態有三種：時間、名聲、金錢</strong>，讓我解釋如下：</p><ol><li>要求付出<strong>時間</strong>，代價最低<br>例如：「那你願意來參加下一堂 30 分鐘的課程試聽嗎？」、「接下來的兩週，我們每天能跟你電話訪問 15 分鐘嗎？」</li><li>要求付出<strong>名聲</strong>，代價中等<br>例如：「願意現在幫我們推薦三位有同樣需求的朋友來做訪談嗎？」、「願意現在幫我們在臉書標注一個朋友推一則短文嗎？」</li><li>要求付出<strong>金錢</strong>，來真的<br>例如：「願意現在就以早鳥優惠價購買嗎？」（拿出 iPad 秀結帳頁面，甜笑貌）</li></ol><p>這種試金石的招式有它的風險，被拒絕時可轉往代價低的招式來要求，也要準備好被完封的說詞，讓雙方有個台階下（菸）。（至於訪談紀錄中所有正面的評價，都請直接灰掉吧）</p><h4>第 9 招，底牌要忍到最後</h4><p>在上一個訣竅中我解釋了如何驗證來自用戶的評價，事實上，在任何 Market Validation 之前的訪談，都應該要極力避免談論到我們的解決方案。直接跳到對產品的想法，會讓用戶進入建議與發想的模式，情報的價值頓時降至人人皆專家的品質。</p><p>如何能確認我們的心血真有解決用戶問題，同時又絕口不提產品呢？</p><p>主訪人可以主攻用戶過去切確的使用障礙、詢問目前的妥協解法、妥協的成本，與忍耐的極限。接著是發掘可能的替代方案、用戶選擇比較的考量，與遲遲不轉換的原因。當我們能有信心判定，用戶對痛點的認識與解法的期待有符合設定的條件時，才能夠用試探性的問題來測試我們的方案。即便如此，也應該規避產品提案的情境，我們需要使用中性的字眼來描述一個抽象的產品概念。</p><p>簡單來說，我們需要<strong>聚焦在明確的歷史事件，並對用戶當下與未來的想法存疑</strong>。</p><p>執行 UX 的質化研究，難免要在產品入市前作風險較低的驗證或探索，但我們總能練習把底牌忍到晚一些才翻開。</p><h4>第 10 招，有不理性才合理</h4><p>如果人都是理性的，根本不需要做訪談，只要夠聰明的人都能獨自推演出正確的劇本。知名的 “5 Whys” 提問方式教我們要連續問五個為什麼，來打破沙鍋窮追根本的動機。方法論看來科學理性，卻沒人告訴我們，第五個回答很可能是全然的感性，是個兒時回憶、自我認同的投射，或是隨機養成的習慣。事實上，我反而期待這種發現，這讓我們比其他不做功課的團隊，多了一分競爭優勢。</p><p>在訪談中要追尋理性相對於感性的比例，我沒有完美的答案。但如果能從找到<strong> 10% 的感性癥結去完美支撐往後 90% 的理性決策</strong>，這整個案例我會給予高度的重視。市場行銷這整門專業，幾乎建構在人對購買決策的不理性，為市場研發產品的我們，當然要比照辦理！</p><p>當對話讓我們感到一切合理、可預測到令人恍神時，只要挑著用戶模糊一句帶過的點追問，或是鉅細彌遺地交代的點反問，都能提高發現不理性癥結的機會。人的大腦面對自己無法解釋的節點時，特別會抄捷徑，或是建立再合理不過的新地圖。</p><h4>第 11 招，多提防記憶弱點</h4><p>有時訪談的目的，是要取得產品與其他解決方案之間，重要的比較基準（Benchmark）。這通常會轉化成：<strong>耗時</strong>、<strong>金額</strong>，或<strong>步驟順序</strong>這類資訊。我的經驗是這三種資訊可以記得很清楚的人很少，遇到交代地明確無比的用戶，請回顧上一個訣竅。</p><p>第一次的回答都該假設為粗估，我們需要透過不同案例、不同角度來探問。如果探問的結果與先前有明顯比例不符，我們就需要調整我們心中的估算。令人困擾的是，如果詢問多次，用戶會建立一個比例原則的模型，往後的回答都會因為不想自相矛盾而扭曲事實。</p><p>我曾在工作坊被講師扎扎實實地玩弄了一次。我首先被要求回答我<strong>印象中</strong>打掃<strong>一般</strong>會花多少時間，接著回答我有<strong>明確印象</strong>的<strong>上一次</strong>打掃開始時間。講師在一陣模糊焦點之後，問我「那上一次打掃結束時間是幾點？」。然後我那不爭氣的下意識為了不違反之前回答，嘴裡<strong>精確地</strong>流出了<strong>明明沒印象</strong>的打掃結束時間。（就這麼巧，剛剛好符合我先前估算的總耗時！）登愣！講師笑畢後我就成為當天教學案例。</p><p>正因為 Benchmark 對於設計（商業）決策的重要性，我們在面對人腦弱點時，更要小心處理！</p><h4>第 12 招，凱旋歸來有門道</h4><p>同事們成天在 Sketch、IDE、GitHub，還有雲端共筆裡打轉，如果期待他們看到勤跑外場的我們會列隊歡迎，是很不切實際的！業主花了錢委外 UX 研究的服務，他們也不會有興致聽我們分享曲折離奇的花絮。「Deliverable 呢？」（敲碗）</p><p>我必須承認，訪談報告的產出，遠比訪談當下還燒腦 10 倍。世界上很少有比重複聽兩小時自己與他人的對話還要無聊的事情。不要以為送去聽打會拯救我們，因為要做成對團隊成員或業主能消化應用的格式，得做一次濃縮版的紀實。這會是我們首次用自己的主觀來粗篩這龐大的資訊（噪音居多）。建議不能等超過三天才做，屆時對腦力考驗更大。如果組織內有多組訪談人員，交換各自手上的原始資料來做濃縮，可以減少主訪人主觀的影響。</p><p>各家的報告內含資訊不同，我只任性地放濃縮版的紀實、經典語錄、報表圖表（如果統計受訪者的資料能做 Data Visualization 的話）等訪談事實，在值得關注的段落標示起來，最後加上簡短幾點主觀解讀與高報酬機會點。相信我，即便如此，對於明明渴求用戶實情的設計開發同仁，這樣的資訊量還是遠超過他們能對付的程度。</p><p>最後的提點：誰說我們對外部用戶的發揮技巧，不能在自己人身上產生好效果？反過來對團隊同仁做訪談，都是很愉悅的議程，「這已經是第五個用戶有這樣的行為模式，大家怎麼看？」、「上次會議僵了三小時，這次特地挖的癥結點能怎麼運用呢？」。獵取情報的人，一切忙碌不就為了這個嗎？（拍拍）</p><h3>後記</h3><p>斷斷續續寫了不少心得，都是來自於過去十多個月的試誤經驗累積，不敢自稱對方法理論暸解透徹，也不敢冒用原屬於講師與其他高手的獨創概念。有任何需要增補改正之處，也請多指教。</p><p>文末，我想跟大家分享勤做訪談對於人生的美好副作用：</p><ol><li><strong>交新朋友<br></strong>捫心自問，我們跟密友或家人，上次在沒有手機干擾的情況下，認真傾聽、挖掘心事足足兩小時是什麼時候？訪後的對象，常常會給我穿越劇的錯覺，似乎已經認識很久了。用戶也是，直到訪後的時間慢慢沖刷掉這種錯覺。但可以是朋友無誤（打勾）。</li><li><strong>跨界專家<br></strong>因為提問的臉皮跟技巧的提升，我們會建立一個人肉機器學習模式。把這技巧用在產品主身上，會在兩小時會議後，有機會解開「我覺得你比我們家 PM 還懂我們的產品跟市場」的成就。</li><li><strong>認識人性<br></strong>不同思路背景的人聊多了。我開始用更寬容的角度看待周遭的不合理。用戶來來去去，大家用不同理念過得好好的，我真的也不必堅持什麼了。</li></ol><p>打完收工，祝大家出訪滿載，凱旋歸來！</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=f58f70af780e" width="1" height="1" alt=""><hr><p><a href="https://medium.com/mz-uxui/12ways-to-improve-ux-designers-user-interview-skills-vol2-f58f70af780e">給 UX 設計師的訪談實戰 12 招（下）</a> was originally published in <a href="https://medium.com/mz-uxui">MZ-UXUI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[給 UX 設計師的訪談實戰 12 招（上）]]></title>
            <link>https://medium.com/mz-uxui/12ways-to-improve-ux-designers-user-interview-skills-vol1-82829a2087a0?source=rss----6b297ffa0342---4</link>
            <guid isPermaLink="false">https://medium.com/p/82829a2087a0</guid>
            <category><![CDATA[product-design]]></category>
            <category><![CDATA[user-interviews]]></category>
            <category><![CDATA[ux-design]]></category>
            <category><![CDATA[ux]]></category>
            <category><![CDATA[ux-research]]></category>
            <dc:creator><![CDATA[Zac, Tong-Yueh Yang]]></dc:creator>
            <pubDate>Wed, 19 Apr 2017 07:40:23 GMT</pubDate>
            <atom:updated>2017-04-19T09:14:25.943Z</atom:updated>
            <content:encoded><![CDATA[<h4>讓我從零開始，急速貼近用戶想法的 3 原則＋ 12 招</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*CqfTg75s3Tp97liq8mer3g.jpeg" /><figcaption>Image Curtesy: Unsplash.com</figcaption></figure><blockquote><em>在跟十位目標用戶訪談之前，會議室裡不管誰說什麼都不要當真</em></blockquote><p>在數位產品設計開發領域中，用戶訪談一直都是不性感的工作項目，尤其在 Data-driven 與 Design Sprint 當道的時代。反觀在新創團隊、大企業的產品部門在做新規格的決策時，與會者還在憑自己主觀且有限的人生經驗來推演設計。坐在會議室一角的你，也許納悶過：找幾個真實用戶來聊一聊，不會瞬間貼近現實幾光年嗎？</p><p>這可不是創辦人、主管、業主口中的<em>「我跟身邊會用我們產品的朋友聊過」</em>這種一廂情願的取暖對話，而是有策略地與陌生潛在用戶做深度 拷問 對談。沒錯，沒有團隊能訪盡所有潛在用戶，一樣米也養百樣人。但社會屢見不鮮的跟風現象，也證實人類群體的行為比想像中還要一致。用戶訪談的美妙就在這：<strong>只需少數成功的訪談，就能拼湊出代表多數用戶的行為思考模式</strong>。</p><p>訪談本質上就是有目的的聊天，外向幽默、善解人意的人肯定會佔優勢。記者、田野調查員，或是情蒐檢調背景的人也會自帶該技能點數。我們設計開發產品的人，成天查規範、追技術、學工具都來不及了，哪有力氣開新技能樹！？幸好，還是有一些共通的原則與訣竅，可以幫助我們挖掘出更豐富、直指人性的用戶洞見。一則好情報，就能逆轉戰局。而 UX 研究員，就該要以情報分析員自詡！（握拳）</p><p>與用戶對話有一些經驗的人，一般會認同以下三個好原則：</p><ol><li><strong>多問少說<br></strong>俗話說：「You have two ears and one mouth, and you should use them in that proportion.」。我也曾在工作坊中聽到三分聽、一分說的建議。不管如何，用戶訪談不是產品簡報，更不是使用教學。大多數人在這一步就踏歪了，忍不住辯贏了世界，卻輸了用戶。</li><li><strong>開放問題<br></strong>封閉性的問題只會帶來是與否的二元解答，對於線索的指引價值很低。用戶訪談求的是一個具有啟發意義的故事，開放的問題能大幅提高用戶娓娓道來真實經驗的機會。多問為什麼、多請對方談談看某次經驗，能規避自導自演，也不會像是問訊般逼人。</li><li><strong>不做預設<br></strong>除非用戶的思考發散到不可收拾，或擺明對於產品價值有根本的誤解，我們該耐心地讓用戶發表他們獨特的世界觀與使用案例。訪談這種形式，有發掘驚喜彩蛋的絕對優勢。多耐著性子聽 15 分鐘，可能會迎來產品軸轉創新的關鍵。</li></ol><p>但是，魔鬼都在細節裡，有用的實務訣竅必須做中學。我整理過去訪談經驗的心得成 12 個要點如下，希望節省大家摸索的時間：</p><h3>如何提高資訊採收量？</h3><h4>第 1 招，篩選問卷別輕忽</h4><p>大型貓科動物狩獵時，會挑大獵物下手，小動物不夠彌補消耗的體力。我們在挑選訪談對象時，也該秉持同樣的嚴選原則。一般來說，在招募表格中放置篩選問題（Screening Questions），就能達到不錯的效果。設計篩選問卷本身是一個很好的團隊內同步理念的機會，它幫助我們搞清楚產品的核心命題，具象化用戶的各種表徵，出門之前就有促進整體 UX 認識的療效。</p><p>如果需要定義的用戶背景比較細緻，可以放心增加問題邏輯跟數量（很多雲端表格也支援答題邏輯的設計），不用擔心沒人來。一來是因為問題多就不想填的人，在訪談當下也會表現一樣的吝嗇寡言。二來是增加酬金誘因所花的成本，絕對低過一個正確對象的情報價值。第三，認真的篩選問題集，會吸引來認真的受訪用戶。</p><p>沒持續在做訪談的人，很難體會 UX 研究員敲到符合夢幻條件的用戶的爽感。（撒花）</p><h4>第 2 招，實戰禮數要做足</h4><p>有些訪談需要搭配用戶自己的真實操作情境，前往別人的場域時的禮節跟作業方式都需要注意。有些訪談只需要舒適安靜的咖啡廳就能處理。盡量避免使用會議室這類辦公空間，用戶越放鬆越能在有限時間內表露自己。穿著打扮樸素簡單為主，不要太休閒也不需過度正式，畢竟是陌生人首次見面，任何引發社會價值判斷的因素都盡量避免。</p><p>有時訪談是需要做錄影錄音的紀錄，需要準備好簡單的同意書給用戶先簽署（也能把酬金的簽收放在同一個表格）。如果個人肖像會需要給第三方或剪輯公播，也要記得把授權條文寫進同意書內。解釋這一份文件的過程，本身就是建立信任感的好步驟。要切記，這是陌生會面，應該要預設對方是不安的。</p><p>理想的訪談組合是二人小組，一位主訪，一位紀錄。為了不破壞對話的流動，紀錄的同仁能排除現場的各種突發狀況，同時也兼具了當場紀錄重點的任務。相信我，當我們進入真正的傾聽模式，任何筆記行為都是一種干擾，更不用說在用戶面前使用電腦這種大忌了。主訪人與受訪用戶面對面做，紀錄員低調地在用戶一旁，有經驗的助手還能幫主訪人打暗號調整節奏。</p><p>在用戶花了一段時間，不保留地跟我們交代人生之後，我們該給予真心的感謝，有禮貌地交遞酬金，並遞送筆來簽收，閑聊一下才告退。對陌生人暴露自我後，換來的是金錢跟客套，不是用戶該受到的對待。</p><h4>第 3 招，餵食誠實豆沙包</h4><p>用戶接受酬金來談自己的經驗，通常會對於自己的答題能力感到焦慮。如果因此激發他們的創造力，是我們最不想發生的事情。相反地，也會有用戶每回答幾題就問自己答的好不好。</p><p>要降低用戶的防禦心，可以再次說明命題的用意，還有這次訪談對話的話題範圍。請對方直接對太私密的問題反應，畢竟大多時候訪談是有酬金的，用戶會為了錢退讓，或是更慘，編了一個故事來圓場。</p><p>對我最受用的一點是，在感覺到用戶的焦慮時，提醒他：「<strong>你的真實經驗跟感受，才是我要的標準答案</strong>」。如果這是關於新產品的測試，我也會表明設計師跟我不是同事，我們的工作只是要帶回用戶的反應。即便這通常不是事實（而且得真心笑臉看別人當場幹樵我們的點子），為了解開真實想法的封印，說點小謊我可以。（還要記得訪後不准透露討拍，除非你想讓用戶羞得挖洞鑽）</p><h4>第 4 招，同步雙方的語言</h4><p>用戶訴說的字眼，反映的是他們對命題的認識基礎。先前有提到不要引導對話的原則，在實作上是很容易越線的，畢竟我們已經在這一題上花了多少時間，這一前提是用戶普遍沒有的。比較簡單的做法會是限制我們的專有名詞、還有形容詞。尤其是在看到明確用戶模式之前，盡量用中性與廣泛的字眼來開啟對話。</p><p>不用擔心這樣講話不會像是正常人，當我們的問得夠中性廣泛，用戶會忍不住迸出他們的版本的字眼。如此一來，我們就能在往後的訪談不停引用，隨著時間推演，我們會建立完整的詞彙集，它解釋了一切用戶思路。邪惡一點來說，用戶真的覺得我們懂他，因為都用相同的語言。</p><p>小提醒，為了避免用戶從交心掉回彼此不熟的事實，當聽到他們用不是預想的字眼、或發音來稱呼我們早已熟悉的概念（尤其是品牌中英文名），<strong>千萬不要指正他們，或在往後對話使用我們認為正確的說法</strong>，只要使用「如同剛剛你提到的 “那個詞” …..」這種方式接續就好。先前提到，訪後用戶的心理需要沈澱，如想導正他們的用詞，可以委婉告知不知道在日常生活中人們是如此稱它，我們的圈子有別的講法。</p><h4>第 5 招，同步雙方的行為</h4><p>這是某些實用心理學書籍帶來的想法，原本是半信半疑，但實際遇上這輩子不想交流超過三句話的對象時，這些技巧可以讓我的兩小時不會像是兩年一樣長。</p><p>原理很簡單，就是完全模仿對方。不論是表情、頭手上半身的姿態、呼吸講話的速度、腔調等，都能讓我們快速除掉個性，與對方建立連結。</p><p>據說人的左半臉會表露真實的情緒，不像是右半臉那樣有修飾的能力。關注用戶左臉的臉部肌肉線條，可以快速幫助我判斷用戶對話題的防禦性，還有他們在回答中提及相關人事物的情緒反應。看到用戶右臉笑起來，左臉卻沒有完全跟上時，我總會背脊一涼。</p><h4>第 6 招，冷場實用求生術</h4><p>看小抄只會提醒用戶這是有目的的對話，但也不代表我們要背誦講稿。準備好要討論的話題，用類似心智圖的方式來內化話題的各種面向跟關聯。在現場的對話絕對不會照著劇本走的，要是碰到句點王，就要有四面八方都敲敲看的準備，此時腦內整理過的脈絡就變成我們的明燈。</p><p>人基本上都喜歡讓別人感興趣，我們不妨在表達同理、好奇，甚至驚疑時，都能帶入表情、語調，與肢體的改變，用戶會因此感覺有義務要回應我們而開啟教學模式。微量的刺激來擾動對話的流動，可以讓整個過程更有生氣。同樣邏輯有反向的應用方式，訪談中刻意的數秒沈默，會促使用戶為了化解尷尬而透露出更深層的思慮，反而造成我們認真聽的印象，也讓更深層的情報得以浮現。</p><p>有時候因為一個閃神、一時詞窮，真的會露出明顯破綻。這時就請紀錄夥伴出來救援，直說「聽到現在，我同事一定有問題好奇想問你」，除了被白眼一陣之外，有時也因此突破地獄鬼擋牆的困境。</p><p>最後，當遇到的愛反問的用戶時，請放心在調整表情後用問題回答問題，一來表現我們對用戶的純然好奇，二來他們的問題其實也代表我們成功敲中了某些心結。</p><h4>第 7 招，片尾彩蛋才精彩</h4><p>在心理諮商領域有知名的門把效應，說客人手握門把離開前，會吐露更關鍵的資訊。在我過去的訪談經驗中，用戶因為脫離問答情境而放鬆時，會自然地用更私密的觀點來講述之前談過的事物，有時會整個推翻這段時間我內心已經建立的理解模型。這樣的效應令人又愛又恨，真相總是來得晚。</p><p>訪談人次累積多了之後，我養成了兩個習慣。首先是刻意把訪談時間縮短，尤其是遲遲感覺不到深刻的見解時。主動繳械說自己沒有問題了，並鼓勵用戶對我發問，此時連紀錄同仁都不自覺肢體放鬆，不盯螢幕看了。轉化成一個更單純的聊天模式，互相有問有答，通常會有更好的突破。所以，可能有人也猜到第二個習慣是什麼了。<strong>錄音筆在用戶離開視線前，千萬不要關！</strong></p><p>至於訪談到何時該停止？如果觀察得夠專心，時候到了自然會知道，因為我們會意識到對方與自己都被掏空了。我個人的經驗，<strong>兩小時是雙方注意力的極限</strong>。</p><p>文長至此，是該緩一緩讓各位來思考如何應用前述的訣竅在手上的產品、服務，或專案。也歡迎大家的提問與指正！</p><p>在下集，我們要接續談一談<strong>如何提高採收到的資訊的價值</strong>，並做個總結。</p><p><a href="https://medium.com/mz-uxui/12ways-to-improve-ux-designers-user-interview-skills-vol2-f58f70af780e">給 UX 設計師的訪談實戰 12 招（下）</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=82829a2087a0" width="1" height="1" alt=""><hr><p><a href="https://medium.com/mz-uxui/12ways-to-improve-ux-designers-user-interview-skills-vol1-82829a2087a0">給 UX 設計師的訪談實戰 12 招（上）</a> was originally published in <a href="https://medium.com/mz-uxui">MZ-UXUI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[數位產品的 UI 設計原則（上）]]></title>
            <link>https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8A-c42f9ddc3700?source=rss----6b297ffa0342---4</link>
            <guid isPermaLink="false">https://medium.com/p/c42f9ddc3700</guid>
            <category><![CDATA[ui-design]]></category>
            <category><![CDATA[app-ui]]></category>
            <category><![CDATA[ui-ux]]></category>
            <category><![CDATA[ui-ux-design]]></category>
            <category><![CDATA[uikit]]></category>
            <dc:creator><![CDATA[MiChang]]></dc:creator>
            <pubDate>Sat, 15 Apr 2017 10:32:15 GMT</pubDate>
            <atom:updated>2017-04-19T07:46:17.466Z</atom:updated>
            <content:encoded><![CDATA[<h4>使用者介面設計與網頁或視覺、平面設計最不一樣的地方是，重視使用者經驗。</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TAk_dDTByMzcQbIAAPtcBA.jpeg" /><figcaption>Image Curtesy: Unsplash.com</figcaption></figure><blockquote>「原來使用者並不一定是我們所想像的樣子。」</blockquote><p>在網頁設計中打滾了十多年後，帶著視覺設計與前端設計的一把老骨頭正式的來到了介面設計。很多站在前端的設計師 / 開發者應該不免有過這樣的經驗，跟 Project manager 一起討論「介面」以及「效果」該怎麼呈現，視覺設計師多半是考慮風格與美觀度、前端設計師考慮在網頁上能否忠實呈現視覺設計、前端開發者則是實現互動效果與以及重視效能，而不管怎麼樣，這些專業最大的共同點在於，這些都是他們「自身」的能力與觀點。<br>「我覺得這樣比較漂亮」、「這個效果比較炫」、「老闆比較喜歡這個風格」、「客戶習慣用那支手機跟這個瀏覽器」、「我不會寫那個效果」、「時間來不及開發這麼複雜的動態」…，那麼到底誰考慮過使用者的想法呢？當然現實有太多必須妥協的因素，而且不停上演著。但為了想要更了解實際的使用者經驗感受，並且不侷限於在各種能力上的技能不足，於是我們現在更專注在使用者介面上，想讓產品介面設計可以更貼近使用者。<br>而與 UX 夥伴在了解使用者的過程中也體會到了與以往不同的感受、以及學習到了不同於以往的經驗，在過程中也有許多衝擊。</p><h4>​1. ​在介面設計之前</h4><blockquote><strong>使用經驗訪談與研究結果，是使用者介面設計的前哨站</strong></blockquote><p>開始設計之前必須考慮到產品的使用者，會使用該產品的人並不是 Product Designer、也不是 Product Manager，更不是 Product Owner，在 UX 進行使用者訪談以及取得結論前，必須先與 Product Owner 了解他們為產品本身定義的使用者族群、年齡層、偏向的性別…，也許更進一步的興趣、喜好等等，當然也有可能最開始的推測不見得是完全正確的。<br>所以<strong>取得使用者經驗的研究結果非常重要</strong>，且必須有專業的 UX 夥伴能夠從使用者訪談過程中去挖掘他們內心的渴望、心理狀態、在乎的事情、使用的習慣、與產品互動的方式等等，並搭配各種 UX 方法論從中研究並整理歸納出結論。</p><h4>2. 把自己放在使用者後面吧！</h4><blockquote><strong>你在意的事情，使用者可能根本一點不在意，甚至沒注意到。</strong></blockquote><p>在開始正式接觸並設計 UI 的過程，必須拋棄很多個人的「觀點」與「看法」，<strong>重點不是我們的感受，不是「我覺得」、「我認為」，而是「使用者」的感受</strong>。即便做了使用者訪談與研究，經歷方法論分析得到結論，並開始針對研究結果進行設計之後，接著再拿 Prototype 到市場上做測試，有時還是可能會被狠狠的打臉，質化分析研究後進行的設計並透過觀察來歸納得到結論，這整個過程實在不容易，而且可能有著血淋淋的結果。<br>檢視整個設計過程發現，也許在長時間的討論以及設計下，還是主觀的決定多，並逐漸偏離了市場，而這件事情也很值得我們去重視，這也是在每一次的產品設計中可以不斷學習到的地方。<br>這麼說並不是鼓勵設計師拋棄自己的主觀與專業，而是根據使用者的偏好與需求，用自己的專業將整個介面設計做出最適合使用者的產品。</p><h4>3. 善用適合的工具</h4><blockquote><strong>如果可以，就用 Sketch 吧！</strong></blockquote><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*-B0kQlxnF6UkSMY7_Y3d0g.png" /><figcaption>Sketch</figcaption></figure><p>UI 設計師最常用的工具大概就是 Sketch 了。他最棒的地方是可以讓你重複使用元件而不必老是複製一樣的圖層，一個樣式改了就可以全部套用所有設定。<br>而且目前市面上的 Prototype 工具都圍繞著 Sketch 產生了各種大大小小的外掛，包含圖型運用、表單模組、模組元件、線上協作、內容生成、前端生成…等，也有很多設計師熟知的國外團隊開發的外掛，UXPin、inVision、Design+code、Flinto、Prott、Zeplin…，一個團隊甚至會陸續開發各式各樣的外掛。<br>免費、付費的輔助工具非常多，從中去挑選適合搭配 Sketch 作業的工具，在很多文章、線上線下課程都有介紹，這邊就不多提了。<strong>重點是我們得要突破語言（多為國外資源）與系統（目前支援 mac）的界線才能取得這些珍貴的資源</strong>。</p><h4>4. 符合基本的規則與規範</h4><p>通常在對 Product Owner 進行訪談時，就已經能夠得到你需要針對什麼樣的產品來做設計，當然也有例外啦。Website、Mobile site、Native app、HTML5 app…，設計前要取得使用者研究結論以外，還<strong>必須確認開發時要符合的作業系統以及瀏覽的裝置及媒介</strong>，Native app 對設計師來說比較需要學習系統給予的規範與文件如 Android 以及 iOS 都有相對應的 Guideline，在針對不同系統的設計上才能夠取得規範基礎。<br>Website 與 HTML5 app 相對來說輕鬆許多，雖然不需要強制遵循 UI Guideline，但若是 Web View，仍需進一步考慮在不同系統以及裝置的情況下，設計出使用者易用及符合通用規範的設計，比如多選的表單不會使用 radio button 來呈現。（易用與通用性請見<a href="https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8B-b976881b5828">數位產品的 UI 設計原則（下）</a>）</p><h4>5. 全域的設計方向制定</h4><blockquote>為使用者尋找合適的介面呈現方式</blockquote><p>我們取得 UX 研究結果以及設定的人物誌（Persona），瞭解使用者的需求與偏好、使用行為、與產品的互動、期待產品帶來的價值，接著可以開始去尋找並且制定適合的介面設計，也許也能從類似族群使用的產品去尋找設計上的靈感，比如約飯局 App 能夠從交友 App 或平台得到一些想法上的刺激。<br>另外例如運動類型的產品，需要透過系統追蹤並倒出資料以即時反饋給使用者，那麼在追蹤資料、圖像、數據的顯示與重要程度就會遠遠超過其他資料，資料視覺化的呈現就相對重要。</p><p>— 延伸閱讀【數位產品的 UI 設計原則（下）】</p><p><a href="https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8B-b976881b5828">數位產品的 UI 設計原則（下）</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=c42f9ddc3700" width="1" height="1" alt=""><hr><p><a href="https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8A-c42f9ddc3700">數位產品的 UI 設計原則（上）</a> was originally published in <a href="https://medium.com/mz-uxui">MZ-UXUI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[數位產品的 UI 設計原則（下）]]></title>
            <link>https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8B-b976881b5828?source=rss----6b297ffa0342---4</link>
            <guid isPermaLink="false">https://medium.com/p/b976881b5828</guid>
            <category><![CDATA[ui-design]]></category>
            <category><![CDATA[ui]]></category>
            <category><![CDATA[uikit]]></category>
            <category><![CDATA[ui-ux-design]]></category>
            <category><![CDATA[ui-ux]]></category>
            <dc:creator><![CDATA[MiChang]]></dc:creator>
            <pubDate>Sat, 15 Apr 2017 10:32:11 GMT</pubDate>
            <atom:updated>2017-04-20T12:43:14.534Z</atom:updated>
            <content:encoded><![CDATA[<h4>將設計著重在「使用者需求」才是最高遵循的原則</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*XJqwZQR2SsklMrA7UdACsA.jpeg" /><figcaption>Image Curtesy: Unsplash.com</figcaption></figure><p>承上篇，<a href="https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8A-c42f9ddc3700">數位產品的 UI 設計的原則（上）</a>提到了傳統設計師的盲點與侷限，以及重視使用者的觀念、善用適合的工具、符合基本的規範、為使用者尋找合適的介面呈現方式等幾點，這篇接著討論了介面的樣式層級、易用通用性以及 Prototype 的必要。</p><h4>6. 定義介面的層級與樣式</h4><blockquote><strong>綜觀產品的層級思考，以及介面元件的一致性是最重要的設計原則</strong></blockquote><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*msparRTpcNotuncnUaNzQA.png" /></figure><p><strong>介面最重要的是「一致性」的定義</strong>，必須考慮易讀、易用性，統一元件、色彩與文字的層級與樣式是最基本也是最重要的，各種元件的間距、元件的樣式、色彩的規範、文字的樣式層級、表單的介面…等等。<br>舉例來說，按鈕 / 連結的樣式在整個產品 / 全站上可能只有三至四種，但不僅僅是「樣式上」定義，使用意義上極為重要，什麼時候要用主要的按鈕呢？我們如果試著定義按鈕的層級可能如下：</p><ul><li>主要按鈕（第一級）：第一主色、文字可能是第三級、外距數值可能會與其他主要元件的間距一致…</li><li>次要按鈕（第二級）：第一主色邊框搭配白色底色</li><li>第三、四級按鈕：第二色或改變尺寸、改用文字連結等等</li></ul><p>而一般來說主要按鈕（第一級）是 CTA（Call to action）類型，也就是需要誘發用戶進行最重要的動作時，必須要給予的一個操作介面；而次要按鈕通常是必要但不是最立即需被注意到的；第三四級可能就需要更加弱化，這種層級上的思考及展現是 UI 設計師必須要具備的。<br>而元件樣式<strong>並非僅針對單一場景作定義</strong>，比如上述的按鈕 / 連結的設計思考及決定，必須綜觀地考量到整個產品會有哪些觸發動作的層級，才能夠回過頭來去「針對層級」做進一步的樣式定義，而這也是最考驗介面設計師的地方。</p><h4>7. 兼顧易用性與通用性</h4><blockquote><strong>不要老想著發明新東西</strong></blockquote><blockquote>我們 UX 夥伴 Zac 最常說的一句話「不要老想著發明新東西啊！」</blockquote><p>沒錯，一個產品設計的創新是有其必要性，但這創新的精神並不需要徹底實踐在每一個設計決定與細節上，如果為了創新而把 App 或 Mobile site 的 Navigation 放在左邊或右邊，的確創新但佔空間、不好使用也不通用，而且在 Native App 還違反了基本的規則。<br>適時的創新通常是概念上，但還是得考慮易用性，且能夠讓使用者能夠在一兩次就學習起來。比如常見的漢堡選單，已經算是相當通用的 UI 設計元件，也不只一兩次聽到使用者表示不懂那是什麼，但他們依舊可以透過學習進而理解，當找不到要去哪裡，手指去畫面四處點擊時，該圖像會觸發的下一個動作是展開選單的動作，因此<strong>這個圖像所觸發的結果是可以容易被學習的</strong>。</p><h4>8. Prototype 在開發過程中的必要性</h4><blockquote><strong>需要快速的測試市場，那麼就先把個人堅持放一邊吧！</strong></blockquote><p>有些設計師無法在設計尚未完整時，就把作品搬出來給人看，但如果要使用 Prototype 快速的測試市場，那麼就必須先把個人的堅持丟到一邊，上面說過了，<strong>重點永遠不是「你認為」產品怎麼樣才完整，而是使用者「懂不懂」跟「願不願意」繼續使用產品</strong>。<br>UX 研究產生了結論，並且定義了 IA，挑選基礎架構設計中最重要的一兩條動線來做 Prototype 並進行使用者測試，即便結果出乎意料，也來得及在產品完整或正式推出前能夠調整到最符合市場的需求。而這個方式遠比要設計師做到自己最滿意、或是最符合 Product Owner 期待的產品，花了一年半載全部開發完才上線，然後發現使用者根本不買單還要來的實際多了。</p><h4>9. 不能忽略內容的重要性</h4><p>雖然是使用介面的設計，但內容的易讀性也不能忽略，<strong>介面與內容是息息相關的，甚至內容也是介面的一部分</strong>。<br>例如當設計的產品是以文字內容為主，在研究結果後會知道在設計時必須要兼顧的文字表現以及格式有哪些，比方字型的挑選、文字層級與顏色的關聯性、字級大小的排列、圖片與圖說的搭配、引言的易讀性、重要文字的區隔與凸顯…等等，都會影響到使用者在閱讀時的感受與理解程度。</p><h4>10. 善用生活與美感經驗</h4><blockquote><strong><em>不斷的學習與感受</em></strong></blockquote><p>身為 UI 設計師可能會為各種不同的產品深入研究與設計，因此平常充實自己絕對有其必要性。如果對於某一個主題比較有共鳴或較為熟知，或自己也是使用者之一，那麼在設計起來也許會更有熱情，以及更能理解使用者在使用時的心情，他們想要從中得到什麼，也許能做出更貼和使用者的介面。<br>不過也曾經碰過本來對該產品沒興趣的設計師，因為接觸後反而引發興趣去學習或深入了解該服務內容的情況。多看看各式各樣的產品設計並深入體驗，對於充實自己還是有非常大的幫助，不論是設計的敏銳度、通用的 Design Pattern、最新的設計趨勢…等等，以及市面上各種付費或免費的資源、教學文章等等，並且<strong>不要抗拒去看看各種領域的新趨勢，不同體驗與知識對於設計產品時都可能會有意想不到的幫助</strong>。</p><h4>總結</h4><p>數位產品的 UI 設計與以往的網頁設計還有很大的不同，那就是：</p><blockquote><strong><em>產品上線以後只是起點而非終點，因為沒有不迭代的產品</em></strong></blockquote><p>因此對 UX / UI 來說，重視使用者的體驗與感受永遠都是最重要的事情，所以如果哪一天 Product Owner 或是各方的 Stakeholder 為了某個功能的去留或樣式而意見相左的時候，不妨直接拿著半成品去問問看路人也許會有突破性的意見！</p><p>也感謝我的 UX 夥伴 <a href="https://medium.com/@zactongyuehyang">Zac</a> 能夠在這麼多次實作裡帶我去領略使用者經驗對於介面設計的重要性，以及累積這麼寶貴的經驗與心得，建議 UI 設計師們不妨有機會跟著 UX 設計師去做使用研究以及訪談，相信也會得到很多意想不到到的收穫！</p><p>— 延伸閱讀 【數位產品的 UI 設計原則（上）】</p><p><a href="https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8A-c42f9ddc3700">數位產品的 UI 設計原則（上）</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b976881b5828" width="1" height="1" alt=""><hr><p><a href="https://medium.com/mz-uxui/%E6%95%B8%E4%BD%8D%E7%94%A2%E5%93%81%E7%9A%84-ui-%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87-%E4%B8%8B-b976881b5828">數位產品的 UI 設計原則（下）</a> was originally published in <a href="https://medium.com/mz-uxui">MZ-UXUI</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
        </item>
    </channel>
</rss>