产品设计

引言原文链接：https://mp.weixin.qq.com/s/9S... 谢邀，人在飞机，刚下海上。 《简洁至上：交互式设计四策略》是最近读的一本领导产品设计的书，它对我的产品设计办法带来了很大的扭转。 书中不仅有设计思维方面的内容，还有执行层面的方法论，让我一个齐全依附直觉和过往教训做功能设计的设计者首次感觉到设计也是有迹可循。 本文算是一篇读后感 + 笔记的混合文，纲要如下 性能和可用性到底哪一个更受用户关注？三类用户：支流、随意型、专家为本人设计还是为用户设计？四策略：删除、组织、暗藏、转移 性能和可用性到底哪一个更受用户关注？书中展现了一个 2006 年的试验，该试验将用户分为两组去筛选性能数量不同的播放器 第一组（未试用组）：只能通过观察产品来做筛选第二组（试用组）：能够试用产品当前再做筛选播放器的规格如下 播放器 A：领有 7 项性能播放器 B：领有 21 项性能最终试验后果如下 抉择播放器 A 的用户比例（7 项性能）抉择播放器 B 的用户比例（21 项性能）未应用组34%66%试用组56%44%由后果能够看出对于没有机会试用的消费者而言，性能越多越能吸引用户留神；然而消费者应用了产品之后，他们的偏好就会从器重性能转为器重可用性了。 简单的产品通常很吸引人，这是因为人们喜爱本人被突围在不必要的性能中。 当然这并不是说性能不重要，而是不要以性能的多寡来掂量产品的价值，这里援用一段原文作者的观点： 减少的性能越多，就越难发现真正对用户有价值的新性能。这样自觉增加的新性能早晚会成为垃圾性能。减少复杂性意味着遗留代码越来越惨重，导致产品保护老本越来越高，而且也越来越难以灵便应答市场变动。简单的性能会导致另一个问题：过多的性能抉择会带给用户累赘。 给用户提供抉择会让人感觉本人在把控场面，但实际上支流用户更心愿少一些抉择，尤其是多种抉择都很类似的状况下，抉择就是一种累赘。 简略的用户体验不会强制用户去做这种抉择，哪种形式最无效应该是设计者思考的事件。 所以作为产品设计者，应该将关注点放在产品是否满足用户最高优先级的指标上。 这不禁让我想起了前段时间开源的据库文档治理平台 Databasir ，该平台有一个模板定制性能，用户能够将表头定义成本人想要的任意名字，如下图所示： 这个性能破费了我大量的工夫做设计、研发，但它的确成为了一个实打实的垃圾性能：用户才懒得来定制呢！ 支流用户关怀的始终都是能看懂文档，而不是去学习如何定制文档好满足本人的偏好。 那么针对这个性能， Databasir 的支流用户理论要的是什么性能呢？其实是国际化。 对于一款开源产品来说，用户可能来自各个国家，在他们关上软件的时候，软件如果是以它零碎的默认语言展现那就是最好的。 用户会冀望更多的性能，通常是因为用户晓得本人面临了什么问题，但却不肯定晓得最合适的解决方案，正如乔布斯学生所言 用户并不知道本人须要什么，直到咱们拿出本人的产品，他们就发现，这是我要的货色......三类用户：支流、随意型、专家个别在做产品之前咱们都会定位产品面向的客户群，比方 软件编辑器的指标用户就是软件研发人员ERP 软件的指标用户就是企业中的财务人员静止品类垂直电商面向的就是喜爱静止或有健身偏向的用户...在《简洁至上：交互式设计四策略》中，作者又以用户对产品的态度将指标用户再次进行分类，次要有 3 种 支流用户随意型用户专家用户支流用户个别都是最大的用户群体，他们抉择产品的时候不是因为产品所应用到的技术，而是你的产品可能实现某项工作（他们最感兴趣的就是立刻把工作实现），他们会把握产品外围性能的应用办法，但不会产生学习所有性能的想法。 以手机为例，这类用户的需要就是：能疾速地打电话和不便地上网。 专家用户个别是具备摸索欲的用户群体，他们会提出倡议，心愿能看到为他们量身定做的前所未有的技术，这类用户和支流用户的需要有着十分的区别 支流用户谋求易操控，专家用户在乎操控的精确度支流用户想要靠谱的后果，专家用户心愿失去完满的后果支流用户胆怯呈现谬误，专家用户则有拆解所有的激动支流用户想看到示例和故事，专家用户想看到的则是原理 最初就是随意型的用户了，他们介于支流用户和专家用户之间，个别是有应用过同类产品的用户，也有趣味应用更高级、简单的产品，但却不违心接触全新的货色。 简略来说就是违心承受新的性能，但新的性能要足够简略，他们才承受。 除了用户分类以外，作者谈到了一个用户的属性：用户所属分类根本是不变的，也就是说不会在一段时间当前支流用户就会降级到专家用户。 即便是用户对一个产品应用了很多年，用户类型的标签也简直很少发生变化，而胜利的产品设计应该是面向支流用户的。 这方面在我做开源时也犯过同样的错，我在思考 Databasir 的性能时就站在了业余用户的角度（可能因为我就是属于业余用户？）。 为了能够灵便扩大数据库，我设计了一个性能：用户只有依照上面的表单填写完数据就能让 Databasir 反对他所应用的的数据库。 刚实现这项性能的时候，我还沾沾自喜了好一阵。 可起初我发现这性能大部分用户都用不了：学习老本太高了，我的用户也有很多非 Java 技术人员，看见 JDBC 这个业余词更是一脸懵逼...... ...

