在上一篇我们提到了使用用户故事方式来描写需求，并将需求进行罗列成“故事清单”。将得出故事清单后，通过业务流程的梳理后，将故事清单整理成业务结构图。这是一个纯粹的业务思维过程。而软件是对现实业务的高度抽象，所以我们在对业务进行梳理以后，我们需要使用技术思维去将业务系统进行再度抽象。
5、主线功能
主线功能是我以前做产品设计的时候常用的一种思维，这其实是借鉴了MVP的思维方式，即最小化可行产品。无论多复杂的产品，我们认为它一定有一个最核心的功能，我们把它称之为核心功能。这个核心功能体现的是产品的主价值，比如从微信这个产品的角度来看，“聊天”就是他的核心功能；但是从微信再进去看，他又有朋友圈、支付、游戏、视频号等其他主功能，所以我们去看微信的迭代记录，就会发现每一个大版本都会有一个核心功能。而无论产品迭代到多大，只要他还存在并被使用者，这个核心功能一定都是存在甚至是最重要的。在围绕着核心功能，会有众多分支功能，这些功能均是为了服务核心功能，或者是为了实现核心功能而存在的。我们把为了实现核心功能，体现产品核心价值的功能集合称之为功能主线。
功能主线
功能主线一般是一条比较粗的业务主线。比如我们都知道的WMS系统。他的主诉求是管理好仓库，保证仓库的入库、出库快捷、高效；而入库后的管理是保证高效出库的良好衔接。所以不难看出功能主线就是入库- 库内管理- 出库。任何WMS系统不会离开这三个部分。那么在系统之下，是对仓库进行建模。我们就可以初步把大部分的故事清单往入库、库内管理、出库、仓库建模四个大类去放。除去这四个大的模块，我们就可以发现其他的功能都是在围绕这4个模块在展开，如质量、生产、财务、外设（如扫码枪、机械臂、RFID、AGV、CCD）等等。
数据主线
数据主线是在功能主线下的数据对象。我们知道程序= 算法+ 数据。如果把功能主线看成系统的骨架的话，那么数据就是系统的肉。我们在做数据库设计的时候，常常使用E-R图的方式来构建数据架构。而但凡做过数据库设计的人，都会知道一个系统的数据架构是围绕主（表）数据去构建的。所以我们在做数据主线的时候，其实也只是需要把主数据罗列出来，再通过功能主线串联起来，最终实现最小业务闭环即完成了这个MVP。
MVP是一个系统性产品最核心的单元，围绕着此MVP可以构建更多复杂的系统。
当功能主线和数据主线梳理完成后，我们需要对此功能进行验证，也就是说我们要看看我们梳理的功能是否可以形成闭环。而这就需要通过软件界面和页面交互来模拟用户实际使用软件的情况来验证。在以前的IT项目实施过程中，需求的梳理可能到功能清单就已经结束了。但是功能清单原本就是一个高度抽象的文本，是很难判断系统是否闭环的。
6、原型设计
我们都知道语言其实是现实世界的一种抽象。脱离语境的同样的一句话，可以有无数种理解。另外，从自然语言到计算机专业语言又是另外一层抽象，我甚至在一些蓝图设计里看到过UML语言。而这个蓝图还要交由客户签字。我真不确定是否每一个客户都能看的懂如此抽象的“蓝图”。而软件原型就是蓝图非常好的表达工具。一般我们在设计页面原型的时候，往往会先做sitmap，通过sitemap来将所有页面串联起来，以梳理页面与页面之间的逻辑。
Sitemap
Sitemap，站点地图。原本是为了方便搜索引擎更好的抓取网页，通过XML的方式记录整个站点中的URL。他还有另外一种表达方式即通过树形结构图的方式表达出来。例如下图：
在设计sitemap的时候，有几点需要注意：
a.需要符合我们之前梳理的业务流程进行页面设计。
b.的最小单位是页面。如果这个页面里有模态窗，把模态窗看成一个单独的页面。
c.在每一个页面中，我们可以将页面里面所需要包含的功能、数据、交互以注释的方式展现出来。后续我们制作原型时也可以参考这里的注释。
页面元素
当我们完成了sitemap以后，其实我们就只需要在每一个页面中添加不同的页面元素来满足业务需求即可。自有了图形界面（GUI）以来，对于页面使用的元素几乎没怎么变，窗体、导航、列表、上下文菜单、表单、图表等等，今天我们无论是web端还是移动端都离不开这些页面元素。
1）页面布局：在web页面中，常见的布局有：
a.上下结构，一般网站常常会使用这类结构，比如门户网站、视频网站等；
b.左右结构（OA）和上左右结构（阿里云）一般在后台或者信息化系统中比较常用。
无论什么布局，其本质都是通过菜单来表达模块以起到内容导航的作用。
2）窗口：窗口其实是window程序的一种概念。但是在当前web、或者移动端程序中，我们也经常会用到窗口的交互方式。窗口分为消息类和模态窗。我们见到的模态窗又有两种情况：
a.模态窗关闭前是否可以回到原页面，如果可以回到原页面，会出现一个母窗体打开了多于1个模态窗的情况，会很容易造成误操作，从而影响用户体验；
b.另模态窗是否可以再单开一个模态窗，而这样就会让整个站点加深，让技术实现也会变得困难。
窗体的设计，从sitemap设计的时候，就已经开始了。需要格外注意的是，对于模态窗的设计。我到现在任然记得，在IOS设计规范中，关于模态窗的设计有非常严格的规定，如果不满足规定是无法通过appstore审核的。
3）导航：导航的概念在网站设计中会需要重点考虑，一般对于我们这类工业化应用其实需要考虑的还是比较少。导航作为信息架构的重要入口，在较大系统设计中，需要重点考虑。
4）列表：我们在信息化系统中常见的页面元素。列表具有很多变化：
a.多列表联动，如何多级分类编辑；
b.列表目的是数据查询，还是数据入口；
c.列表中的数据是否可以点击；
d.列表数据的查询都可以通过哪些条件；
e.列表刚打开有没有默认数据；
f.是否可以排序，默认排序是什么；
g.是否可以搜索，基于什么字段进行搜索；
h.分页的方式；
i.列表数据加载时的loading状态；
5）表单：表单内又包含了各种元素。如输入框、按钮、单选、复选、日期控件、下拉框、开关。那么表单最需要注意有如下内容：
a.输入的内容需要有提示；
b.复杂的操作需要有教学；
c.填写的正确性需要实时反馈；
d.输入的内容需要有分段；
e.内容多了，需要考虑分布保存；
f.需要考虑“tab”等快捷键
设计规范
很多公司都会有自己的UI设计规范，产品经理画原型时也会遵循公司的设计规范。而这些设计规范，都需要遵循一些标准机构的设计规范。我以前常常跟团队说，到今天，我们要设计出90分以上的用户体验是非常困难的事情，因为那需要很多静心的设计，同样我们也很难设计出70分一下的用户体验，我们只要遵照标准规范来设计，基本上用户体验都不会太差，而当前能在网上搜到设计规范非常多，比较权威的有：
a.IOS设计规范
b.安卓设计规范
c.微信设计规范
d.Web设计模式
7、功能清单及验证
当我们将原型完成以后，每一个模块对于哪些功能其实就已经很清晰了。他可能是某一个页面，也可能是页面中的某一个表单或者某一个数据列表等等。我们将这些功能通过功能模块组合起来，会组合成一个功能清单。然后再回到我们的“故事清单”中去，验证我们的功能是否匹配我们的需求。
如果全部覆盖我们所有的需求，则代表功能设计是复合用户需求的。但到页面是否复合需求就需要通过用户验证环节才能最终确认。
8、文档撰写及客户验证
当故事清单、业务流程、原型设计、功能清单均设计完成，那么我们最终撰写蓝图的素材也就都具备了。这个时候，我们就只需要页面、功能逐个说明即可。那么在文档编写时我们需要特别注意如下几点：
a.名词说明：一些专业性比较强或者不是很好理解的名词，需要额外说明；
b.数据：重要数据需要注明数据类型、文本大小、取值范围、默认值、数据逻辑；
c.流程说明：业务流程在关联页中需要标出并详细描述；
d.页面交互：页面交互逻辑需要单独说明。
e.页面跳转：页面跳转可以通过连接线或者做动态页面图来表达。
f.提示信息：如果有提示信息，需要在注释中表现出来。
g.异常问题：如果页面有任何异常问题，如空页面，404等问题，需要特别注明。
文档最终是交由实施人员做现场实施使用。但对于我们的最终用户而言，还是需要使用原型工具进行用户测试，以及在分布交付中多次跟客户确认，以保证其准确性。
9、总结
以上我们从需求分析到系统设计，提到了用户故事、故事清单、业务结构、功能主线、数据主线、产品原型等我以前在产品设计中经常会用到的工具。以实现对一个系统从0到1的实现。其实在我们现在很多to B产品中，均有一些“标准答案”，及各种组织提供的标准。但to B产品有意思的就是每一家企业都是独一无二的，很难用A家公司的经验或者系统完全套用到B家公司中去。所以，这就需要业务顾问既要做好教练，和客户一起收集需求，梳理流程；也要能够将客户的需求抽象成蓝图文档，并和客户共同验证蓝图的可行性，以最终实现IT系统的成功实施。
网友评论