10个对开发者非常有用的设计原则

标签: 开发者 设计师 原则 | 发表时间:2015-08-08 17:05 | 作者:Specs
出处:http://segmentfault.com/blogs

要点:我会尽力解释Jakob Nielsen的10设计启发式算法。我会用例子告诉你,作为一名开发人员,如何使你的产品以及你产品背后的代码更加有用。

为什么我要在乎这些?

开发者也是设计师,他们只是使用不同的媒介。

因此,你知道如何设计系统也是你的最终产品的一部分。

关注于把底层设计的更加有用将会帮助确定以下事情:

  • 对新加入的开发人员更容易上手
  • 系统的可维护性及更改时的简易性
  • 作为这个系统的一名开发者,你是多么的有效率

当我与开发者一起工作的时候发现,这些观念已经在程序员之中存在了–只是他们还没有把这个表达给设计师。还有很多需要去做,但是基础已经存在了,这难道不是好消息吗?

在我的例子中并没有任何实际的代码,因为我觉得人们对于编写任何软件的正确方式都太敏感了。

像设计师一样,程序员喜欢运用他们的创造力来解决复杂的问题。而我宁愿你考虑一下下面关于设计系统的规则,而不是按照一组严格的规定来说“这是解决XX问题最好的方法”。

设计启发式是 什么?

启发式只是通过你的经验中学习。它是用于查找在用户界面的易用性问题,使得它们可以参加到作为迭代设计过程的一部分的方法。

我们得到3-5个启发式设计的专家来使用我们的产品,并判断它是否符合最基本的可用性规则,即“10设计启发式”合规,这是启发式的简化。

下面让我们开始吧。

1. 系统状态的可视性

曾经上传图像到一个网站?比如说一个社交网络的头像?

主要的原则是要使你始终可以了解上传的状态。上面的例子只是告诉你上传的状态。而看到它的进步使用户更加舒服,你不觉得吗?

图片描述

2. 系统和现实世界之间的匹配

当写文档或命名一个组成部分,始终尝试使用熟悉的术语。了解目标用户是谁,然后使用他们熟悉的单词、短语和概念。

3. 用户控制和自由

图片描述

系统应该允许你自由去探索其内容,但是以一种更加负责的方式,应该让你可以从你可能犯的错误中进行恢复。比如说支持“撤销”与“重做”。

4. 一致性和标准

苹果和微软都对“确定”和“取消”按钮的顺序有不同的意见。哪个更好?

图片描述
图片描述

都不好或者都好?当然,这并不重要,重要的是你要确保所有用户交互系统的一致性。

要做到这一点,你就不应该让你的用户困惑,为什么不一样的单词、不一样的环境或者操作确得到相同的结果。

5. 错误的预防

在错误可能发生的第一个位置阻止错误是非常重要的。

当我们一开始的时候,就有QA人员来寻找产品中的缺陷以保证产品质量。然后把他们放到生产线上,让他们指出如何在第一道工序开始就做出没有缺陷的产品。你会惊讶于这样的效率是多么的高,当你做的东西中的缺陷在第一时间被发现而不是到最后才被发现。

— Mary Poppendieck

6. 可识别性

显示出提升用户可用性的标识,这是另一个有帮助的内容。

CLI(命令行接口) 是一个完全无视这一原则的最好的例子,通过这样,它演示了优雅(它用灵活性与效率来弥补了它所缺少的)。

7. 灵活性和使用效率

在你的系统上提供一个潜在的、隐藏的层,来帮助有经验的用户通过“噪声”,变得更加有效率。

Cli 就是这样一个“隐藏”界面的功能是可以多么强大的例子(我们甚至可以选择扩展)。

8. 简洁

最初被列为“审美和简约设计”。这一原理是关于提高信噪比的。

你提供给用户的所有数据都要有一定的约束–是否有臃肿的HTTP请求的占用带宽、充满缺陷的API、以及需要太多请求的交互界面。

尽量用最小的输入,获得最大的产出。

9. 帮助用户识别、诊断和从错误中恢复

错误消息应该用平实的语言表达(没有代码),精确显示问题,建设性地提出一个解决方案。对用户是有用的。并且提供一个解决方案。

就像 这样

10. 帮助和文档

在设计原则的列表中看到这一项,我和你一样感到惊讶。