前言明天看到一段话：产品设计，会塑造用户的习惯，影响用户的抉择。所以，请多一些敬畏之心。深感认同。 造物主？一个产品是有外延的，这个世界没有造物主，却有制作产品的人。而产品的内核，由制作产品的团队打造，这么一想有点细思极恐。 衷心希望世界上的所有产品，都是怀着对世界的美妙产生，而后事实却并非如此。 小小开发者我是一名普普通通的小小开发者，也是互联网产品的深度用户。我发现，当我应用gitee或者github的时候，总是fork优先，而不是在某个仓库上创立分支，因为我没有权限，但也因为我更喜爱应用fork。然而，当我应用gitlab的时候，我则更喜爱创立分支，我想这是产品的设计塑造了我不同的习惯。这种习惯，并无好坏之分。 韭菜在成长我也是一名小小的韭菜，热衷于把小钱钱越滚越小。我发现当我在支付宝买基金时，往往热衷于短期的热点，比方高位接了白酒医药，这里大部分起因是本人太菜，但也有一部分起因来源于支付宝的推广机制，理财板块的热点总是近几个月爆火的题材，但这时往往在高位。我想赚钱，支付宝则想我屡次交易赚取手续费，动机不统一，则不可同行，由此可见，支付宝真是一个妖艳贱货，不便是不便，但往往只能爽一时。 心灵的符合所以呀，什么样的产品是好的产品，则须要用户用心与之沟通，发现自己的指标与之相符合。那可真是太好啦！ 很多时候，能够找本人起因，但也应该正当地找找客观因素。毕竟使坏的产品也不少呢。有时候对你温顺，有时候则有本人的小心理。 关注&&分割gitee： https://gitee.com/cmcc-oneos/OneOS-Lite docs： https://oneos-lite.com/

