分享设计师的危机感

Ruby On Rail是37singal的David Heinemeier Hansson在开发basecamp.com的过程中分离出来的一套Ruby语言的开发框架，适用于敏捷开发Web APP，我们目前这个团队正在用它。

之所以会想要花时间来学习Rails这套框架以及Ruby语言，是因为过去的工作经验告诉我，仅仅设计好用的界面，对于产品成功的贡献度太小了，而且在将来还会愈演愈烈。

原因主要有两个，第一个是互联网产品在逐渐告别Copy to China，需要从“寻找用户需求”做起。一个从美国抄来的产品，用户需求基本已经靠谱的，接下来团队之间、公司之间的竞争会更围绕怎么好用、怎么好看。交互和视觉设计的价值会很重要。但慢慢大家会发现，这样copy来的产品不会成长，最典型的例子就是人人网。而12306.cn也用数据告诉我们，做“有用的、有需求”的产品才能让自己站到能把猪都吹上天的大风口上。不知道什么东西有用户需求，就让设计师去把它做的好用、好看，又有什么意义呢。

第二个原因是一门技术在经过一段时间的探索之后，会逐渐离开混沌期。不断有人贡献自己的经验、给出可以信赖的原则、提供简单易用的模板，诸如iOS Human interface Guideline，yahoo design pattern library，twitter Bootstrap css framework，都可以让一个不太懂设计的工程师在几天学习之后很快搭建出一个在交互、视觉上都可以打70分的网站/APP出来。那，还要设计师干嘛呢?

一个人的价值在于控制通往成功之路上的不确定性。在“好用、好看”这个领域的风险越来越低的时候，设计师该怎么发展，以提高自己的价值呢?

一个成功的产品是需要有三个要素的，“有用”、“好用”、“能实现”。所以我能想到的，让自己更有价值的，就是以“好用”为根基，去帮助团队伙伴解决“有用”和“能实现”的问题，这也是我要学习开发技术的原因。

1、帮助验证“是否有用”的假设：在和产品经理沟通用户需求之后，可以用最简单、粗糙的代码实现假功能，投放到真实场景中去，让用户去感受、去触碰，给出是否觉得有用的反馈。

2、提高设计阶段“是否好用”的可信赖度：自己设计出来的界面方案，自己可以先简单地实现出来，代码效率低、奇丑无比都没关系，只要能够让自己把玩一下，切身体验下这个设计方案是否好用就行。

3、降低设计方案“不可实现”的风险：懂一点代码，就可以知道实现某个设计方案需要怎么样的技术支持，有怎样的限制，成本如何。这样就能确保交付的设计方案不是天马行空的。

作为一个心理学出身的半吊子设计师，我深深感觉到自身价值的危机感，就像当年被机器替代掉的工人那样。一个领域被充分探索之后，变得自动化、低价值化是很自然的，没什么好埋怨的。我在努力地让自己做的事情变得更有价值，你有什么好建议呢?

VIA：totry