px、pt、dp、sp 大混戰
dpi、ppi、px、pt、dp、sp 之類的名詞釋義網路文章已經有很多，但全部混在一起運用到 Mockup 上時該怎麼處理？
這個問題其實我也爬了滿久的文，沒翻到有比較完整的說法，所以自己整理了一篇。
形色 - 会上瘾的识花神器
這篇是意外插隊。在網路上亂逛爬資料時無意發現這款 App，評價還很高。第一代 iPad 剛出的時候，我做過寶石、甲蟲的標本箱 App，也做過從外觀、聲音、棲地辨認鳥類的科學型 App，看到能辨識花朵的 App 覺得好親切啊～
iOS、Android 字級單位
「這是靠我自己摸索出來的喔！是拿 App 截圖進 Photoshop 辛辛苦苦比對所量出來的尺寸。」這位 UI 先生/小姐，你知道世界上有 Guideline 這種文件嗎？「比起問別人，自己摸索出來的才記得深刻嘛！」你知道世界上有工程師這號人物嗎？浪費一堆時間在 PS 量半天為了什麼？文件上寫得一清二楚。字級要用是 pt 或是 px 轉頭問問 RD 立刻就有答案了。
反應與提示
在易用性原則裡，系統狀態的能見度、辨識而非記憶這兩點與「反應」有關。在操作 App 時，「反應」扮演著重要角色，它有著引導使用者至下一步的功能，幫助使用者理解目前狀況、繼續操作。在 iOS 上，常見的反應有數種：視覺、聽覺、觸覺。點擊某個按鈕，按鈕會變成被擊中凹下去的樣子，輸入正確會聽到叮叮的成功提示音，操作錯誤或失敗手機會震動並聽到嘟嘟的錯誤提示音等等。如果對於 App 的「反應」置之不理，使用者就無法知道自己操作的結果，對於自己的操作產生疑慮、逐漸失去對這個 App 的信賴度。
各種狀態與突發狀況
即使畫了非常精細的 UI FLOW、每一頁 Wireframe 旁也寫上詳盡的註解，但在專案後期 RD 仍是發現許多在前期規畫階段沒有被考慮進去的情況，這是為什麼呢？有一種可能性是漏了思考「各種狀態」和使用者的「突發狀況」。這會導致開發時程延後，因為訂定的規則不夠準確而再次召開討論會議確認細節。甚至發現此路不通但該功能已經做下去了無法修改進退兩難的情況。
十大易用性原則
身為 RD 的你受過太多 UI 的氣嗎？老是發現邏輯不通需要打掉重練被延誤時程嗎？常被 UI 嫌念理工的沒有美感都不懂嗎？報仇的時間到了。這篇文雖然說是「十大易用性原則」，也可以說得上是：「教你如何捅 UI 」。RD 最擅長講理，就來跟 UI 講理！從易用性下手找 UI 麻煩，沒有幾位 UI 不中刀的…
文章分類
