10個對開發者很是有用的設計原則

要點:我會盡力解釋Jakob Nielsen的10設計啓發式算法。我會用例子告訴你,做爲一名開發人員,如何使你的產品以及你產品背後的代碼更加有用。php

爲何我要在意這些?

開發者也是設計師,他們只是使用不一樣的媒介。程序員

所以,你知道如何設計系統也是你的最終產品的一部分。算法

關注於把底層設計的更加有用將會幫助肯定如下事情:網絡

  • 對新加入的開發人員更容易上手
  • 系統的可維護性及更改時的簡易性
  • 做爲這個系統的一名開發者,你是多麼的有效率

當我與開發者一塊兒工做的時候發現,這些觀念已經在程序員之中存在了–只是他們尚未把這個表達給設計師。還有不少須要去作,可是基礎已經存在了,這難道不是好消息嗎?學習

在個人例子中並無任何實際的代碼,由於我以爲人們對於編寫任何軟件的正確方式都太敏感了。網站

像設計師同樣,程序員喜歡運用他們的創造力來解決複雜的問題。而我寧願你考慮一下下面關於設計系統的規則,而不是按照一組嚴格的規定來講「這是解決XX問題最好的方法」。spa

設計啓發式是 什麼?

啓發式只是經過你的經驗中學習。它是用於查找在用戶界面的易用性問題,使得它們能夠參加到做爲迭代設計過程的一部分的方法。命令行

咱們獲得3-5個啓發式設計的專家來使用咱們的產品,並判斷它是否符合最基本的可用性規則,即「10設計啓發式」合規,這是啓發式的簡化。翻譯

下面讓咱們開始吧。設計

1. 系統狀態的可視性

曾經上傳圖像到一個網站?好比說一個社交網絡的頭像?

主要的原則是要使你始終能夠了解上傳的狀態。上面的例子只是告訴你上傳的狀態。而看到它的進步使用戶更加舒服,你不以爲嗎?

圖片描述

2. 系統和現實世界之間的匹配

當寫文檔或命名一個組成部分,始終嘗試使用熟悉的術語。瞭解目標用戶是誰,而後使用他們熟悉的單詞、短語和概念。

3. 用戶控制和自由

圖片描述

系統應該容許你自由去探索其內容,可是以一種更加負責的方式,應該讓你能夠從你可能犯的錯誤中進行恢復。好比說支持「撤銷」與「重作」。

4. 一致性和標準

蘋果和微軟都對「肯定」和「取消」按鈕的順序有不一樣的意見。哪一個更好?

圖片描述
圖片描述

都很差或者都好?固然,這並不重要,重要的是你要確保全部用戶交互系統的一致性。

要作到這一點,你就不該該讓你的用戶困惑,爲何不同的單詞、不同的環境或者操做確獲得相同的結果。

5. 錯誤的預防

在錯誤可能發生的第一個位置阻止錯誤是很是重要的。

當咱們一開始的時候,就有QA人員來尋找產品中的缺陷以保證產品質量。而後把他們放到生產線上,讓他們指出如何在第一道工序開始就作出沒有缺陷的產品。你會驚訝於這樣的效率是多麼的高,當你作的東西中的缺陷在第一時間被發現而不是到最後才被發現。

— Mary Poppendieck

6. 可識別性

顯示出提高用戶可用性的標識,這是另外一個有幫助的內容。

CLI(命令行接口) 是一個徹底無視這一原則的最好的例子,經過這樣,它演示了優雅(它用靈活性與效率來彌補了它所缺乏的)。

7. 靈活性和使用效率

在你的系統上提供一個潛在的、隱藏的層,來幫助有經驗的用戶經過「噪聲」,變得更加有效率。

Cli 就是這樣一個「隱藏」界面的功能是能夠多麼強大的例子(咱們甚至能夠選擇擴展)。

8. 簡潔

最初被列爲「審美和簡約設計」。這一原理是關於提升信噪比的。

你提供給用戶的全部數據都要有必定的約束–是否有臃腫的HTTP請求的佔用帶寬、充滿缺陷的API、以及須要太多請求的交互界面。

儘可能用最小的輸入,得到最大的產出。

9. 幫助用戶識別、診斷和從錯誤中恢復

錯誤消息應該用平實的語言表達(沒有代碼),精確顯示問題,建設性地提出一個解決方案。對用戶是有用的。而且提供一個解決方案。

就像 這樣

10. 幫助和文檔

在設計原則的列表中看到這一項,我和你同樣感到驚訝。

即使沒有文檔也可使用的系統,最好也仍是要提供幫助和文檔。任何此類信息都應該易於搜索,關注用戶的任務,列出具體的進行步驟,並切不該該太大。

總結

我但願這對你是有幫助的。若是你有任何問題或見解,請留言。

via:medium譯文地址。本文由 Specs 翻譯整理,發佈在 Coder資源網,轉載請註明來源。

相關文章
相關標籤/搜索