写本文背景：公司的网管在杭州公司开发了有2年了，到现在为止还不好用，我们南京的经理组织了一次讨论，召集了杭州的网管开发人员，南京的测试人员，以及我和其他有UI开发经验的人，目的在于给网管提提建议，交流交流。后来经理也让我做个界面风格（配色），我顺便做了含内容的网管模型。
广义上讲，每个人、每个集体每天的工作都会生产出产品，例如程序员生产出代码、各类文档，以及思考心得和学习探索。本文仅讨论狭义上的产品，就是公司卖给客户的最终产品。
如果市场上没有同类产品，那么产品可以通过功能占领市场；如果市场上有许多同类产品，那么产品可以通过质量和价格占领市场，质量包括可用性、稳定性、美观性、便携性、售后服务等等，这里仅关注可用性，可用性指客户对产品的学习难度，使用方便程度，喜好程度。顺便插一句，面对一个竞争激励的市场，研制出三个五六十分质量的产品，同样的资源，也许不如研制出一个七八十分质量的产品，然后每一年一次小升级，每两年一次大升级，从七八十分逐步提高到九十分以上。
当前应用软件在设计最终客户使用的功能时，从最终客户的角度考虑问题的意识太淡薄，导致产品对最终客户而言太难用，太专业；另一方面，产品明显呈现出是面向开发人员而开发的，只有相关的开发人员才懂，才会用，才敢用。下面以PDT网管为例，见下图。
将复杂留在系统内部，将简单易用留给用户，才能真正帮助用户更好的工作，创造务实的持久的价值。客户只关心易用、美观、稳定，他是不需要知道打通一次电话需要多少设备参与配合，手机内部有多少零件。
面向客户开发产品，而不是面向开发人员开发：
l 面向多类客户前期调研和后期主动跟踪使用反馈，而不是前期调研仅依赖于个别客户，而不是后期直到客户忍无可忍时投诉才知道使用状况。客户可以分为包括决策类、使用类，能决策的客户可能不直接使用系统，他们的需求在乎功能强大，标新立异，随意性大；直接使用的客户在乎使用简单，稳定，真正能影响到系统的实际价值。需要定期跟踪各类用户对各功能各模块的使用频率、意见、缺陷，反馈给各层次开发和管理人员，从而不断完善。例如，卖出去的设备是一年用1小时，还是每天用8小时；哪些功能经常用，哪些功能不常用，哪些功能没有，那些常用的功能还需要怎么完善才能更好用，那些从来不用的功能是不会用还是真的不需要。
l 面向客户的工作场景设计功能，而不是面向系统的实现设计功能。
上图是现在的网管，下图是另一种思路，直接告诉客户他能做什么，需要做什么。恢复向导中，通常只该告诉用户如何找到设备，如何检查供电是否正常，如何找到按钮重启相关设备。
l 面向客户关心的业务设计功能的内容，而不是面向开发人员关心的设备和代码设计功能的内容。软件中不该有客户经过培训也不可能懂的术语，更不该让客户去配置开发人员内部实现用的参数。现在的网管中到处都是不需要懂的术语和开发人员内部实现用的参数。
上图是现在的网管，下图是另一种思路，让用户关注业务，而不需要懂得（也不可能懂得）业务的实现。
l 面向工程和测试人员开发专用部署和维护工具，而不是将功能混杂在最终客户的软件中，增加不必要的耦合度。他们需要快速完成部署和初始化设置，应该向他们提供各种向导和模板，而不是要记住各种繁琐的操作步骤和参数；出了问题他们需要快速导出各种环境和系统配置，导出各种日志，而不是要记住各种各样的TELNET命令和日志存放路径。
