你们有没有碰到过这么一种情况？在小组进行头脑风暴时，有人讲出一个不错的想法，它就会在脑子里挥之不去，刚想到点别的，还没深入，就又回到了这个想法。知道的越多，思维越受束缚。创新难，难在不容易走出思维的牢房和知识的边界。以前大家都用带键盘的诺基亚手机，习惯了手机有按键，研发一款新手机时，有几家手机厂商能够想到将键盘删除，改成触屏手机？现在大家习惯了触屏手机，在下一代个人通信设备中，会是以什么样的方式进行人机交互？前端开发，也是一个道理。
最近开始了新任务，要设计开发一个库存管理系统。我从来没有接触过这个领域，对库存管理的商业运作完全不了解，这时如果自己空想去造一个软件出来，不可能会符合要求，就像不懂佛跳墙的厨师硬要自己做一道，不知道要放哪些主料，哪些佐料，要用什么火候等，做出来的可能不是佛跳墙，而是东北乱炖。作为一个刚入门的程序员，最直接的反应是，我去找找现有的软件，看看他们是怎么做的，参考参考，再自己设计。这种方式能够让我们在最短的时间内，知道做出来的软件是什么样的，却也同时极大限制了自己的设计。我们的大脑总是会不自觉的引导我们去做相对简单的事。因为有了参考，在之后设计的过程中，会倾向于去回忆别人的做法，去模仿别人的做法，因为有模版参照，最省时省力，最终设计出来的产品，也就不会有很大的突破，和别人的差不多，并且不一定适合公司的商业运作场景。那具体要怎么做呢？
一切软件设计，都应该从商业角度入手，从用户角度去思考和设计。
软件设计的流程
软件设计，大体可以分为一下三个步骤：
- 理清业务逻辑
- 思考用户日程
- 参考现有软件，补不足
理清业务逻辑
在着手设计之前，先要弄清楚，这个软件是 给谁 在什么样的场景 下使用。
- 了解使用软件的商业运作过程，理清商业运作的主线。
- 在考虑在这个过程中，有哪些特殊情况。
- 在整个流程中思考，哪些部分要使用到软件，哪些部分能用软件优化？
拿库存管理软件为例，其中一条主线大概是：采购员下单，库存管理员在物件到库时，清点，存库。这个过程中的特殊情况有：清点货物时，货物和下单的不符、货物有损伤等，尽量将这些细节都考虑全。软件在这个过程中，可以帮忙下单，可以有扫码器，扫码识别货物同步信息。如果货物出问题了，可以通过软件记录并通知采购员，让采购员与供货商进一步联系，重新发货等。
这只是一个简化的例子，真实场景还有很多别的要考虑的，也有其他用软件处理的方式。
思考用户日程
第一点主要从业务角度入手，这里侧重从用户角度思考。主要考虑：
- 每个用户，每天在什么时间都做什么事情？
- 用户使用软件的频率是什么样的？
- 软件怎么帮助用户更好，更快的完成任务？
这点似乎和第一点有些重叠，但因为思考的角度不同，有助于将业务逻辑和用户使用场景思考的更加全面。继续上面的例子，假设库存管理员每两个小时才有一批新的货物要入库，一天还有很多别的时间，他们可能会要清点整个仓库的货品等，将这个用户其他可能进行的活动都考虑进去。那软件怎么帮助这个用户呢？比如说要存库，软件可以显示地图，让管理员知道该存哪，更厉害点的，可以有仓库的室内导航。
对每个场景，每个用户都这一系列的思考，并将软件使用融入其中，整个流程下来，软件的设计基本差不多了。
参考现有软件，补不足
都说要站在巨人的肩膀上，有了初版自己的设计，就能去和别人的设计相比较。
哪些功能他们有，我们没有？并不是将自己没有的全加上，而是考虑业务逻辑，猜测他们的业务逻辑是什么样的？我们需要这部分的功能吗？
哪些功能我们有，他们没有？考虑是否需要做出相对应的修改？
另外一个可以借鉴的地方，对方的界面设计。特别对新手来说，怎么去排版，这个表格怎么排比较好？那个按钮放哪里更合适？不清楚时，可以参考优秀软件，想想为什么对方这么做？我们也这么设计合适吗？
小结
做个小总结，我们容易被自己看到过的应用，软件影响思维的边界，所以在开始做一个新的领域的软件时，第一步不应该是直接参考别人的软件，而是思考业务逻辑，用户的使用场景。最后再去参考对比别人的软件。
所见即所缚，你知道的，都将成为你迸发创意的阻力。
