引用「Why Johnny can’t build a decent user interface.」

Most user interfaces are poorly designed. This is so widely understood that it’s become a common humor trope.

For instance, from xkcd:



And from Dilbert:




Funny because it’s true.

So why do most user interfaces suck?

In my experience, it’s usually a combination of these reasons:

A self-serving agenda. The person designing the interface often has an agenda other than helping out the users. The above xkcd comic illustrates how most universities are more interested in glorifying themselves than in helping visitors find the information they need. Another example is the web designer who wants to show off his mad skillz at web programming technologies, and packs the web page with enough flashing Disneyesque eye candy to send the casual visitor into transports of epilepsy. (See Web Pages That Suck for some examples, unless you’ve just had breakfast.) The designer has let his/her ego take precedence over the users’ needs.

Intellectual arrogance. Many programmers have a gross overconfidence in their ability to design user interfaces. As I discussed in this post, incompetent individuals tend to overestimate their abilities and fail to recognize their inadequacies. Just because someone can write good code does not mean he/she can design an effective user interface. The common attitude among many programmers that the user interface is “just more code” can contribute to this arrogance.

Lack of ability. (This one often goes hand in hand with the preceding.) In my experience, good user interface design involves a lot of inherent ability: you can either design pretty good interfaces or you can’t. If you naturally suck at it, a human factors degree and all the latest UI design books won’t help much — and may just instill a sense of false confidence (again, refer to the preceding point).

Lack of intellectual empathy. Many people lack the ability to see things fairly from the viewpoints of others–specifically, in the case of user interfaces, to put oneself in the place of a user. This can especially be the case for those developing software in user domains with which they are not familiar (e.g., a programmer with no medical background developing clinical database applications).

A disregard for human factors. It’s been my experience that human factors engineers tend to get marginalized. Most organizations that develop interactive software don’t even hire human factors engineers, and most software engineers don’t understand the value of true human factors engineering — in particular the cognitive psychology and human-computer interaction expertise that human factors engineers bring to user interface design.

The wrong kind of mentality. I’m admittedly generalizing here quite a bit: Database programmers tend to have a data-centric mentality, and build data-driven applications organized around the way the data is modeled and stored. C/C++ programmers who build desktop apps tend to have a functionality-centric mentality, and build applications organized around the capabilities implemented. Web programmers can have a technology-centric mentality (as described under “the wrong agenda” above) or sometimes a content-centric mentality, and build sites organized around providing access to content. These are all the wrong mentalities.

The right mentality is a user-centric mentality. User interfaces should be designed from a mentality that focuses on the users and the work they must accomplish.

When building user interfaces, developers should research the answers to the following questions:

Who are the users? What are their abilities and backgrounds? Are there different groups/types of users, and how do they differ? For example, a church website has two distinct user groups: (1) current members, who are coming to the website for “insider” information (when is the next choir practice?); and (2) potential new members, who are visiting the website to find out more about the church.

What are their goals? What is it that users are trying to accomplish when they sit down to use the system?

What are their tasks? What tasks do users have to perform in order to accomplish each goal? How do these tasks decompose into subtasks? What is the sequencing and dependencies between these subtask?

And what are the information needs of these tasks/subtasks? At each step of the way, what does the user need to see on the screen in order to perform the tasks/subtasks – in particular those involving decisions? This, more than anything else, should drive the way the user interface is designed.


引用來源：http://jeffreyellis.org/blog/?p=8897

Reading：平面設計創意workbook(未完成)

書名：平面設計創意workbook--創意+技術+溝通=讓人無法拒絕的好設計作者：Mark Oldach 出版社：原點出版 Uni-Books 出版時間：2009年5月 ------------------------------------------------------------------------------------- 一、掌握訊息

• 開放地思考

1. 創造出真正原創性、焦點清楚的妥當想法，關鍵在於從零開始，沒有預設，接納任何資訊。


2. 身為設計人，任務就是打開客戶和觀眾的想法，帶給他們意想不到的驚奇。

• 掌握創意流程

1. 成功的設計師會從客戶理解的角度去呈現他的想法，讓客戶贊同他的理念，並提供適當的舞台實踐他的創意。要達成此目標，必須知道你的客戶是誰，瞭解他們的需要，建立關係，讓你的想法到他們的期望值。善加處理客戶的期待是建立良好關係的關鍵。

• 瞭解你的客戶是誰

1. 想辨法接觸到真正的決策者，離決策者越近，設計提安越容易成功。


2. 最有效的進展流程溝通方法就是透過提案企劃書，簡述以下事項：

• 專案發展階段


• 每階段參與的人員及工作內容


• 每階段預期的結論

二、讓如何讓客戶接受創意

1. 接收資訊->組織資訊


2. 永遠繞著客戶的意見發問，而不要去批評客戶。


3. 客戶越清楚解決方法取決於目標、影響參數、事實等，越能接受你所強週的邏輯和你最終要呈現的成果。

• 顧客是創意把關者