对于Scrum的起源，咱们常常会提到1986年发表在HBR上的一篇论文，《The New New Product Development Game》，明天咱们把它从新翻译，一起重温为何Scrum会如此设置3355？为何会用橄榄球的术语来代表Scrum？ The New New Product Development Game【新新产品开发游戏】作者：Hirotaka Takeuchi（竹内弘高）、Ikujiro Nonaka（野中郁次郎）摘自1986年1月在当今快节奏、竞争强烈的商业新产品开发畛域，速度和灵活性至关重要。公司越来越意识到，旧的、程序的办法根本无法实现新产品的开发工作。相同，日本和美国的公司正在应用一种整体的办法——就像橄榄球一样，当球作为一个整体在球场上挪动时，球在团队中传递。 这种整体办法有六个特点:内置的不稳定性、自组织的我的项目团队、重叠的开发阶段、“多重学习”、奥妙的管制和学习的组织转移。这六块组装起来就像一个拼图，造成了一个疾速灵便的新产品开发过程。同样重要的是，新办法能够起到改革推动者的作用:它是将创造性的、市场驱动的想法和流程引入到旧的、僵化的组织中的工具。 新产品开发的游戏规则正在扭转。许多公司发现，要想在当今竞争强烈的市场中怀才不遇，须要的不仅仅是公认的高质量、低成本和差异化的根底。它还须要速度和灵活性。 这种变动反映在公司把新产品作为新的销售和利润起源的重点上。例如，在3M公司，五年以下的产品占销售额的25%。1981年对700家美国公司的考察显示，新产品将占1980年代全副利润的三分之一，比1970年代的五分之一有所增加。 这种对速度和灵活性的强调须要一种不同的办法来治理新产品开发。以美国国家航空航天局(NASA)的阶段性打算布局(PPP，phased program planning)为例，传统的程序开发或“接力赛”办法可能与最高速度和灵活性的指标相冲突。相同，一个整体的或“橄榄球”的办法—一个团队尝试作为一个整体走齐全程，来回传递球——可能更好地满足当今的竞争要求。 在旧的办法下，产品开发过程就像接力赛，一组性能专家将接力棒传递给下一组。该我的项目从一个阶段到另一个阶段顺次进行:概念开发、可行性测试、产品设计、开发过程、试生产和最终生产。在这种办法下，职能是专门化和分段的:营销人员在开发产品概念时审查顾客的须要和认识;研发工程师抉择了适合的设计方案;生产工程师使它成型;其余的性能专家在较量的不同阶段拿着接力棒。 在橄榄球办法下，产品开发过程从一个精心筛选的多学科团队的一直互动中产生，团队成员从开始到完结都在一起工作。该过程不是在定义好的、高度结构化的阶段中进行的，而是在团队成员的相互作用下产生的。(见表1) 例如，一组工程师可能会在可行性测试(第二阶段)的所有后果呈现之前就开始设计产品(第三阶段)。或者，团队可能会因为稍后的信息而被迫重新考虑某个决定。团队不会进行，而是进行迭代试验。这甚至在开发过程的最终阶段也会产生。 (附录1序列（A）VS 重叠（B和C）开发阶段) 表1阐明了产品开发的传统线性办法与橄榄球办法之间的区别。程序的办法标记为A类，是由美国国家航空航天局类型PPP零碎的典型代表。重叠办法由B类和C类示意，其中B类重叠只产生在相邻阶段的边界上，而C类重叠扩大到多个阶段。咱们在富士施乐察看到B型重叠，在本田和佳能察看到C型重叠。 这种办法对于心愿疾速灵便地开发新产品的公司来说至关重要。从线性办法到集成办法的转变激励尝试和谬误，并挑战现状。它在组织的不同档次和性能上激发新的学习和思考形式。同样重要的是，这种产品开发策略能够作为更大组织的改革推动者。这种致力所产生的能量和能源会扩散到整个大公司，并开始突破一些随工夫而造成的僵化景象。 在本文中，咱们重点介绍了日本和美国的一些公司，它们采纳了一种新的办法来治理产品开发过程。咱们的钻研考查了富士施乐、佳能、本田、NEC、爱普生、兄弟、3M、施乐和惠普等跨国公司。而后咱们剖析了六种具体产品的开发过程: FX-3500中型复印机（富士施乐于1978年推出）PC-10家用复印机（佳能，1982年）装备1200 cc发动机的城市汽车（本田，1981年）PC 8000集体计算机（NEC，1979年）AE-1单镜头反光相机（佳能，1976年）Auto Boy，在美国被称为Sure Shot，镜头快门相机，（佳能，1979年)咱们抉择每个产品的根据是它的影响力，它在公司外部的可见性，作为“突破性”开发过程的一部分，过后的产品个性的新颖性，产品的市场胜利，以及获取和取得每个产品的数据。 将Scrum移到前场从对组织成员的采访，从CEO到年老的工程师，咱们理解到当先的公司在治理他们的新产品开发过程中体现出六个特点: 内建不稳定性自组织我的项目团队重叠的开发阶段“多重学习”奥妙的管制学习的组织转移这些特色就像拼图游戏的碎片。每个元素自身并不能带来速度和灵活性。但作为一个整体，这些特色能够产生一组弱小的新动力，从而有所作为。 Built-in Instability 内建不稳定性最高管理层通过收回一个宽泛的指标或总体策略方向的信号来启动开发过程。它很少提出明确的新产品概念或具体的工作打算。但它为我的项目团队提供了宽泛的自由度，并建设了极具挑战性的指标。例如，富士施乐的最高管理层要求更换一台齐全不同的复印机， 并给FX-3500我的项目团队两年的工夫来研发出一种机器，该机器的生产成本可能仅为其高端产品的一半，而且性能依然很好。 最高管理层通过给予我的项目团队极大的自在来执行对公司具备策略重要性的我的项目，并设置极具挑战性的要求，从而在我的项目团队中造成了压力。本田一位负责开发的高管说:“这就像把团队成员放在二楼，把梯子拿掉，通知他们要么跳下去，要么就想方法。我置信创造力是通过把人们推到墙边并把他们逼到极限而产生的。” Self-organizing Project Teams 自组织的我的项目团队当我的项目团队被驱动到“零信息”的状态时，他们呈现出一种自组织的特色——在这种状态下，先前的常识并不实用。这种状态存在着模糊性和波动性。让它本人慢慢来，这个过程开始创立它本人的动静秩序。我的项目团队开始像初创公司一样运作——承当主动性和危险，并制订独立的议程。在某个时候，团队开始创立本人的概念。 当一个群体体现出三个条件:自治、自我超过和异花授粉时，这个群体就领有了自组织能力。在咱们对各种新产品开发团队的钻研中，咱们发现了所有这三种条件。 自治。总部的参加仅限于在一开始只提供领导、资金和道义反对。在日常工作中，高层很少染指;团队能够自在地设定本人的方向。在某种程度上，最高管理层扮演着风险投资家的角色。或者，正如一位高管所说:“咱们关上钱包，但闭上嘴巴。” 这种自治在IBM开发个人电脑时就很显著。在佛罗里达州偏僻的博卡拉顿，一群工程师在一个革新过的仓库里开始钻研这台机器。除了季度公司评估外，位于纽约阿蒙克的总部容许博卡拉顿团体独立经营。该团体获准采取非常规措施，如为其微处理器和软件包抉择内部供应商。 咱们在案例钻研中察看到了自治的其余示例： 本田城市我的项目团队成员的平均年龄为27岁，他们从管理层失去了以下批示:开发“年轻人想要驾驶的那种汽车”。一位工程师说:“公司让像咱们这样的年老工程师来设计一款全新概念的汽车，并让咱们依照本人的形式来做，这真是不堪设想。”最后销售微处理器的一小群销售工程师在NEC生产了PC 8000。这个小组一开始对个人电脑无所不知。该我的项目负责人示意:“咱们失去了最高管理层的批准，能够持续推动这个我的项目，条件是咱们要本人开发产品，同时还要负责制作、销售和培修。自我超过。我的项目团队仿佛全神贯注于对“极限”的永无止境的谋求。从最高管理者提出的指导方针开始，他们开始建设本人的指标，并在整个开发过程中一直晋升指标。通过谋求最后看起来是矛盾的指标，他们设计了超过现状并获得重大发现的办法。 咱们在实地工作中察看到许多自我超过的例子。佳能AE-1我的项目团队提出了新的想法，以满足高层管理人员提出的具备挑战性的参数。该公司要求团队开发一种高质量，主动曝光的相机，该相机必须紧凑，笨重，易于应用，并且价格要比单镜头相机的现行价格低30％。为了实现这一雄心勃勃的指标，我的项目团队在相机设计和生产上获得了几项第一：由德州仪器（TI）定制的集成电路组成的电子大脑；模块化生产，使自动化和批量生产成为可能；整机数量缩小30％至40％。“这是一场奋斗，因为咱们不得不否定传统的思维形式，” AE-1团队负责人回顾说。佳能公司另一位高管答复说：“然而咱们每天在业务的日常工作中都这样做。”整个组织每天都会进行渐进式改良，以强化总裁所说的“根底”：研发，生产技术，销售能力和企业文化。 本田城市我的项目团队也实现了冲破，超过了现状。这个团队被要求为年轻人开发一款具备两项竞争性特色的汽车:在资源和燃料方面的效率，以及在价格上毫不妥协的品质。车队的本能是开发一款放大版的本田滞销思域车型。然而通过一番探讨，团队决定开发一款全新概念的汽车。它挑战了汽车应该长而低的风行观点，设计了一辆“短而高”的汽车。确信向“机器最小，人类最大”概念的演进是不可避免的，团队违心冒险去违反行业标准。 异花受粉（跨畛域）。由具备不同职能业余、思维过程和行为模式的成员组成的我的项目团队进行新产品开发。例如，本田团队由来自研发、生产和销售部门的精心筛选的成员组成。该公司更进一步，在团队中安插了各式各样的人物。这种多样性孕育了新的思维和概念。 尽管抉择一个多样化的团队是至关重要的，但直到成员们开始相互作用，才会真正产生跨畛域。富士施乐将多功能团队建设成一个大房间，包含来自打算、设计、生产、销售、分销和评估部门的成员。一个我的项目成员为这个步骤给出了如下的基本原理:“当所有的团队成员都在一个大房间里时，有些人的信息就会变成你的，甚至不须要尝试。而后你开始思考什么对整个群体是最好的，什么是第二好的，而不仅仅是你的立场。如果每个人都了解对方的立场，那么咱们每个人都更违心退让，或者至多试着相互交谈。后果就产生了各种倡导。” Overlapping Development Phases 重叠的开发阶段团队的自组织个性产生了独特的动静或节奏。只管团队成员开始我的项目的时间跨度不同——研发人员的时间跨度最长，生产人员的工夫最短——但他们都必须同步进度以满足最初期限。此外，尽管我的项目团队从“零信息”开始，然而每个成员很快就开始共享对于市场和技术社区的常识。后果，团队开始作为一个整体工作。在某些时候，集体和整体变得不可分割。个体的节奏和群体的节奏开始重叠，发明了一个全新的脉搏。这种脉搏推动着团队后退。 然而脉搏的快慢在不同的倒退阶段是不同的。节奏在开始阶段仿佛最无力，并在靠近序幕时逐步削弱。佳能PC-10开发团队的一名成员这样形容这一节奏:“当咱们在探讨要创立什么样的概念时，咱们的思维就会向不同的方向发散，并列出备选计划。然而，当咱们试图同时实现低成本和高可靠性时，咱们的头脑会致力整合各种观点。当一些人试图辨别而另一些人试图整合时，抵触就会产生。窍门在于发明这种节奏，并晓得何时从一种状态转移到另一种状态。” 在程序或接力赛的办法下，一个我的项目以循序渐进的形式经验几个阶段，只有在满足了前一阶段的所有需要之后，能力从一个阶段过渡到下一个阶段。这些检查点管制危险。但与此同时，这种办法简直没有为集成留下空间。某个阶段的瓶颈可能会减慢甚至进行整个开发过程。 在整体或橄榄球办法下，这些阶段有相当大的重叠，这使得团队可能排汇整个开发过程中产生的振动或“乐音”。当瓶颈呈现时，噪声程度明显增加。但这一过程不会忽然进行;团队设法向前推动。 富士施乐从其母公司继承了PPP零碎(见附件1中的A型)，但对其进行了两方面的订正。首先，通过从新定义一些阶段并以不同的形式汇集它们，将阶段的数量从6个缩小到4个。其次，它把线性的、程序的零碎变成了所谓的“生鱼片”零碎。生鱼片是将生鱼片排列在一个盘子里，一片与另一片重叠(见表2)。 (附录2富士施乐的产品开发打算) 生鱼片零碎须要宽泛的互动，不仅在我的项目成员之间，而且与供应商。FX-3500团队一开始就邀请他们退出这个我的项目(他们最终生产了模型90%的部件)。单方定期拜访对方工厂，并始终保持信息渠道畅通。这种替换和凋谢——在我的项目团队外部和与供应商之间——进步了速度和灵活性。富士施乐将晚期型号的研发工夫从38个月缩短至29个月。 如果生鱼片定义了富士-施乐的办法，那么橄榄球将形容本田的重叠之处。像橄榄球队一样，本田的外围我的项目成员从头到尾放弃残缺，并负责将所有阶段组合在一起。 在相似继电器的PPP零碎中，要害的问题往往产生在一个团体将我的项目移交给下一个团体的中央。橄榄球办法通过放弃跨阶段的连续性来解决这个问题。 ...

