上周末参加了一场产品人线下的 meetup，其中一位嘉宾分享了 Salesforce 里的一次产品改版。
读者从名字大致也能猜出来，左边的是旧版 (Old 有点难听，所以大家都喜欢把旧版叫做 Classic)，而右边的则是新版。嘉宾接着说到虽然新版看上去更现代，界面也清爽，但上线后，受到了用户的大量抵制，渐渐地又改回到旧版的样子了。这个分享就一页，不过击中我好几点。
首先是这个改版，其实嘉宾放出这张图的时候，我直觉估计要讲个反例了。因为虽然右图看上去清爽，但是他的信息密度相比于左图差太多了。而左图虽然看上去密密麻麻的，但是整体布局严密，信息错落有致，配色合理，一看就是一个历经打磨的设计 (虽然老式了一点，但我觉得还是很有品位的，所以叫 Classic 也确实不为过)。
有这个直觉也是因为自己工作中也碰到过。我有一段时间在蚂蚁负责开发者工具平台，做的第一个大项目是对 Code Review (CR) 工具进行改版。设计师一开始出的稿子是按照设计规范来的，我给的反馈就是留白太多，间距太大，看上去界面整洁，但信息密度不够，于是让设计师回去修改。设计师又来来回回改了几版，但可能是她个人审美或者整体设计规范的要求，双方始终很难达成共识。这也形成了一个尴尬的局面，一方面自己很难要求设计师能完全理解 Code Review 的场景和使用者的诉求 (这需要长期 CR 的经验积累，以及用过像 Google 内部 Critique 这样很好用的 CR 产品)，另一方面当时设计师的绩效考核方式是业务部门和设计部门各占一半，而我作为业务方提出的设计建议又是背离当时设计部门的规范。所以最终定下的还是一个妥协的方案。
类似场景经历过好几次，毕竟设计师对于开发者场景确实是较难共情的，多少人能理解程序员会为了 vi 和 emacs 吵翻天？这也是我很喜欢 Linear 的原因，顶尖的设计 + 深刻的开发者场景理解，这样的技能组合太稀缺了。
另外还有一个故事也一直印在我的脑海里，讲的是一个人看到收银台软件的页面，上面铺满了密密麻麻的按钮，就问收银员那么乱的界面，用起来不舒服吗？收银员的回答是，她需要的就是能在一个屏幕上有尽量多的操作按钮，因为每天都用，就完全能记住所有的按钮位置。
所以嘉宾最后的总结也很到位 『2B 创新要创造并且保持高效使用习惯』。
我在设计 Bytebase 时始终会关注这一点，因为没有 Linear 那样的设计水平，所以在信息密度和美感之间，我只能尽量保证前者， 比如下面的这个界面，用于配置 project 的 VCS 集成：
估计不少设计师看了会皱眉头，但通过尽量挤压空间，使得用户在小屏幕上也能看到所有信息，而不需要再划动滚动条。
Design is not just what it looks like and feels like. Design is how it works.
这句话是 Jobs 说的。而具体到 DevTools 产品的设计，我持有的大概是更激进的观点：
Design is not
justwhat it looks like and feels like. Design is how it works.
对于我这样一个程序员来说，DevTools 里的留白真的是一种奢侈。
若有收获，就点个赞吧
0 人点赞