1. 千萬記住!要好好把握與客戶的第一次會面。


2. 如果你能有效掌控訪進行，便能幫客戶以更客觀的新觀點去剖析問題。以下是幾種打開話匣子的方式：

• 您想表達什麼內容?為什麼?


• 誰需要這些資訊?為什麼?


• 什麼是觀眾已經知道的?他們還需要知道什麼?


• 觀眾看完後應該獲得什麼重要的焦點訊息?


• 為了傳達這些訊息，過去你做什麼樣的努力?


• 預期觀眾的反應為何?你打算如何回應?


• 觀眾會從貴公司黃他的形式活動或媒體得到相同的資訊嗎?還是得從黃他組織的活動中獲得?


• 觀眾是否想要得到這項資訊?或者他們根本不想要?他們在乎嗎?

1. 在討論過程中，為了有效達成任務，記得要：

• 聆聽


• 注意客戶的用語、見解和知識


• 以客戶的用語提問


• 如果不懂就要問清楚


• 寫下重點，但不要分散聽力


• 挑戰客戶的成見


• 不要馬上就想解決問題


• 鼓勵所有參與評量設計的人員與會


• 晤談後馬上紓壓

• 如何面對客戶的期待

1. 創意流程中，完全把客戶排除在外，將註定失敗。


2. 在創意發展的過程裡，應該要：

• 和客戶談，無論親自登門拜訪或打電話。讓他明白你的想法、進度、遭遇的問題。


• 讓客戶參與你解決及分析問題的過程，測試你的想法並取得回應。


• 暗示你會採取的方法。


• 繼續協助客戶準備好接受意料外的解決方案，告知客戶你的辨法可能需要用新思維看待問題。

paper prototype

"In human–computer interaction, paper prototyping is a widely used method in the user-centered design process, a process that helps developers to create software that meets the user's expectations and needs - in this case, especially for designing and testing user interfaces. It is throwaway prototyping and involves creating rough, even hand-sketched, drawings of an interface to use as prototypes, or models, of a design. While paper prototyping seems simple, this method of usability testing can provide a great deal of useful feedback which will result in the design of better products. This is supported by many usability professionals."

Reference：
http://en.wikipedia.org/wiki/Paper_prototyping

延伸閱書：
Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces

Reading：優使性2.0(Usability 2.0)-網站經驗設計與使用者研究(未完成)

書名：優使性2.0(Usability 2.0)-網站經驗設計與使用者研究
作者：魏澤群
出版日期：2007年8月初版
-------------------------------------------------------------------------------------
1.優使性(Usability)是一種從使用者角度進行思考的設計概念。
2.國際標準組織 ISO(International Organization for Standardization)的定義，優使性是能讓使用者在有效率並感到滿意的情況下，完成某些特定工作的一種特性(Usability is the “effectiveness, efficiency and satisfaction with which a specified set of users can achieve a specified set of tasks in a particular environment.”)。
3.Jacob Nielsen曾經針對網站設計的優使性提出五個特性：學習度、使用效率、記憶度、錯誤率、滿意度。
5.使用者中心設計(User-Centered Design ,UCD)有兩個重點：
(1)在設計的初期就必須將設計的焦點著重在使用者及使用任務上。
(2)UCD是一種不斷進行測試、改進的設計流程。
6.UCD為一種設計哲學或是理念，以UCD理念進行設計的工作者，會運用有系統的方法及流程，讓設計出來的產品符合使用者的需求，而非讓使用者來適應產品。

眼睛保養

眼睛是靈魂之窗，如何保養?

1.眼睛疲勞
搶救方法如下：
（1）定時休息，多看遠物。
（2）疲勞時，閉眼熱敷3分鐘。可用熱毛巾敷，或將雙手搓熱，再輕放在眼睛上。
（3）輕輕按摩眼睛骨，能放鬆眼睛肌肉，也可促進血液循環。

2.隱形眼鏡的傷害
搶救方法如下：
（1）多眨眼睛，用淚水滋潤眼睛。
（2）縮短配戴時間，建議1天不超過8小時，但很多上班族無法做到，所以原則可折衷為能不戴就不戴，例如回家立刻拔掉。
（3）點人工淚液補充水分，建議1天次數不超過5次。
（4）感冒或眼睛發炎就不戴。

3.眼睛過敏
搶救方法如下：
（1）避免過敏原是首要之道，少出沒在空氣汙染嚴重地方，或沙塵暴季節少出門。
（2）眼睛過敏時，不要熱敷或揉眼睛，反倒要冰敷，可協助緩和過敏症狀。
（3）點抗過敏眼藥水，但不可自己隨意買、隨意點，最好經過專業醫生認可再使用。

4.中年眼疾
搶救方法如下：
（1）立刻就醫。
（2）治癒後，心情要放輕鬆。


參考來源：
http://www.blogger.com/post-edit.g?blogID=849587947382570780&postID=1677750719308052230
http://blog.sina.com.tw/stanhaki/article.php?pbgid=31701&entryid=572903