两年实践经验干货：关于软件产品设计的一些总结

最大收获：原来踏踏实实地做一件事情，是可以获得这么多成果的，如果不写出来，连我自己都没有想到！

这篇文章纯干货，没有心情看的千万别打开！

不方便公开的内容：具体产品的界面、设计流程图，由于会在不久的将来作为商品的一部分出售，所以不方便贴出，只能够靠读者自己根据文字去想象了，不好意思！

这两年，我自己一直在抽空做一件事情，就是设计和云及客户端相关的联动性产品，同时这个产品还有绑定硬件进行身份识别的功能，并组织团队将产品落地。抛开团队磨合、沟通协调上遇到的问题不说，这里先总结一下这一年来，关于软件产品设计和落地测试过程中遇到的问题，看看从中获得了什么经验，学习到了什么方法，以及如何将这些经验和方法运用到未来的产品设计和落地中去。

上面提到的产品，由于涉及到云（Web功能）、客户端（软件功能）和硬件（设备特征），其实是比较复杂的，但是在设计之初，我并没有意识到这三者掺和在一起的复杂度，也没有完全意识到这三者在整个系统中作为独立的部分，各自充当的具体角色的每一个具体功能是什么，以及这些功能的合体对整个系统设计的影响会是怎么样的，就开始了设计之旅——当然，设计的时候并不“匆匆”，相反，还花了很多时间去思考功能之间的利弊，流程走下来的先后次序排列等细致问题。

当时的做法是，将这三者作为一个整体，以用户操作角度入手，模拟整个操作流，之后形成设计文档；再和开发人员反复确认各个子功能细节实现有无困难，如果有，应该如何改进实现，直至敲定软件各个功能；然后开发人员开始代码编写，实现各个子功能并组成整个系统；接下来进入软件功能测试阶段，再由测试发现软件问题，然后不断修改问题，最终完成软件落地目标。

从软件的设计上看，从设计、功能定型、代码编写、软件测试、产品定型这几个步骤，确实是踏踏实实地走了一遍，但给我的感觉是看着挺热闹，却缺少章法；正是发生在软件测试过程中碰到前所未遇的新知识，以及软件测试过程中由于发生了中美芯片贸易战，而机缘巧合地获得了梁宁产品设计思路等一系列不期而遇的事情，才得以让我意识到必须要回顾这次软件设计的整个过程，找出自己的问题，提炼出经验和方法，为下一步的软件设计提供实践支撑。以下就是具体的总结内容：

单一功能 = 单一产品

简化设计，降低设计难度和抛掉设计中不必要的思想压力——对应于软件的每一个单一子功能（具体功能），都应以设计单一产品的方式来对待，而不必考虑这个功能以外的事情。

这点就是针对上述所说的，云、客户端、硬件三者各自角色功能没有完全具体化考虑而得出的经验教训；说得具体一点，将三者拆分分析，就是作为云端，它究竟需要提供什么功能：用户注册、存储用户信息、用户身份验证、用户登录、设备注册、设备验证、授时等等一系列子功能。

而针对每一个子功能的设计，就是将每个子功能作为一个单一产品来设计！例如，用户注册功能，就是先制定接收接口，将用户填写的账、密码通过客户端传输到云端；之后云端对比该账是否已经存在数据库中，不存在，即存储相关账密码信息，并回复客户端用户注册成功；如账已存在，则不能存储相关账密码信息，并回复客户端用户已存在。

这样做的好处，就是一个功能作为一个单一产品来对待，完成功能，就是完成产品，某个功能出了问题，处理起来也非常简单，就是去找这个“产品”流程上哪里出了问题，便于设计人员和开发人员定位问题位置，并快速解决问题。

流程设计——非对即错