本文基于面向基本公共卫生的业务系统设计经验，抽象出一套适合大型ERP系统的表单业务数据模型，目标是最大限度保留系统弹性的同时，尽可能降低系统复杂度和开发成本。enjoy~背景填写表单应该是所有业务线条中最避免不了的环节，例如我所经历的医疗项目：以上面两个例图作为示例，可以看到姓名、性别、出生日期、血型等字段是完全重复的，由于业务场景的差异，表单被定义了不同的样式和字段结构，此时将遭遇以下几种问题：同一用户经历了两个不同场景时，不得不重复填写相同的字段；如果相同的字段在两个表格中的值不同，基本无法判断哪个为正确值，例如同一个人在居民健康档案中血型填写为A型，而在居民健康档案信息卡中填写为B型；某些字段会重复出现在不同的表单中，随着业务需要，将其串连起来查看其趋势，如身高、体重、血压、心率等等，以帮助医生确诊疾病，然而这些字段保存在各自的表单中，由于开发人员的变更、文档的遗漏和产品的迭代，无法穷举出所有的这些字段数据来源，即便能够回溯所有的来源，本身也是一件十分消耗精力的事情；因为政策或业务需要，要在原有的表单上做调整，新的标准导致表单字段产生变化，此时原有系统为保证其运行的稳定，难以从数据表和底层代码中迭代，只能新增数据表做开发，当表单需求频繁变化时，加剧数据碎片化的问题；新增业务表单时，开发需要订排期，用户需要等待发版后才能使用，新增大量表单时影响原有开发计划的同时，业务部门也难以快速开展系统业务。做数据统计和分析时，由迭代造成的数据字段遗失或变更，无法统计出完整而准确的数据，做出的报告难以反映出真实的情况….传统的区域化基本公共卫生系统正在经历这样的剧痛，当然其他行业比如金融的部分业务同样面临相同问题（本人只经历过这两个行业，见谅），如何在纷繁复杂的业务环节中抽离出四两拨千斤的数据模型，除了满足日益频繁的业务调整外，还能将数据完整的、标准的存储并利用起来，是后端产品经理的安身立命之本。作为一个不务正业的产品经理，这次就从数据库表结构设计上，介绍一套解决方案：结构化动态表单。场景和需求：1.可覆盖绝大部分表单业务场景。2.表单样式和字段可灵活调整，不影响历史积累数据，不会造成数据库和代码层面的频繁变更；3.数据统计时能够快捷、准确、全面地获取到想要的字段数据，不过度依赖文档和程序员老员工；模块介绍属性库所有表单中所有的字段都在属性库中定义，相当于表单字段的字典。定义的核心包含属性的唯一标识、属性名、属性值取值规则和约束等信息。因为我认为所有的字段都是围绕某个业务进行的，把这个业务抽象成对象，那么这些表单的字段就是这个对象的属性，所以命名为属性库如果用关系型数据库表达属性库，根据以往的经验可以总结出如下两个基础表：属性分类，主要根据使用者需求对属性进行分类，方便查找和后期的批量数据统计，比如健康管理把心率、瞳孔大小、脉搏等属性规划到生命体征类，把身高、体重等属性规划到基本体征类等等，因此仅需要定义唯一识别码、名称和分类说明即可。属性，这个表非常重要，是数据标准化的基础表。唯一标识、名称、说明，这是一个属性最基础的说明，不用解释。分类ID字段可支持多个ID，表示一个属性可划分到多个分类下，这个可根据实际需求定义，我所经历的场景是有这种情况的，比如心率，既可以是生命体征类属性，也可以是临床诊断类属性，很难绝对界定。当然属性和属性分类也可以通过单独建关系表来定义对应关系，方法有很多，各有优劣，看技术leader自行选型吧。属性类型，根据个人的经验，总结出图中的几种类型，相信大家都认识，不用展开，其中单选框、多选框两种类型因为还依赖对应的取值字典，因此还需要到属性值字典中定义取值选项。另外值单位这个字段，方便做数据转换和终端数据展示用，比如时长的值60，单位是分钟，通过算法即可转换该单位的值为1小时。属性值字典，主要用于配合属性类型为单选框或多选框的取值，也是数据标准化的一部分。例如定义一个属性叫性别的属性规划到基础信息分类中，此时会属性库的三个表中分别插入以下数据：属性分类表：ID=‘1’，分类名称=‘基础信息’，分类说明=‘用户基本信息’属性表：ID=2，分类ID=‘’，属性名称=‘性别’，属性说明=‘用户的性别’，属性类型=‘单选下拉框’，值单位=空属性值字典：[ID=3，属性ID=‘2’，字典值=‘男’],[ID=4，属性ID=‘2’，字典值=‘女’],[ID=5，属性ID=‘2’，字典值=‘未知’]模版库所有的动态表单都是以模版的方式保存在数据库中，表单模版中定义表单中填写的字段、字段的默认值和表单样式。由于表单样式的不可预见性，因此可以准备一套符合自家产品风格的视觉设计语言，限定表单视觉样式的框架，包含前面提到的属性类型呈现样式，和细化到UI在手写、PC端、移动端的字体大小、线条风格、交互方式、间距、缩进、比例、布局方式等参数，当然本篇由于篇幅限制不展开和视觉风格相关的讨论，读者可自行脑补。既然是模版，肯定少不了控件，模版由控件组成，在这里把控件分为两类：属性组件和容器组件。表单模版，是表单的字典表，用于定义表单的基础信息如名称、用途说明等，如果与业务衔接，还可以添加关联的业务、填写对象、触发填写的时间等，这部分信息由具体的业务场景决定，可根据实际需求设置字段。容器组件，负责定义外观样式的组件，决定了属性组件在表单中的呈现样式，可根据不同布局需求细分更多容器组件，这里不展开细讲。顺序号，在同级下的显示排序，从左至右，从上至下的原则进行排列。容器名称，即表单中某方框的名称，可不填在终端显示表单时，需要充分考虑各个组件在页面上的默认布局参数和可变参数。通常前面提到的设计语言中会定义标准的内边距外边距、线粗和线色等视觉样式，这些就是默认布局参数，但组件在表单中的显示顺序、嵌套关系和组件内的组件排列方式等参数多数时候是需要配置的，依据实际需求添加参数即可。容器组件可嵌套，当遭遇多级层级关系时，用容器组件实现嵌套关系再好不过了，不建议属性组件也支持嵌套，因为会提高属性值的取值复杂度，除了开发和数据存储逻辑复杂度高外，后期数据分析时也会进入逻辑黑洞，应尽量避免是否支持累加数据，此字段用于控制组件内的元素，是否可以按照定义的字段多组生成，例如如：在容器组件主要用药情况中，属性组件药物名称、用法、用量、用药时间、服药依从性的值可以添加多次还可以添加跟多字段或子表，描述容器更多的视觉布局样式，比如支持PC端、移动端、打印手写的样式定义。属性组件，来自于属性库中的属性，决定了表单中填写的字段信息。容器ID，当前属性组件放置在某个容器组件内，若值为null，表示直接放置在表单中属性别名，为适应部分个性化的需求，可以为属性定义别名，比如身高，对婴儿通常叫身长，对青少年或成年人叫身高。别名定义到模版中而不是在属性库的意义在于，用户的个性化称呼通常只会在自己所处的场景内使用，对于其他场景下的其他用户并不一定通用。属性默认值，很好理解，没用把这个字段放到属性库的理由和别名一样，场景不同，默认值不一定通用。是否必填，表单提交前判断必填项的依据。页面区域，用于判断当前组件出现在其父组件的位置，枚举类型。属性组件还可以有更多可扩展特性，后面会提到一些。业务数据库有了前面的属性库和表单模版库的配置，即可配置出各式各样的表单，而实际使用这些表单保存下来的数据格式是怎样的呢？表单主表，作为表单的索引表，主要是提供表单的填写来源、时间戳和与业务相关的标记。通常实际业务有很多附加的信息，图中给出的是本人面临的业务场景常见的字段。容器明细表，这里保存了表单内负责样式的容器数据，因为表单模版可能会变更，因此需要将其视觉样式数据保存下来，以记录当时呈现的样式，避免因为模版变更而造成的布局样式丢失。属性明细表，保存了所有表单的所有字段的值。为了配合容器组件记录其布局样式，还添加了容器ID、顺序号、组号、页面区域，用于记录保存表单时属性在表单中的位置。组号，当遇到属性组件放置在允许累加数据的容器组件中时，标记出属性值所在的组。别名，若属性在模版中配置了别名，则保存在这里，如果值为空，则显示原属性名。修改时间，表单可能会遇到修改部分数据，因此标记字段的最后修改时间。如果有属性值的操作日志，可以不要。样例弊端动态表单的存在，在一定程度上可以缓解产品迭代因业务变更带来的压力，但其开发复杂度较高，尤其表单模版，解析模版数据呈现到终端时，依赖遍历算法，对程序员的要求不低，若整套产品的应用规模不大，不建议使用动态表单，或者根据需求开发简配版。由于表单依赖属性库和表单模版的配置，属性和表单模版的维护质量决定了表单的数据质量，因此需要有高度责任心和专业能力的人员来进行属性库的维护，提高了使用门槛，但反过来讲，罗马不是一天建成的，如果有野心建立行业标准，本身也需要大力投入数据质控。设计思想和基本原则产品开发和业务运行尽可能的解耦。业务人员不必完全依赖产品业务功能的情况下才能运行相关业务（这个问题单独靠动态表单无法完全解决，还需要依赖工作流，不过没有动态表单时也可以勉强适应部分场景做业务试运行）；产品永远做功能迭代，尽量避免数据迭代。常见的C端产品往往会有很多的营销推广广告页，这些广告页常常会频繁变化，而且为了抓热点往往需要即时响应跟进，如果按照每周发版1-2次的节奏，等发出来商业机会已经凉了，因此往往会做一个后台配置广告页的功能，使运营人员可以自行配置广告页面，包含页面元素、入口布局、外链引导、渠道埋点配置等等，这就是功能迭代。如果运营改一次广告，产品即发一次版，这就是数据层迭代。每一次变更都将累积相应的数据，产品是生成这些数据的工具，产生数据是业务人员做的事情，产品和业务是冰淇淋机和卖冰淇淋的小姐姐的关系。用户永远只能看到功能，只关心产品是否满足其需求，而产品经理永远要从高低远近多维视角看待和解构需求，不断的整合、重组、拆分、归纳，穷举各种场景下的业务形态，在业务耦合和模块化处理上达到平衡，本质上是优化效率，创造利润，如果达不到这两个目的，这个产品不能叫产品，只叫艺术品。提前预判功能模块的发展趋势，在设计初期预留充分的扩展性和迭代方向，避免高频率的推倒重来，当然如果是敏捷开发，请无视这条。意义属性库即数据规范，如果数据量在行业中足够大，适用面足够广的情况下，具备发展为行业规范的潜力。表单模版即数据接口标准，当多个系统需要进行数据对接时，最头疼的往往是梳理数据对接标准，将需要对接的数据模版通过接口规范的方式导出给对接方，数据字段和取值规范一目了然，新老系统导数据也会用到。数据利用更加便捷方便，需要查询某项具体的属性数据时，只需到属性明细表中即可找到，无需遍历其他业务表单用户可通过配置表单明确新需求，表单模版一定程度上提高了用户需求和功能落地的沟通效率，一定程度上提高了产品的业务可扩展性扩展性以下是随意举例的可能的功能扩展方向，仅作为扩展阅读属性组件功能扩展多属性之间的逻辑约束和默认值性别为男时，诊断中不可出现妇科疾病年龄在18-21岁之间，职业默认值为大学生填写了身份证号码即可解析出籍贯、性别和出生日期单属性复用姓名性别等字段用户一旦填写后，以后再次填写有这些字段的表单即可自动填写属性值字典诊断、症状字典数据可能依赖外部接口调取，而非本地属性值字典库容器组件扩展可配置容器背景图，视觉优化内部元素排列方式支持左对齐、右对齐、垂直排列、水平排列等可套用整体视觉设计的皮肤模版库扩展模版插入公用参数字段，如表单中的制表机构、填表人、所在科室等等表单中的字段可作为工作流业务环节控制字段，比如当支付方式为现金时，无需弹出支付二维码操作日志记录所有用户在业务表单上的操作记录，包含操作人、时间戳、修改前属性值记录所有用户在属性库和表单模版库上的操作记录