即便没有文档也可以使用的系统,最好也还是要提供帮助和文档。任何此类信息都应该易于搜索,关注用户的任务,列出具体的进行步骤,并切不应该太大。

总结

我希望这对你是有帮助的。如果你有任何问题或看法,请留言。

via: medium译文地址。本文由 Specs 翻译整理,发布在 Coder资源网,转载请注明来源。

相关 [开发 设计 原则] 推荐:

10个对开发者非常有用的设计原则

- - SegmentFault 最新的文章
要点:我会尽力解释Jakob Nielsen的10设计启发式算法. 我会用例子告诉你,作为一名开发人员,如何使你的产品以及你产品背后的代码更加有用. 开发者也是设计师,他们只是使用不同的媒介. 因此,你知道如何设计系统也是你的最终产品的一部分. 关注于把底层设计的更加有用将会帮助确定以下事情:. 对新加入的开发人员更容易上手.

Android设计原则

- - 所有文章 - UCD大社区
译者按: 在 iOS HIG已经强大经典了N年之后,Android终于推出了一套比较系统的 HIG(大概是为了配合Android 4.0 Ice Cream Sandwich). 仔细比较两套HIG的“设计原则”部分,发现完全是截然不同的两种风格. iOS HIG走的是更专业型的路线,描述严谨且有不少的专业词汇(比如Metaphors、Consistency之类的).

设计指导原则

- - 企业架构 - ITeye博客
避免在循环内部new一些没有必要每次都new的对象. 所有与IO相关的操作,都需要考虑性能问题,一般采取的措施是连接池,缓存,减少调用次数,合并请求. 每个业务都要分析整个请求链路,找到瓶颈,通过压测的方式确认问题及验证解决方案. 根据业务情况,使用异步化和最终一致性. CPU,内存,网络IO,磁盘IO这些瓶颈,需要知道在合适的场景牺牲什么换取什么.

MySql 之表设计原则

- - 互联网 - ITeye博客
1) 不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之 间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统或表 结构的重构提供可能性.

设计模式和设计原则

- - 编程 - 编程语言 - ITeye博客
26.1  设计模式和设计原则. 26.1.1  设计模式和设计原则的关系. 面向对象的分析设计有很多原则,这些原则大都从思想层面,给我们指出了面向对象分析设计的正确方向,是我们进行面向对象分析设计应该尽力遵守的准则.        而设计模式已经是针对某个场景下某些问题的某个解决方案. 也就是说这些设计原则是思想上的指导,而设计模式是实现上的手段,因此设计模式也是应该遵守这些原则的,换句话说,设计模式就是这些设计原则的一些具体体现.

一些软件设计的原则

- 夕角 - 酷壳 - CoolShell.cn
以前本站向大家介绍过一些软件开发的原则,比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则. 相信大家从中能够从中学了解到一些设计原理方面的知识,正如我在《再谈“我是怎么招聘程序”》中所说的,一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成. 在这里想和大家说说设计中的一些原则,我认为这些东西属于长期经验总结出来的知识.

web交互设计原则和模式

- shallwelin - 译言-
原文作者:Bill Scott. 原文链接:Designing Web Interfaces Principles and Patterns for Rich Interaction. web界面设计(丰富交互设计的原则和模式). (本书英文版大家可以到我blog下载:http://blog.youmila.com/?p=325).

分层架构设计原则

- - 博客园_首页
通常一个软件系统都包含不同部分互相交互耦合,我们希望设计能够将系统划分为有意义的各个部件,各个部件能够独立的开发、演进、部署. 这时整体性的设计已经无法满足这些挑战,这就需要我们对系统进行合理清晰的划分. 通常我们为待开发的系统定义多个层次,每一层完成独立的功能. 1:系统分为多层,每层完成独立的功能,层内部继续细分子模块,每层能够独立演进、部署.

设计模式原则总结

- - IT技术博客大学习
0、单一职责原则(SRP) 就一个类而言,应该仅有一个引起它变化的原因. 一、”开放-封闭”原则(OCP) 在软件设计模式中,这种不能修改,但可以扩展的思想也是最重要的一种设计原则. 即软件实体(类、模板、函数等等)应该可以扩展,但是不可修改. 【通俗】:设计的时候,时刻考虑,尽量让这个类是足够好,写好了就不要去修改了,如果新需求来,我们增加一些类就完事了,原来的代码能不动则不动.