web-archive-me.com » ME » A » AKANELEE.ME

Total: 398

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • 無損圖片的介面製作方式(上) « 嫁給RD的 UI Designer
    形狀圖層 向量 Photoshop 中也是有向量繪圖工具 採用形狀圖層 活用筆型工具 路徑選取工具 搭配圖層樣式 一樣能得到精緻的效果 在 App 裡 Navigation Bar 是最常遇到需要製作的元件之一 可使用形狀圖層快速製作 以下教學就以形狀圖層的方式 做一條 Bar 和一顆按鈕 1 Navigation Bar 的範圍 使用形狀工具裡的 矩形工具 畫出一個 640x88 px 的長方形 只要是iPhone 4 之後的 Navigation Bar 都是這個尺寸 2 Navigation Bar 的光影 添加圖層樣式 設定漸層覆蓋 使用灰階上淺下深 讓 Navigation Bar 有基本從上方打光的光影變化 淺色和深色差距 HSB 的B數值不超過 20 超過光影會太強烈會變成復古 10 年的公家機關風格 3 Navigation Bar 的材質 設定圖樣覆蓋 加上材質的質感 4 Navigation Bar 的色彩 顏色覆蓋 讓 Navigation Bar 偏藍綠色 這種作法可以快速修改測試 Navigation Bar 的色彩 如果遇到客戶要求出個11種不同顏色的 Navigation Bar 你會很感謝這招 5 加強 Navigation Bar 最深的陰影處 iOS 預設皆由正上方打光 將 Navigation Bar 的最暗處製作出來會讓畫面顯得更真實精緻 使用矩型工具 建立一條 640x2 px 的純黑色長條細線 置底對齊 Navigation Bar 6 打亮 Navigation Bar 的高光 用同樣的方式製做高光處 建立一條 640x2 px 的純白色長條細線 置頂對齊 Navigation Bar 7 製作按鈕 使用形狀工具中的 圓角矩形工具 畫出長方形 8 按鈕要和 Navigation Bar 相同風格 在 Navigation Bar 底圖圖層上按右鍵 選 拷貝圖層樣式 9 複製貼上最快 在按鈕圖層點選滑鼠右鍵 貼上圖層樣式 10 貼上後長這樣 此時按鈕的樣式就會和 Navigation Bar 一樣 要加上點修飾讓它凸顯出來 11 加強按鈕輪廓 設定 筆畫 讓按鈕的輪廓線明確些 12 增加立體感 突顯按鈕 內光暈 可以加強光影變化 讓按鈕更立體 13 輸入文字 使用文字工具 輸入 Edit 14 加強文字光影 文字也加上陰影 讓字體更明顯 15 完成 記得每新增一個圖層 就順手將圖層命名整理 以後不僅修改快速 也讓接手的人便於處理 雖然現在流行扁平化設計 出這篇教學似乎過時了 BUT 台灣的客戶真能接受扁平化那種色塊的沒幾個人 他們會覺得 空白的地方太多 設計師沒做事 為了跟上潮流和迎合停在擬物風 iOS6 的客戶 做個折中方案的話 可以考慮用這篇教學的作法 這是很基本很簡單的製作方式 熟的話不用3分鐘就做好了 然後就不停的拷貝貼上做出其他頁 頂多改改按鈕上文字 很快很方便 善用 拷貝圖層樣式 能加快很多工作速度 無損圖片的製作方式 下 將介紹智慧型物件 智慧型濾鏡 在ai畫好 貼到ps的技巧 遮色片 調整圖層等不同的技巧 Posted by Akane Lee November 20 2013 初學者 photoshop UI

    Original URL path: http://blog.akanelee.me/posts/161003-non-destructive-image-modes-part-one (2016-05-02)
    Open archived version from archive

  • UI 跟 RD 溝通的三個誤區 « 嫁給RD的 UI Designer
    混亂邪惡 只會自己爽就好講不出個所以然 老是愛幻想程式辦不到的事 從 UI 的角度卻會把 RD 歸類在 守序邪惡 滿口這個不行那個辦不到故意挑骨頭唱反調 自己是 混亂善良 人生目標就是做出最棒的作品造福世人 2 UI 不是沒有邏輯 是一口氣講太多 RD 來不及反應 當電腦 LAG 的時候不耐煩又輸入好幾次指令會發生什麼事 當機 錯亂 或輸入錯誤請重試 和 RD 討論事情千萬要注意這一點 不是每位 RD 腦中都有最新款的 CPU 還多插了 2 支 RAM 外加光速上網 尤其在公事上 他們十分留意自己的承諾 當你講了一句話 對他們來說就是下達某個指令 需要 Search 腦海中的資料庫的時間才能確認 再經過一段時間才能將確認後的想法組織成語言回覆 短時間內講太多不同面向的事情 他們就會打結 想像你和他們討論某份文件有問題 他們還在尋找 D 工作 2013 內部案件 CaseXXX 功能 功能分析 規格書 V0 1版 doc 這個檔案時 你就同時塞入很多指令甚至換了話題 他們不錯亂才奇怪 請給他們開啟檔案 尋找關鍵字 存檔or取消 關閉檔案 退出此資料夾的時間 有時候不是他們不理你 而是他們專注在某段 Code 上 RD 認真起來媲美三重苦人士 聾 盲 啞 對外界根本毫無反應 試想一台開了很多軟體和視窗 全速運轉中的電腦 風扇都已經摧到快飛上天了 還一直試圖輸入指令 明知道他的緩存空間都滿了還這樣惡搞他 這不是虐待是什麼 資深的 RD 會分成兩種 超級電腦 或是真空管時期的古董 這不是指他們的能力或技術 而是針對 反應 這件事 資深的 RD 已經遇到同樣的情況太多次 知道怎麼應對進退 腦海中有龐大的 Pattern 可以套用 反應十分迅速 另一種 RD 受到太多打擊根本放棄這一塊 把所有精力都投在工作和專業技能上 他們會等遇到問題再來解決 反正解決問題的經驗太豐富 也早建立一套 Pattern 起來了 3 RD 會覺得這是常識大家都該知道 卻沒想到這只有觸角星人才會懂 觸角星人的眼睛不是在頭頂 是頭頂上長兩隻觸角 眼睛長在觸角上 沒學過程式的 UI 不能理解為什麼 a a 1 對 就是我 RD 不舉個實際的例子來說明 UI 很難理解 但要 RD 找個現實生活中的 UI 能理解的例子也很難 我聽老公解釋半天還是不懂 你們一定對 RD 這種說話方式有印象 那個你知道吧 喔 你說那個 我覺得太商業了 還好吧 那個就是那個理論啊 誰聽得懂你們在說哪個啦 取自蝴蝶小說 沈默的祕密結社 就因為他們覺得常識大家都該知道 誰會知道薛丁格的貓犯了什麼錯被抓去關微波爐之類 講話會習慣性省略主詞和受詞 有時候連動詞都省了 UI 和 RD 在溝通上很常遇到這種狀況 所以我會很機車地把 RD 上一句話的主詞 動詞 受詞一個個挑出來追根究柢 不問清楚很容易誤會 RD 實際上要表達的意思 他們真的沒有惹毛你的意圖 往往讓人生氣後他們會擺出一副無辜的表情搞不清楚自己說錯哪句話 反過來說 RD 會覺得 UI 講話很跳痛 講話前後文接不上 常常天外飛來一筆 討論半天雞同鴨講 UI 已經轉了好幾圈提出數種可能性 RD 還死抓著 20 分鐘前的某個論點不放 這時候我會抽出紙筆畫心智圖 寫明問題的起因 受到什麼影響 所以我以為的方式是這樣 以及為什麼對話方向會歪樓 之類 很大費周張沒錯 但這招能瞬間招回 RD 的聰明才智 只要讓他們了解全盤情況 通常問題都不是問題 還可以順便做個紀錄 未來出包還找得到是誰的錯 省得死無對證 最大的問題在於溝通落差而不是能力不足 要學會和 RD 溝通對 UI 來說真的是門學問

    Original URL path: http://blog.akanelee.me/posts/160872-ui-communicate-with-rd (2016-05-02)
    Open archived version from archive

  • 十大易用性原則 « 嫁給RD的 UI Designer
    良好的設計能讓使用者降低出錯率 在提供取消和重做的功能前先減少使用者出錯的機會 Ctrl z 復原 是最容易被記住的快速鍵 也因為有復原的存在 使用者才會大膽去嘗試各種不熟悉的操作 他們心想 反正做錯了重來一遍就好了嘛 如果一出錯就表示要從新開始 使用者會感到迷惘並且覺得壓力太大 想看看 Diablo 的專家級模式 人物死亡不能重來 在這種模式下哪個玩家不是備感壓力戰戰兢兢小心翼翼的 使用者操作 App 是為了完成他預期的目標 根據八二法則 你的使用者有 80 都是使用最初階的操作 只有 20 人會想要更專業進階的功能 越輕鬆簡單無壓力越受大部份使用者青睞 不過是想透過 App 完成某項目的 用不著壓力這麼大的挑戰自我極限吧 App Awesome Note 的設定頁面 許多進階功能都放在這裡 初學者和RD很容易在這個原則犯下錯誤 不是所有的功能全部攤到第一層就代表豐富好用 所有的功能都很重要就代表沒有一個功能是重要的 就像期末考前把課本每個字句都劃上螢光筆強調 根本沒有重點 有劃跟沒劃一樣 凡事都有輕重緩急 就像一位血流不止 骨折又長期咳嗽的病人在眼前 是要先止血 先處理骨折 還是先治療咳嗽一樣 最重要的事情需標明出來 可以暫緩不急的事之後再說 功能的優先順序也是如此 最重要 最常用的功能放在最顯眼易觸碰的位置 較次級非必備的功能就擺到下一層或是乾脆挪到某個進階選單裡去吧 App Gmail 的側邊欄 這種選單無論主要還是次要的功能 都能排序整理得很漂亮 4 一致性和標準 Consistency and standards 使用者不應該猜測不同的字彙 狀態 動作是不是代表同一件事 考慮到瀏覽器的相容性 App 必須採取使用者的語言 並運用他們熟悉的單詞 短語和概念 而不是程式語言或專有名詞 介面中的控制元件 命令 設定的功能應該清晰明確 操作軟體不應該需要透過排除法進行演繹推理 也不要讓使用者所執行的操作和他們的目標沒有明顯的關連 App Priority List 下方各個 icon 的含意要稍微想一下才能理解 且實際操作和預期的有落差 依現實生活常見的習慣 讓訊息在自然且有邏輯順序的情況下產生 為了達到這個目標 有時需開發一個詞典 這個詞典最好由團隊的技術編寫者來管理和實施 監視文件檔案和軟體中出現的術語一致性 支援目標工作領域中的問題該如何解決 它應該最大限度地減少或消除使用者花費時間解決軟體技術層面中的問題需求 屬性 參數 設定 設置 資源 或者是尋找 搜尋 搜索 搜查 尋求 等等 這些詞指的都是同一個功能 對使用者來說他不會知道 App 上寫的 設定 和 屬性 其實是同一件事 如果將所有的字詞統一有困難 可以乾脆直接使用圖示代表 App My Wonderful Goals 簡單易懂的 icon 設計 畫面乾淨清爽 5 預防錯誤 Error prevention 比起提供使用者明確易懂的錯誤訊息 更重要的是如何防止使用者發生錯誤 像是消除容易出錯的條件或是自動檢查確認選項 或是讓使用者確認他們接下來要做的行動 越是讓使用者自行輸入的欄位越容易出現錯誤 明明只能輸入數字的地方就是有人會想打英文字母 擺明說了帳號只能使用英文或數字 還是會有人用上特殊符號 比起使用者填完所有欄位按了送出後再告訴他哪些地方有誤 不如在輸入錯誤時就擋住他 在輸入正確資料前無法進入下個步驟 如果能在欄位旁邊即時反應驗證狀態是再好不過的 在 iPhone 上最方便的就是內建數種鍵盤 在輸入電話號碼的欄位時只跳出數字鍵盤 輸入日期時使用 Picker App 聯絡資訊 輸入只有數字的欄位時 就跳出數字鍵盤 在小小的手機螢幕上打字是非常辛苦的一件事 按鈕小不好按 又容易出錯 最好也最貼心的作法是連輸入都簡化了 最好點點手指就解決 像是 Google 的即時搜尋 打入第一個字時就將熱門選項列出來供使用者選擇 但有可能不是使用者需要的 或像是 Facebook 輸入一個關鍵字就將所有包含這個關鍵字的朋友列出 App App Store 在使用者邊輸入時即時搜尋有可能的關鍵字 6 辨識而非記憶 Recognition rather than recall 盡量減少使用者需要記憶的事情 行動以及可見的選項 使用者沒辦法記住太多步驟 App 如果有使用說明介紹 應該放在顯眼且可輕易使用的位置 如果軟體把資料當作訊息 把資料都丟給使用者 要使用者自己查看資料代表他們的注意力會被分散 產生錯誤的機會就會增加 軟體應該將使用者的注意力集中到重要的資料上 並幫助使用者從中取得訊息 而不是未經過篩選要使用者花時間思考 像是為了酷炫而特別設計的操作介面 與眾不同讓人眼睛一亮 但使用者在初次接觸後再度使用 要花多少時間才能找到上次操作過的功能 相信很多人都有邊自言自語 我記得這個 App 有 xxx 功能啊 在哪裡呢 邊將某個 App 所有按鈕選單翻一遍的經驗 App Yoritsuki 非常漂亮精緻的 App 下方選單與上方提示一目了然 7 彈性與使用效率 Flexibility and efficiency of use 功能與易用性之間通常存在一個平衡 對於軟體中的每個特性 功能 或能力 都必須提供一種途徑讓使用者調用或控制 如果使用者的目標是可預測而且常用的 使用者不應該為了實現這個目標而必須做很多工作 做少量的工作 得到很多結果 才是使用者想要的 簡單來說就是要思考 有多少使用者 和 使用頻率如何 的問題 越頻繁使用的功能 需要點擊的次數應該要越少 越多使用者使用某功能 它就應該越明顯 且要為核心情況設計 不要為 邊緣 情況付出太多 快速鍵就是這個易用性準則的最佳代表 在 App 上沒有快速鍵的設計 可以透過手勢來完成各式各樣的操作 例如瀏覽列表頁 已捲到最下方後想回到頂端不需要一直滑動手指 只需輕點一下 StatusBar 列表會自動捲回最頂端 App Day One 對撰寫日記來說 拍照和新增是最常用的功能 8 美觀與簡化設計 Aesthetic and minimalist design 為了防止使用者出錯 可以在軟體設計上就盡量減少使用者的記憶負擔 將功能 操作及選項設計得顯而易見 對於不相關或是很少需要的訊息或功能要隱藏起來 僅突出重點在軟體設計上非常重要 像是註冊新會員 如果一開始就要使用者填寫一長串的個人資料 相信許多人在這個階段就打退堂鼓 簡化註冊流程就可以增加使用者成為會員的意願 最好只要一個按鈕就能完成註冊 有的 App 會串接 Facebook 使用者只要同意授權就完成註冊手續 或者是只讓使用者填寫必備的資料如帳號密碼等 其他非必備資料如生日 所在城市等 使用者可以在登入後去個人設定頁自行填寫 App Pose 使用 Facebook 登入 或是輸入帳號密碼 9 幫助使用者認識 偵錯並從錯誤中恢復 Help users recognize diagnose and recover from errors 幫助使用者識別 診斷 並從錯誤中恢復 將損失降到最低 如果無法自動挽回 則提供詳盡的說明文字和指導方向 而非難以理解的代碼 最好能在告知使用者發生錯誤的同時一併提供解決方法

    Original URL path: http://blog.akanelee.me/posts/160115-top-ten-usability-principles (2016-05-02)
    Open archived version from archive

  • 什麼是 Wireframe ? « 嫁給RD的 UI Designer
    Map 一一確認 像是使用者欲刪除某些檔案所跳出的 Alert 警告 或是操作到一半網路突然斷線的提示 畫面上元件是否易於操作 依照 HIG 和大眾操作的慣性 回前頁在左上角 編輯 確定通常會在右上角 有沒有小於 44x44px 的按鈕 或是小於 12pt 的中文字 是否塞太多資訊進去導致畫面擁擠 Wireframe 製作成本低 容易被修改 繪製快速 在開發初期是溝通和發想的重要步驟 節省時間和人力成本 又可防止開發中期發現缺漏或不合用導致全盤重來 很多時候案子都很趕 沒有時間讓 UI UX 在開發後期進行易用性測試 所以在 Wireframe 階段就要將易用性考慮進去 可以說未來所有的設計都是以 Wireframe 為基準 別小看它只是份簡單的框線圖稿 責任非常重大 除了畫面結構外 額外的說明註解也是 Wireframe 的一部份 在每個按鈕或是可操作的元件上說明其變化和狀態 讓這份文件即使不經由說明也能夠讓人理解所有元件的操作與畫面組成 註解說明通常有幾大類 過場動畫 特效 像是視窗是由右往左推 還是從下方往上浮現 是左右翻轉還是撕去一頁的擬真動畫 這部份如果沒有明確指示 RD 就得依照自己的想像製作 極有可能不是原本規劃人員心裡想的那個樣子 也有可能製作這樣的特效需要花費更多的時間 礙於時程沒辦法製作 越初期決定這些細節越能節省開發成本 所以在 Wireframe 上就要清楚註明 畫面操作 Table View 內建手指往左划動 該欄位會出現刪除按鈕 手指將列表向下拉即重新整理 雙手指是否可在圖片上放大縮小等等 各種操作導致畫面變更 怎麼變更的方式都需寫明 視窗種類 新開的視窗是 Popover Alert 還是 Model Window 雖然畫面一看就知道 但還是標記一下吧 狀態改變 電話功能在 iPod 上無法使用 所以要偵測機型 在 iPod 隱藏播打電話的按鈕 或是地圖搜尋到一半網路突然斷線 檔案下載到中途就失去連線等等 各種突發狀態會影響 App 的功能與操作 在這種情況下的畫面顯示也需在畫 Wireframe 時就考慮進去並詳細說明應對方法 本文中的 Wireframe 圖片上其實省略很多說明文字 真的要寫是寫不完的 有些 UI 設計師會把 Wireframe 串成很大一張 Flow 這能快速了解每個頁面的層級順序 但這對 RD 來說就是個吃效能的怪物 Wireframe 結合 Flow 的圖片尺寸非常非常大張 要從這麼大張的圖找到其中某一格是自己想看的那頁很困難 負責刻介面的 RD 比較長時間盯著其中一頁在工作 而不是對著整大張 Flow 圖滿畫面亂跑 上面這張 Flow 原始對應的 App 只有14個頁面左右 在沒有任何文字說明的情況下 圖檔原始尺寸就已達 1260x3358px 如果把 Wireframe 結合 Flow 的作法套用在更複雜的 App 介面設計上 再加上說明文字等等 相信這張圖會大到沒有人想去開它 看著圖上標示的去執行 即使 RD 必須照著 Wireframe 工作 好幾位 RD 跟我抱怨過 為什麼 UI 設計師老愛這樣做 除了看起來很炫好像很專業印出來可以當壁紙外 開大圖根本就是在為難他們的電腦 其實我也不知道 我的電腦效能不太好 Lag 過後就學乖了 立刻捨棄這種大圖作法另尋解決方案 所以每一頁 Wireframe 都需要編號的原因在這裡 RD 可以把純文字版的 UI Flow 當成是目錄 對照編號找到 Wireframe 只需開啟一張單頁 Wireframe 圖檔和一張文字版的 Flow 圖檔 這兩張圖尺寸都不大 不僅節省電腦效能和閱讀圖片時間精力 更能讓 RD 專注在寫 Code 這件事上 Posted by Akane Lee November 16 2013 Wireframe ux UI 初學者 Tweet Comments Please enable JavaScript to view the comments powered

    Original URL path: http://blog.akanelee.me/posts/159788-what-is-wireframe (2016-05-02)
    Open archived version from archive

  • 為什麼要畫3次 Wireframe? « 嫁給RD的 UI Designer
    靈光一閃和降乩差不多 要如何在被繆斯女神附身的短短時間將腦海中的靈感記錄下來 靠的是鬼畫符orz 管不到細節 先抓住大方向 畫草圖時間搞不好只有20分鐘 總是要先有粗糙版的 UI Flow 才能慢慢修改到完整 既然目的只是紀錄靈感和順 Flow 用 通常我會拿背面空白的廢紙塗鴉 Bamboo Paper Notebook 是我目前最喜歡的靈感記錄 App 不管是寫字或是繪圖都十分好操作 還能同步 Evernote 當備份 畫得醜沒關係 自己看得懂就好 在會議上邊聽大家的提議 隨手畫出想法好跟與會人員討論用的亂撇 Wireframe 第二次能說是精稿 注意每個元件的比例和位置合理性 從只有自己看得懂的鬼畫符 整理重畫成可以拿給 RD 和 PM 看的圖並和他們討論要修改的地方 如果負責寫 Code 的 RD 說沒空陪你討論 就恐嚇他 有經驗的RD 一定比 UI 關心介面配置合理性和每個畫面串接的邏輯 這關係到他們未來要天天加班還是準時回家打電動 重畫一次 Wireframe 能補完剛剛沒想到 被無視的部份 加上簡單文字說明 此時整個 Flow 又被順了一次 不合理的地方會因為對這個 App 架構的熟悉度增加而被找出來 和 RD 討論實作可行性時 現場修改也容易 如果能夠提升這個階段的製圖速度 遇到有爭議的時候 直接畫給對方看 專業度立刻大增 對外行人來講亂威一把的 可以預期客戶音量會越講越小聲 尤其是把紙筆推給對方 請他把他想像中的介面畫出來的時候 有些客戶甚至會當場消音 某次和老公討論字級表的 Wireframe 嫌太複雜要再修改 第三次就是完稿 當 RD 和 PM 都說沒問題後 在電腦上使用軟體將框線勾勒出來 並加上文字說明 給客戶簽約用的規格書如果需附上 Wireframe 的話會是這個版本 熟一點的好客戶可以拿手繪稿跟他們討論 但最終還是要進電腦 將手繪稿電子化有個好處 即使將檔案交由他人接手一樣能夠修改 維護 未來遇到類似介面直接拷貝修改 加快工作速度 會使用 Axure 或 Balsamiq 來製作電子稿 這兩套都是很多人使用 業界滿知名的軟體 各有優缺點 網路上有很多教學和資源庫 上手容易 不過這件事通常被我塞給工讀生去處理了 遠目 才擁有更多時間處理下個 Case 但遇到複雜 規模較大的產品還是會自己動手 繪製的過程中多少能發現需要改進的地方 花一點心思讓產品更完美沒什麼不好 可比對本文第一張圖 將整理過後的構想定版 講了這麼一大篇 好像有 Wireframe 就往順利結案踏出一步似的 別傻了 我相信 80 以上的客戶看不懂 Wireframe 逼他看還會被嫌醜 嚴重質疑專業 這種客戶在請他確認介面時什麼都好 等到定版 交規格書 約都簽了 連 PSD 都做得差不多後才開始 GGYY 囉哩囉嗦 加新功能加特效別人有我們也要有 Wireframe 主要是給 RD 看的 省得沒什麼想像力 和設計師比 的 RD 要靠降乩在刻介面 如果肯定這個 Case 結案後再也見不到它 手繪稿撇一撇 說明文字寫一寫 你家的好人 RD 說好就好 Posted by Akane Lee November 16 2013 Wireframe ux UI 初學者 Tweet Comments Please enable JavaScript to view the comments powered by Disqus comments powered by Disqus UI 和 RD 什麼是 Wireframe Akane Lee Recent Posts UI 設計入門班 學員心得 UI UX 吃貨群 2016 年 4 月書櫃 UI 設計師看 Auto Layout

    Original URL path: http://blog.akanelee.me/posts/159795-three-times-wireframe (2016-05-02)
    Open archived version from archive

  • UI 和 RD « 嫁給RD的 UI Designer
    之前就遇到這種神人 開口跟他說 Guidelne 上不建議這樣做 神人回一句 那是賈伯斯訂的又不是我 Guideline 太死板那是初學者在看的 我覺得就是應該 實現這個 UI 是 RD 的工作 老天保祐他們 之前看過 RD 對 UI 嗆聲 UI 開口閉門就是 我覺得 然後被 RD 酸到淚奔 不是我 這時候就是 Guideline 出場的最佳時機 如果可以請把 Guideline 看得比 RD 熟 當然在設計開發上也以 Guideline 優先 不只是給自己一個背書 一條退路 面對和自己意見不同的場合 可以大聲且理所當然的說 這是遵守 Guideline 所做的設計 對付 RD 就是要佔盡 理 這個字 比他們講道理就贏了 和老公吵架的心得 當然也是有客戶 RD PM 反問 你怎麼沒有自己的意見 這時候可以秒回 Guideline 是多少高人組成的團隊做了無數實驗訂定的精華 同時也是使用者最熟悉的操作方式 我能做的就是基於 Guideline 之上將功能化為可操作的介面 如果對方還囉嗦 就說好啊我改 可是要加時間 加錢 喔 加錢加時間是大絕 客戶怕加錢 PM 怕加時間 RD 也怕加時間XD 我很堅持 不該只是使用者覺得好用 連 RD 都該覺得好寫才稱得上是好 UI 簡單的 UI 不只使用者容易上手 通常邏輯也簡單 邏輯簡單表示 RD 也會輕鬆點 較不易出錯 QA 也不用一測再測 時程壓力小 PM 也不會天天被客戶追殺 有能力設計出大家都開心 大家都滿意的 UI 就不要為難同事了吧 大家都是出來混口飯吃的 即使台灣這個大環境不重視設計 也不能因此覺得自己不重要 UI 設計包含的層面太多 要學習研究的範圍也太廣 胡搞一通就是害到工作流程排在你後面的 RD 好人 RD會含淚加班搞定你捅出來的邏輯不通大洞 資深的 RD 會拿著 Wireframe 和 Flow 把你罵到淚奔 因為現在不是你 UI 哭 等客戶確認一切定案後就換他 RD 哭了 受邀去某公司介紹 UI時 有遇過開口閉口都喊我 美工 的 RD 一時沒反應過來很順的反問 打字工你在叫我嗎 嫁給RD的壞處之一 整天都在嘴砲練得牙尖嘴利 這 RD 一定沒吃過UI的苦頭 百分百是剛出社會的小雛鳥 UI 要整 RD 是很簡單的事 來幾個炫麗繁複的過場特效 即時運算邏輯複雜的動畫等等 就夠 RD 整顆頭抱著燒了 開發時程不能延 就在前期規劃大幅提升他們的開發難度吧 基本上 RD 都是些不錯的好人 通常單純好騙不善鬥爭 也不太會抱怨 至少我遇到的RD大部份都是這種類型 偶爾缺根筋在奇怪的地方出糗這樣 我老公腦袋一定被門夾過 看在 UI 設計不佳是由他們來收拾善後 設計師們請對工程師好一些吧 Posted by Akane Lee November 14 2013 個人經驗 Tweet Comments Please enable JavaScript to view the comments powered by Disqus comments powered by Disqus 三年前 三年後 為什麼要畫3次 Wireframe Akane Lee Recent Posts UI 設計入門班 學員心得 UI UX 吃貨群 2016 年 4 月書櫃

    Original URL path: http://blog.akanelee.me/posts/159759-ui-and-rd (2016-05-02)
    Open archived version from archive

  • 三年前,三年後 « 嫁給RD的 UI Designer
    2 年累積超過 30 個 app 網頁作品 紮紮實實被 RD 和 PM 磨練 我的 UI 基礎是 RD 教的 就是那位每晚和我搶棉被的傢伙 三天兩頭就被罵 妳的腦袋有洞嗎 妳腦子是進水了喔 妳的腦容量只有骰子這麼大嗎 設計師的思考和工程師的邏輯根本南轅北轍 套句我的指導教授 她也嫁給 RD 的話 RD的眼睛不是長在頭頂上 是頭上伸出觸角 根本長在觸角上 奇怪為什麼我還會嫁給他 就因為 UI 基礎建立在觸角星人身上 所以和其他從視覺或平面轉行做 UI 的設計師不一樣 即使不懂程式怎麼寫 我仍然知道這個需求需要什麼樣的功能或特效 對於 RD 而言會不會很難搞 大概需要多少時間等等 偶爾面對客戶的時候 還可以幫 PM 擋需求 對客戶來說 增加需求就跟再來一杯白開水一樣 Free Html CSS也是這段時間被磨出來 對 RD 而言 設計師用 Photoshop 產出 Html 叫做 邪魔歪道 用 Dreamweaver 內建功能填填數值那種 叫作 不優雅 在全公司幾乎都是 RD 只有我這麼一位設計師的情況下 寡不敵眾 只好乖乖的練手寫 Code 死亡打字員真是款練英打的好幫手 麻煩的是 這兩年都把技能點數投在 UI 實戰上了 視覺這塊幾乎原封不動 偏偏大眾第一眼看到的不會是好不好操作 而是精美漂亮的視覺 這就回歸到一個問題 我總覺得台灣人其實不重 也不想去懂 UI UI 只是個很潮的口號 遇到不少客戶驗收的方式是 左手邊擺支 iPhone 右手邊擺 Android 按一下 iPhone 按一下 Android 嗯 兩邊畫面長一樣 很好 誰能告訴我 為什麼 Android 介面要和 iPhone 一樣 為了 Cost Down 還硬要把 iPhone 的內建元件放到 Android上 前陣子在找新工作的時候遇到一位天才面試官 他直接跟我說 在設計介面的時候不需要考量 Android 實體的 Back 和 Menu 鍵 直接無視就好 妳看 iPhone 就沒有這兩顆 Android 介面本來就要跟 iPhone 一樣 使用者是需要教育的 要讓他們習慣這樣子的操作介面 有人質疑這是對方說反話 我確定不是 這幾點我跟他辯了很久 還問他 你是認真的還是說反話 對方還覺得我莫名其妙怎麼這樣問 真心祈禱這種觀念不會是常態 UI 包含的領域太廣 又很容易和 UX 混淆 踏入 UI 領域的 1000 個日子 越深入就越覺得這個領域肯定會越來越被重視 科技始終來自於惰性 老實說 我覺得讓使用者方便 讓使用者可以更偷懶 我也不過是在從事一行如何讓大家不用大腦的行業罷了 Posted by Akane Lee November 13 2013 個人經驗 Tweet Comments Please enable JavaScript to view the comments powered by Disqus comments powered by Disqus UI 和 RD Akane Lee Recent Posts UI 設計入門班 學員心得 UI UX 吃貨群 2016 年 4 月書櫃 UI 設計師看 Auto Layout 讀者來信 UI 設計流程

    Original URL path: http://blog.akanelee.me/posts/159742-three-years (2016-05-02)
    Open archived version from archive

  • 嫁給RD的 UI Designer
    2016 Comments 我買了 Simon Ng 寫的 iOS 9 App程式設計實力超進化實戰攻略 Beginning iOS 9 Programming with Swift 學習怎麼用 Xcode 和 Swift 做 App 這本書非常推薦設計師和完全不懂程式的初學者購買 前幾章都在講 Xcode 的 GUI 操作和實例 跟著範例自己做個會動的頁面出來很有成就感 能學到很多 Read on 讀者來信 UI 設計流程 March 28 2016 Comments 收到一封 Mail 其中提到幾個關於設計流程和 Prototype 的問題 UI設計流程 Wireframe 低保真Prototyple Mockup 高保真Prototyple 這樣的流程是對的嗎 根據上過課的學員回應 以及自身經驗 目前業界的情況大多是 UI 設計師收到 開工啦 的通知 然後就從 Wireframe 開始下手 使用者怎麼操作 有哪些功能 使用者和客戶的需求是什麼往往靠 PM 簡單口述 Wireframe 為什麼會長這樣 在 Wireframe 之前還有哪些事要做 全部都靠通靈 所以執行專案期間都在改來改去 撐到最後一天總是可以結案就解脫了嘛 再開始下個改來改去的輪迴 Read on 關於媽祖繞境 March 23 2016 Comments 我看了這個新聞 直擊 魏應充兄弟跪求鑽轎 白沙屯媽閃開 頓時好奇了起來 媽祖娘娘是怎麼指示抬轎人不給魏應充兄弟鑽的 如果是抬轎人的自主行為 就和媽祖無關 如果是媽祖指示 她怎麼指示的 不太理解 Read on 如何挑選 UI UX 設計課程 March 7 2016 Comments 收到太多這類的私訊或 Mail 問 A 補習班好不好 B 課好不好 C 班好不好的 一併在此回答 自己判斷啊 因為我自己有開 UI 入門班 這文寫起來很業配 怎麼看都像是在貶低別人 自抬身價 明知道我有自己的班還扔其他單位的開課訊息問意見的人真不知道在想什麼 想從我口中得到什麼答案 Read on 上課心得 Rails 商務網站 x 即戰力 2016 春季班 二班 March 2 2016 Comments 補充 UI UX 設計師在工作上不會用到 Rails 這是個人學習 寫程式也不是我的興趣 只是覺得先學起來放 而且學得很痛苦就是了 非常不適合完全外行的初學者來上這門課 除了打一堆指令碼外 不主動纏著助教問是不會懂 為什麼 外加初學者嫩到就想問問題都不知道從何問起 只能從背指令開始 UI UX 設計師為什麼要來學寫程式 自己要先想清楚啊 去年年底我就報了這個班 Rails 商務網站 x 即戰力 2016 春季班 二班 三月 by Xdite 聽說 5 小時就賣光了 下一班很多 UI UX 設計師報名 這不是重點 重點是 如果你不做課前練習 設計師 100 掉隊跟不上學習進度 Read on 情人節禮物 DIY 3 Star Wars 紙模篇 February 10 2016 Comments 看到這張圖大概就知道我幹了什麼事吧 對 因為老公是星戰迷 所以我做了一隊白兵 Darth Vader 給他 Read on 情人節禮物 DIY

    Original URL path: http://blog.akanelee.me/?page=1 (2016-05-02)
    Open archived version from archive