这个做法的好处也是非常明显的，就是明确功能操作的正确结果是什么，而且不能有第二个正确结果，如果真的发生了两个或两个以上的正确结果，则需要考虑这两个结果是不是真的都是正确的，抑或是需要做功能分离（至少到现在为止，我还没遇到过对同一个功能的操作会出现两个正确结果的情况，不知道是设计正确还是水平有限……^_^）；当功能操作确认了到达正确结果的路径，则整个路径过程中的每一个步骤可能出现的问题，此时可以一一分析和罗列出来，作为“岔路口”进行批处理，制定相关的处理步骤，去屏蔽操作中可能出现的错误结果。

还是拿上面用户注册的例子来说：

用户注册功能就是通过客户端填写账密码，上传至云端直至注册成功的步骤，“正确的路”就是注册成功，这个结果不可能有两个；而错误的路就是注册不成功。注册成功的步骤就是：客户端接收用户填写账密码，客户端将用户填写的账、密码通过客户端传输到云端，云端对比该账是否已经存在数据库中，不存在，即存储相关账密码信息，存储成功以后，云端返回给客户端一个注册成功代码，客户端接收云端返回的注册成功代码，之后客户端弹出用户账注册成功对话框提示用户注册成功。

从整个步骤看注册成功的流程没有问题，接下来就可以通过分析注册成功的步骤，逐一分析注册不成功的地方，经过确认，有以下几个：

客户端接收用户填写的账或密码的其中一个不符合预先定义的规范，例如定义了用电子邮箱作为用户名，则不符合电子邮箱地址填写规则的账，将由客户端判断不允许传输到云端，导致注册失败；

又如账填写符合要求，但定义了密码注册规则，例如密码不能设置为低于6位字符/数字/符的其中一种或组合，抑或是定义了密码不能为纯数字/纯大写英文/纯小写英文/纯符，而是这几种类型的两种或者两种以上组合，当不符合要求的时候，客户端也不会上传相关账密码到云端；

当账密码都按预定规则填写，并经过客户端确认无误以后，客户端上传账密码信息到云端，此时，云端要判断的就是上传的账在数据库里边是否存在，当账存在且比对一致，则返回账已注册的返回值给客户端，客户端知道注册失败；

可以看到，“注册失败”有三个岔路口，其中两个在客户端就可以处理，剩下来一个在云端处理；三个岔路口的出现，正是以先找到正确的路，之后找错误的路，再对岔路口进行分析和批处理的思路来分析出来的，由此可见“非对即错”的思想在设计操作流程上的清晰！

整体设计——以终为始

对应于软件的整体设计，都应“以终为始”的方式，来考虑包括界面、具体功能、操作步骤等不同元素的组合。

“以终为始”的设计方式，是实践中的真知灼见！“以终为始”的设计方式，对软件的整体设计起到了画龙点睛的作用！

这个经验，来自于作为软件设计者的我，以及与开发人员在实际项目中的沟通等渠道。

作为设计者，一开始可能仅仅是一个想法，这个想法对我而言，萌芽状态可能仅仅是一个思路，说得更实际一些，应该是一个发现问题、分析问题的过程，但是远没有达到解决问题的阶段。举个例子，要做一个客户端可以完成用户注册、用户登录、设备注册、用户及设备捆绑识别的功能，在界面上，这个客户端究竟长啥样子，有几个按钮，有几个输入框，有几个弹出提示框，有几个对话框，这些按钮、提示框、对话框如何将以上功能完整搭载，如何在一个或多个这些元素组合的界面中搭配出合理而美观的窗口；在功能上，是不是这些功能已经是我需要的全部功能，是不是客户端都能够完整处理这些功能，哪些功能是本地能够解决的，哪些功能是需要与云端交互才能解决的；在流程上，每一个功能的具体操作流程是什么样的，有多少个步骤，每个功能包含“正确的路”和“错误的路”具体是怎么样的；综合上述所有的情况，还有所有功能和流程是否已经达到最优化状态？这些都是设计者在一开始的时候都不可能想清楚但是又必须细化的地方，“以始为终”的思想，则可以让设计者从软件的整体出发，先以可视化的界面入手，再分析各个具体功能，最后到各个功能的具体流程，逐步细化设计思路，让设计真正可行和落地。

