有的放矢抠细节
Haijun - 2014/06/10
前同事设计师 Sophie 在 blog 上问「抠不影响成败的细节有必要吗」，事隔 7 日，从 Reeder 过去评论了几句。
实际上，在绝大多数情况下，这位工程师说得对，对成果毫无影响。在多数产品难以「创新」的情况下，很多互联网产品的「设计」整体作用都是被高估的。
但就像 Sophie 所说，这在以前合作过的工程师里却是少见的，前端工程师甚至会跟设计师一起抠细节。我猜测她说的是豆瓣。这是公司产品文化的具体体现，非常难得，对于设计师来说亦是运气。
在现在的公司里，产品和设计师（这两个职位二合一）被强调要尽可能去做 impact 足够大的事情，不纠缠细节。但几个月下来，总有一些细节问题不忍直视。这对于老板是处女座，注重产品设计的公司，是无法容忍的事情。于是每半年抽出一周时间，主题就是「查漏补缺」，公司上下所有人一起挑产品细节问题。一个字的文案、一个象素的对齐、一点点的色差，都可以被揪出来，集结成册，并尽量控制在一个工程师 0.5-1 天能解决的范围，鼓励数量越多越好。称之为 Polish Week。
Polish Week 最早来自于 Asana 在 2012 年的一篇 blog。
When we work on a mission and product as ambitious as Asana, it’s important to spend most of our energy on bold changes. However, we recognize that the finer details of a product are what bring delight to our users, so we built in time this episode to spend a week doing only product polish.
利用整周时间，工程师都用来 Polish。公司会将工程师分组，解决问题最多并通过 QA 验收的小组，会得到一些实物奖品。最近一次的奖品是一台 Segway，这两天总发现办公室总有人踩着这台家伙到处窜。
7 条评论
看到你在Sophie评论中的分享：
“赞同需要重新定位角色，原来那种产品口述+画线框，再交给设计师画关键流程/页面，再制作出漂亮的界面的模式，需要更新了。”
请教：你觉得什么样的产品设计开发流程更高效？（或者说，你们现在流程是怎样？）
谢谢，期待回复。（或者专门撰文）
by diff on 2014/06/11 at 15:59. #
比如传统的产品流程是：
1. 产品经理提需求，画个草稿；给交互设计师；
2. 交互出一个低保真原型，根据PM的口述/文档画出关键流程；
3. 再给视觉设计师，给出详细的视觉设计稿。
经常出现的问题是：
第1和2步之间，PM 认为自己比交互更理解产品核心问题，定义好了「产品要做成什么样」只是由交互设计师翻译而已；交互则认为自己也同样更懂产品，对产品定位和原则提出质疑，僵持不下。
第2和第3步之间，需求传到视觉设计师那里，视觉设计师对原始需求的理解可能会发生二次「变形」，容易出现过度发挥美的设计，而忽略需求本身的情况。
理想的流程其实是全栈「产品设计师」，国外很多公司如 Quora，国内如豌豆荚都推崇如此，当然早期的豆瓣更是阿北一个人做产品+设计+开发。即产品设计师将产品经理和设计师二合一，强调对结果负责，在职业技能上也提出更高要求。减少角色的同时，理论上会提升沟通效率和作品质量。
by Haijun on 2014/06/11 at 22:40. #
我其实也偏向于通过“全栈设计师”来降低设计流程中的损耗，但是这样的人，真不容易找。
我们团队现在的做法是：
角色：产品经理+视觉设计师（有交互思维）；
1. 产品设计阶段，通过工具协作(google doc），产品经理和设计师共同探讨、完成产品定位/交互流程。锁定需求；这个阶段，重点在确定产品需求、交互流程；
2. 然后进入视觉设计。这个阶段，产品经理基本不用插手。视觉设计师因为一直参与需求迭代，所以也不会有“二次变形”的情况。
by diff on 2014/06/11 at 23:07. #
感谢分享
by 麦杰机械 on 2014/06/20 at 14:09. #
文章写的不错 学习了 支持一下
by 小营博客 on 2014/06/21 at 23:54. #
为啥
http://sylvieluk.me/
自动定位到你这儿了。。。
by 不明真相的群众 on 2014/10/12 at 00:42. #
以前我帮她管理 blog，用的我的服务器。最近她把数据搬走了，但域名还是指向了我的服务器。
by Haijun on 2014/10/12 at 12:04. #