不要成为瓶颈


你们团队是否有这样一位工程师,人们常常向他咨询某种问题?或许他是团队的高级工程师,编写了绝大部分代码库。或者,他是技术领导或管理人员,参与大部分设计方面的讨论,甚至很多项目中因历史原因形成的逻辑依据。或许,他是负责特定系统的核心人物,有着多年运作这些项目的经验。

我们常常被鼓励成为给人们解疑释惑的重要工程师,我把这种角色做为我们提供给团队的价值标识。像 Google 之类的公司,这部分能力甚至和晋升过程挂钩:那些初级工程师,成为了负责关键项目的核心工程师,经过论证后,常常更容易得到晋升。

这种鼓励看起来十分合理。根据供求关系,工程师的相关技能和知识越稀有,他或她对于团队的价值就越大。因此,成为很多项目核心人物的目标,貌似是合理的,对吧?

不幸的是,这种稀有的思维模式只能让我们更远地偏离轨道。

面向色盲的设计


每次有人发现我是色盲时,我常常产生同样的疑问:「这是什么颜色」?95%的情况下,我能够正确地回答,随之而来的是,「等等,如果你能辨认出{某颜色},那么你怎么会是色盲?你看到了什么?」。这就是解释色盲运作原理以及对我产生影响的乐趣所在。

做为设计师,我们总是担心易读性、内容质量、目标效果是否足够大、或者用户是否能够走通整套工作流。但是我们经常容易忽视,每十个人当中就有一个人是色盲。有太多次,我下载了某个 app 或游戏时,才意识到用起来十分痛楚。我经常无法区分某个对象、或无法确定某些地方该怎样打标签。

如果十分之一的用户觉得你的 app...

关掉它,看看是否有人抱怨


在我工作中的 Internal Web Tools 小组,我们定期处理一些终端用户【注1】,怎么说呢,他们坚持认为自己需要 app 里的某项特定功能,要求我们为他们开发出来。当问他们需要这个功能的理由时,他们的反馈通常包含「我想要...