而除了上述作用，“以始为终”的设计思想，还是连接设计人员和开发人员从项目设计到项目实现的桥梁，正因为这个思想指导的工作，细化了每一个操作细节，才能让设计人员和开发人员深入交流，一一确认界面、功能、流程的具体模样，最后保证软件的设计和落地保持一致，而不至于跑偏。

从开发人员角度出发，设计人员和开发人员在同一个项目的思想鸿沟，实际上是开发人员认为设计人员提出的问题都不是问题，通过技术都能解决问题，即“这都不是事，都能解决”；而设计人员认为开发人员能解决问题，所以提出需要做什么功能，开发人员就能通过技术去实现，即“我提出的需求，你都能做”。而实际情况却不是这样，为什么？因为开发人员并不知道设计人员要做的具体内容是什么，而设计人员并不知道开发人员要做什么工作才能把功能实现，大家沟通的层面只是停留在“你能做吗”——“可以做，不是问题”——“那就做吧”！

最后，结果就变成了这样：

开发人员的困惑是：

设计人员要做的功能具体是什么，这些功能是通过按钮来实现的，还是通过提示框实现的；是通过对话框实现的，还是通过输入框实现的；主界面是怎么样的，对话框有几个，提示框有几个，按钮有几个，每个按钮实现什么功能？——这些具体化的东西，开发人员没法替设计人员去设计和想定。

设计人员的困惑是：

开发人员不是说啥事都能搞定，技术上都不是问题吗？为啥我提出的需求他还要问我“你要怎么做呢？”既然开发人员都能搞定问题了，为啥还问我“你要我做什么呢？”

解决沟通中的困惑：

两者之间沟通的鸿沟其实是各自的方向都跑偏了，开发人员想到的是设计人员提具体需求，这些需求是有具体图片、流程图甚至是图文解释的设计方案，让开发人员能够深入了解到设计人员最终要达到什么目的的文档；而设计人员想到的则是，我把需要达到的功能给你说清楚，你就能按照我提出的功能去设计界面、流程，直到把软件做完交付给我。

这就有点像：我把情况告诉你了，但是你为啥还是没法和我好好说话，把问题解决掉？而对方的感觉却是你就告诉了我一个大概，相当于啥都没说……

所以，为了解决双方在理解上的距离，需要提出需求的设计人员，通过“以终为始”的方式，把界面、功能、流程清晰化，形成图片、文字及图文混排文档，交由开发人员，与开发人员深入沟通每一个设计细节，这样才能提高沟通效率，让开发人员清晰设计人员的想法，而且，这么做的好处，也是便于开发人员通过自己的经验，对设计不合理的地方提出合理化建议，去修改及优化整个软件的各个设计细节，使软件更容易落地。

对“以始为终”这个思路的总结，其实是在软件测试阶段触发的，因为到了这个阶段，软件该暴露的问题都基本上暴露了，而且问题暴露也非常直接——就是在设计阶段没有考虑到的问题或者忽略掉的问题。当看到测试结果的时候，就如同看到了软件在设计阶段时的一面镜子，这面镜子反射的就是当初设计过程中的每一个细节，这点让我不得不从结果去倒推当初设计的过程，设计时思考需要解决的问题，以及综合了这些问题所形成的功能是否合理、是否有冲突等等，由此让我深以为“以终为始”这个设计思路给软件设计带来的好处和高效率。

“想定”才是功能落定的结果

软件的功能一定是“想定”的，而不仅仅是“想”的，“想”只是个设计的过程，“定”才是设计的结果，只有“想定”，才是将软件最终定型！

谁都知道“想”，但是从“想”到“想定”，是经过发现问题、分析问题和解决问题的过程，最后将软件功能、操作流程等设计得到最终确认，到达设计定型终点的结果。

