談 UX 設計師的文字技術力

圖文:獸群之心/Soking

談 UX 設計師的文字技術力

這篇文章我想記錄在 UX 設計工作我在哪些地方大量運用了文字相關的技術,許多習慣源於我在新媒體領域工作時期,除了當 PM 外,還兼任社群營運、媒體編輯與採訪記者所磨練出來的文字能力。

如果你希望獲得 Soking 的課程、讀書會以及 UX 講座訊息,歡迎留下你的 Email,訂閱最新的 UX 活動通知:https://subscribe.soking.cc/

我的 UX 專案文件始於文字企劃書

每次 UX 專案開始,我不會先打開設計軟體開始把想法視覺化,而是用文字寫下來所有的一切,因為越早期的想法通常是錯的,文字的修改成本最低。

當我們對一個點子或想法投入越多心血我們就越想去捍衛它,即使大多數時間我們是用在描繪細節而不是確保它是一個有效的需求、設計規格。

例如,我們想想看這樣的一句需求,要花多少時間畫畫面來實現?

用戶可以自行完成線上預約,以挑選適合自己的時段。

如果從畫面出發,線上預約有好多種跟時間有關的介面,我會怕自己一不小心就沉迷於找各種美麗的 UI 來幫助「畫面的發想」。而忘記我一開始必須專注在構思系統的規則以及用戶情境。

尤其人在卡關的時候,特別容易分心用找參考資料的藉口跑去逛網頁。

所以我會像許多年前我還在寫遊戲企劃文件一樣,從文書軟體開始寫作,用老派的企劃文件開始我的產品設計。

記得剛到任遊戲公司的第一週,帶領我們的主企劃告訴我,整個企劃文件的靈魂就是「企劃目標」,沒有問清楚你的企劃目標,後面的規劃都是垃圾。

將資訊視覺化變成 Sitemap、Prototype、Wireframe,反而是建立了堅實的設計理念與想法後,為了跟其他人溝通而作。

擅長現場會議的文字速記

我的打字速度算快,但這沒什麼,經歷過 MMORPG 年代的人都有飛快的打字手速。但我的打字速度感覺快,其實是快在轉譯現場對話的能力。

通常一個專案會議、用戶訪談等等,動輒四十分鐘到兩三個小時。我經常擔任主持會議的人,除此之外,我還會鉅細靡遺的寫下誰講了什麼重點,以及目前議題的進度。

通常會議一結束,我就可以當場略微調整格式,刷刷刷,馬上就把完整的會議內容寄給與會者,人都還沒走出會議室,手機就收到叮咚聲響,熱騰騰的會議記錄來也。

現場打字速記對於掌握會議也有微妙的優勢,通常會議時間一長,話題開始複雜,許多人對於自己先前的意見會忘記、會矛盾,甚至可能對十分鐘前才定案的議題又試圖翻盤(因為他忘記已經充分討論了,可能只記得自己還想發言)。

此時如果有會議即時的紀錄,我可以馬上告訴與會人這個複雜的話題是因為A、B、C的理由,已經有了共識所以才做出了什麼結論。避免自己腦袋讀檔失敗,被牽著鼻子走。(尤其當我指出幾個月前的會議對於某話題的討論脈絡時,與會人往往會大吃一驚。)

打字速記的能力在用戶訪談時特別吃香,我很長一段時間是 UX 獨行俠作用戶研究,約了訪談對象一對一的時候,除了講話引導受訪者以外,基本上不太依賴錄音內容,光靠現場的打字速記我就能建構完整的訪談記錄。

其實這個能力從在新媒體工作時期就磨練出來了,活動採訪或者大型演講的紀錄都要搶時間儘快發佈,如果在現場就完成七八成完整度的速記內容,稍微修潤一下,馬上就可以出刊,不用等到隔天回公司才慢吞吞的出稿。

討論系統功能分類或Tag使用的標籤文案

當過編輯的人應該都有類似的毛病,如果看到一個分類語意含糊不清,不知道這個字詞實際上應該指向哪些內容,就會覺得渾身不舒服,非要再多討論幾個字詞把它換掉不可。

處理分類真的是 UX 設計師一個超級無敵重要的工作,而這件工作關乎於文字的敏銳度。例如「查看旅程」跟「查看飛行計畫」,會不會感覺能在旅程中看到飛行計畫呢?

但討論分類這件事情最困難的是整合利害關係人的認知,像我曾經待的新媒體業,開會的同事基本上都是編輯,你如果拿著網站分類或系統類別的功能性名稱的命名問題去問他們意見,基本上就會像炸了馬蜂窩一樣,各式各樣的意見非常難統合。

關於分類的研究,我讀過一個很有趣的實驗結論(出處忘了),人們只需要看似合理的分類架構就可以,任何一種分類邏輯都沒有特別明顯的優勢。即使是對於分類最龜毛的人,給他一個乍看之下有道理的分類,即使不滿意他還是能使用。

使用真的假文案

我看過許多 wireframe 上面充滿了假字,我說的假字可是真的就複製貼上「假字假字假字假字假字假字假字假字」,讓整個畫面假的不能再假。

這事情在老外那邊叫做「Lorem ipsum」因為他們最有名的假文字段落開頭就是這兩個沒意義的單字。

假文案無助於解讀,大家會看不懂情境脈絡

在我們家的 wireframe 上,要求必須要填寫客戶最後可能使用的真實文案。即使那些文案不是系統功能的按鈕、提示文字等等。

表面上看起來好像作 UX 設計的怎麼還要幫客戶寫文案的感覺?但實際上,如果我們在 wireframe 上面沒辦法寫符合情境的文案,這代表我們對於用戶要看到的資訊,一定還有很多不了解的地方。

換個角度來說,如果我們寫了自以為符合情境的文案,但客戶或上面老闆皺著眉頭跟你說方向不對,那是不是前面對於使用者的認知有了溝通落差呢?

功能規格一樣,但文案換上有情境的文字

有很多次我們在寫介面上的假文案時,發現客戶對於我們願意花時間理解他們的產業感覺開心,即使最後那些文案沒有採用,但在會議上客戶的態度會開始轉變,把我們當做同行,用自己的人術語在討論。

這是寫文案的另外一個小技巧,學著用客戶的慣用語、業內行話來溝通,並且寫在他會看到的地方,讓利害關係人覺得熟係親切,而不是看到一大堆陌生冰冷的介面文案。

結論

我覺得這些個人工作上常用到的文字技巧跟一般在討論的 UX 文案不太相同,雖然大概也算在 UX 寫作的範疇吧。文字運用的好,有很多促進認知、幫助設計專案的地方。

其實每次開專案時我都夢想著,如果這次能少畫點圖就好了(被打)。

或許本質上我還有個文字工作者的靈魂。

感謝你閱讀我的文章,喜歡這些 UX 工作話題的話,幫我多拍些手兒。如果想私下多聊聊 UX 工作話題,也可以加我 FB 好友

本文由 獸群之心 / Soking 授權轉載,原文連結

瀏覽 1,265 次

覺得不錯的話就分享出去吧!

發佈留言

Back to top button