剛聽完 UX/UI 的分享、從 PicCollage 台北 HQ 回來。在路上邊騎車也消化了一下在分享會聽到的東西，就來寫一下吧！
如果你不是設計師，你也可以先從「結語」的段落開始看，再決定要不要讀讀文章的內容。
這篇主要是由在聚會上聽到的分享，以及自己的經驗和想法而撰寫成。在聚會中大大們分享的內容中，實作經驗的部分遠大於理論，想要在專案中使用的話值得參考。
尊重你的夥伴和你的使用者
每一個人都會有他們自己的背景知識及經驗，對於同一件事情的看法也不一樣；在思考的時候多為你自己的夥伴及使用者著想，
- 一來可以放下自己的堅持於成見
- 二來可以看見原本自己沒看見的角度，更加容易接納夥伴或是使用者的回饋
過去的經驗與每個人的定位
- 過去的經驗可以幫助當下的思考
- 每個人的專長不同，一定都會有其有用的地方
今天有幾個講者的背景都不是本科系的：如土木、醫生、電子電機。而我自己應該也算是有開一些分支：音樂、繪畫、 UI/UX 和本業的工程師。這些過去的經驗其實都可以幫助我們在現在或是未來的專案幫助到我們自己。
像是今天 Screencast 的報告者，就有以醫學名詞 - neglect - 去敘述他們所發現的使用者的行為。意思就是指使用者明明就有看到某個東西，卻會無意識地忽略那個東西。
在今天分享的過程中，也有許多因為生活中經驗、而觸發 App 的點子的案例。例如： Walkr 是因為在新加坡走了很長的路到捷運站，就想要讓走路變有趣；Screencast 是因為想要讓朋友之間的聯繫更加即時緊密等等。
模仿主流 Apps
- 尊重平台的使用方式，也就是人機介面準則 (Human Interface Guideline)
- 可以模仿主流 App 的操作模式，但是也要顧及目標使用者 (TA, Target Audience) 的操作體驗
近年來我有發現一些主流的 apps ，像是 Facebook app 和 Twitter ，雖然他們各自基本上有自己特有的操作流程，但是其實他們在 iOS 和 Android 的平台上，都大量的採用了各自原生的操作模式。
今天在分享會中，有一些模仿主流 apps ，讓我想起自己在過去有參與一些專案的 UX 或 UI 的發想中，時常想當然地覺得某某 app 這樣做，我就想說提議可以這樣做做看。
例如，
- 在 Tumblr 的 app 中，在貼文上快速點兩下，可以 like 那篇文章或圖片，我們也可以這樣做做看
- 在 Pinterest 的 app 中，在列表出現時，會先預載圖片的顏色，增加 loading 時的趣味感，我們也可以這樣做做看
- Line 的 NEWS app 中新聞分類方式，好像可以解決分類超多時的呈現問題，我們也可以這樣做做看
- ... 等等等等
這樣有好也有壞，其實我也常常會收到設計師跟我說：
這樣我覺得就不好用啊！
所以我覺得其實有一些優缺點：
優點就是
- 可以直接萃取人家做完使用者研究的結果，去猜想使用者想要（或是可以接受）怎麼樣的操作。
- 越受歡迎的 app ，模仿他的操作方法可以降低使用者的進入門檻，進而達到這個 app 的目標，並讓使用者取得我們要提供的核心價值；也就是比較容易創造好的 onboarding 體驗。
缺點還是有的
- 有些 app 是獨有的操作模式，這些操作模式可能就是只有一部分的 power users 有辦法熟悉的操作，要是拿來當使用，可能會困擾絕大多數的使用者
- 取用或參考的操作模式，不一定適合你的 app 的模式
關於要養成獨有的操作模式，我覺得跟迭代的進化也有關係。譬如，在初期上線時，保有各自平台的操作習慣，透過不斷的操作來訓練想要在 app 上達成的操作模式
至於如何決策該採用什麼操作方法，也需要去多想一下別人對於這個操作的感受，以及收集使用者操作的資料來判斷、又或是進行 A/B Testing 或是 pre-release 測試。
尊重習慣與養成習慣
- 要尊重使用者的習慣
- 要注意不要無意的打破自己幫使用者養成的習慣
習慣其實是很重要，也是很困難的一件事情。但是當好不容易幫使用者養成習慣了，要小心不要無意間打破那個習慣，而造成體驗下降。
我自己的想法是，可以將想要讓使用者養成習慣的行為，從簡以及讓使用者可以反覆操作。例如，在一些通訊軟體上可以長壓著麥克風大按鈕來錄聲音訊息。
Metapher（隱喻）以及提示
- 規範 - 跨 app 的一致性
- 正確及清楚的提示
這邊指的隱喻會指像是 app 中的 icon 、或是 app 內的操作方式。在 app 裡面，除了當然需要的一致性之外，也要去瞭解使用者對於各種圖標或是操作方式應該會產生的結果。
另外也有被提到的是， app 中的圖標對於行為的表示要一致，不要換了畫面、同一個圖標；或是在對於同樣的操作模式，你的使用者們習慣時，要謹慎不要造成例外（突然少了個按鈕，或是發生未預期的事情）的情形發生。
或是當需要使用者進行某項行為時，畫面上有空間的話，多了幾個字或是多個圖標，可以讓操作流程更加順暢，不要讓美術上的堅持及省略，造成使用者的困擾。
而在提示的部分，「把想要使用者要做的事，放在最容易取用的地方」，我覺得是很重要的，這也是很多線上 app 常做的事情。例如： Instagram 把上傳照片的按鈕放在畫面中最顯眼的位置、 Foursquare 的 Swarm 把打卡的按鈕使用了很顯眼的顏色並放在畫面中最顯眼的位置、 Uber 把乘車地點的按鈕放在第一畫面的正中間並也用了對比強烈容易注意到的顏色顯示 ... 等等。
對使用者不要失禮、減低困惑
- 在適當的情境要求手機的權限
- 不要在半夜推播
- 用一般人容易理解的詞語
這一點我覺得是最重要的，如這一篇從最前面和一路上都有隱約提到的「尊重使用者」，去關心使用者的操作習慣、去思考使用者會不會對 app 的用語困惑等等。
首先就是手機的權限。從有 app 的時代以來，應該對不少 app 都是在開啟 app 的第一次，就拼命要權限的情形滿有印象吧！比較好的做法是，可以先有前導的說明，再請使用者開啟存取的權限；或是當真的有需要用到某個硬體的權限時，再去要求即可。
接著就是推播通知 (push notification) ，當你要睡覺的時候，收到推播通知其實會讓人不爽的吧！這時候只要訂個當地時間的勿擾區間，例如晚上十點到隔天早上七點，都不要發送推播，就可以避免再不當的時間干擾使用者。
關於容易理解的部分，開啟「計步器」，是 Walkr 設計師有提到的案例。對於使用者，他們不需要知道 iOS 或 Android 上分幾種用來當計步器的硬體，他們只需要知道「要開」還是「要關」計步器的功能就好。我們必須要把艱澀的字詞，用使用者看得懂的敘述表達出來。
學習與抱持開放的心
- 抱持開放的心態，為目標去尋找各種多樣化的解決方案
- 利用下班時間或空閒時間學習或做自己覺得有趣的事情
雖然分享者提到設計師跟工程師的思維的不一樣，工程師偏收斂，設計師要往開放多樣 solution 的方式進展。但是我覺得工程師也要擁抱及思考多元的解決方案，激盪之後才可能會有更好的結果。
在學習的部分，可以利用空閒時間，補充自己專業的新知識、嘗試自己想要做的東西從中學習或是激發靈感。上班太忙的話，也可以利用回家後半小時到一小時的時間閱讀或是嘗試新的或是不了解的東西，也總比沒有好。
結語
其實今天獲得的這些知識，換換主角的角色其實是都可以通用的，例如：
- 一個專案的 PM ，尊重自己的成員，幫忙他們排除專案執行中的困難、並給出清晰的指令及規格
- 寫後端 API 的工程師，尊重自己的使用者（前端工程師），寫出容易接，架構清楚且一致的 API
- 一個工程師，尊重未來的自己及自己的夥伴，寫出容易閱讀的程式碼
- 一個團隊的成員，尊重及互相交流不同的專業，如團隊中的 UI 和 UX designer 以及工程師之間的互動 ，幫助提升產出的水準
這篇所有的大標的內容其實很多都有互相關聯，而不管套到什麼職業或是職場都可以適用。我在過去也有經歷過持著知識的傲慢、逐漸轉換成願意互相聆聽及調整的現在的我，也很感謝各個職場、同事及朋友的教導與體諒。
以上心得都是我目前及過去的工作中獲得的經驗，分類可能也有點混雜，如果正在閱讀的您有什麼想法，歡迎在下面留言，謝謝 