说得具体一点，“想”，实际上经历的过程可以归结为：

产生念头：

这个部分的潜台词是——“灵光乍现，需要留意！”

这时候的“想”，可以理解为“一闪而过的念头”，其实就是一个灵感，但是并不确认这个“灵感”是否可行，仅仅就是一个“念头”。但是必须考虑的问题是：必须记住这个一闪而过的念头，否则稍纵即逝，转身就不记得了。

确认念头：

这个部分的潜台词是——“我想的究竟是个什么样的东西？”。

“念头”是什么，“灵感”是什么，都需要将其形象化，具体化，例如看到手机APP盛行，但是发现到菜市场买菜太麻烦，于是想到做一个连接菜市场摊贩和买家实时视频看菜并且完成交易过程的APP，这算是一个“念头”，但是这个“念头”到底是怎么样的，即这个APP应该长什么样，有几个按钮，有几个对话框，有几个操作窗口等；具备几个具体的功能，譬如为买卖双方提供视频、音频的交互，提供结算交易，提供不同城区的菜市场供买家挑选，提供实时行情等功能，这些都是APP需要为买家设想和提供的；最后就是每个功能的操作流程是怎么样的，每一个操作流程是否合理且简便，等等一系列的问题。

其实确认念头，就是给念头“画像”，能够提供给念头“画像”的元素越多，这个念头就越容易确认，而且完善和落地就越清晰，而且，给念头画像，基本上都会用到上述三个设计技巧：

以终为始设计软件整体；

单一功能就是单一产品，功能要列明，而且要仔细区分；

流程设计要非对即错，注意流程的每一步是否合理，整个流程操作是否完善，解决的问题是否清晰和唯一；

整个的画像，实际上还是围绕“先总体，再分割，最后走流程”这样操作步骤来处理。

只有“画像清晰”，念头才能真正成为“有模有样”的想法，之后才能更好地往下走。

关联现实：

这个部分的潜台词是——“我想的东西真的是市场需要的东西吗，能够让市场接受的难点是什么？”。

把念头的画像做完，下一步要考虑的是已经画出来的“像”，是否与客观的情况相符，例如卖菜APP，提供视频互动，是否对买卖双方都真的可操作，他们是否都愿意接受，还是说平时会有其他的方法来解决；再比如APP的界面，把手机屏幕分割成几个部分，每个部分放几个图片框，带几个功能，放几个按钮，先落实成图、文字等具体可见、可读、便于理解的形式，之后再拿着这些图文资料去做落地调研，看设计图设计的功能、流程是否合理，哪些还需要优化，哪些需要删除，等等，目的就是让想法贴近现实需求，反复确认需求的真实性，把产品的功能与实际需求对接上。

关联现实的做法就像“如梦初醒”，梦想已经有画像，但是尚不明确与现实的差距在哪里，需要形成具体的图像、文字，并调研合理性，找出需要优化和丢弃的部分。

确认可行：

这个部分的潜台词是——“市场需要的东西，我能做到吗？”

其实上一步“关联现实”的做法，已经是在界面、功能上完成对软件落地过程中最关键的一步了，因为这一步是把“梦想”转化为“可见的现实”，接下来，就是需要确认这个可见现实的落地可行性，也就是把“可见的现实”变成“真正的现实”，包括：

确认市场是否认可这个“想法”——就是在上一步工作确认产品功能及操作流程的基础上，对软件整体设计再做一次调研，确认软件确实能够解决用户现阶段的需求痛点；

确认市场是否认可基于这个想法构建的软件功能，和客户需求已经完全可以一一对应，完整联系和结合在一起，成为一个切实可行的解决方案；

相关技术人员的确认（是否可以完成该项目、需要多少人力、人的水平要达到什么程度等等）；

相关资金预算的确认（总预算、付款条件、付款周期等）；

两年实践经验干货：关于软件产品设计的一些总结

相关推荐