科技猎减少产品背锅的思维神器——灵活化设计
我记得刚做产品那会，有一个很搞笑的事，那就是开发问我，“直接写死还是做成可配置”，我傻傻的回答说：“直接写死”。然后就看着开发呵呵偷笑着走开了。
当然不久后我就知道，开发为什么偷笑了。项目上线后，自然最后也给自己挖了不少的坑，可谓是相当被动。
随着对产品的理解愈发深入、对技术实现更加了解，我在早期开始逐步形成了自己的设计方法论，其中很重要的一种就是“灵活化设计”。
灵活化是一种思维，是一种趋势。
市场经济中，人们需求呈现出一种快速变化的趋势，多样性、可选性、不确定性的特征越来越明显。
今天还在用支付宝扫码支付，明天可能就全部用刷脸支付了；今天还在优酷刷视频，明天可能就全跑去B端当弹幕大军了。
今天给用户发一张满减券，明天换着发一张折扣券；今天上了一个促销活动，明天就要更换一个新活动。
这种市场快速变化的特性将成为互联网行业、甚至是全社会在未来很长一段时间常态化的标签。
这就要求产品在设计过程中需要充分考虑、提前考虑这种灵活化的要求。
一家公司一年内可能有很多新需求、会做很多新产品、有很多新迭代、有很多新变化。没有东西是做好了就不会变的，拥抱这种变化，才能不断完善自己的产品。
1、参数的灵活化
比如最简单的，开发会问这个参数要不要写死？
这个时候，你就需要评估这个参数会不会变化？如果经常会变化，那肯定不能写死，因为写死就意味着每次变化的时候，都需要开发更改后发布，麻烦且耗时，对用户也不友好（需要更新app）
再比如搞一个线上活动，如果活动直接写死在页面上，遇到一些突发情况想要下架活动，开发还要手忙脚乱的修改线上代码将其下架，如果提前考虑做个“可下架”的配置项，是不是就很轻松了。
2、流程的灵活化
做saas的小伙伴一定深有体会，那就是不同的客户的业务流程有所区别。
比如对于医疗诊所来说，主流程大致都是预约、登记、分诊、问诊、检查、缴费、配药。但是有些小诊所因为只有1个医生，不需要分诊，如果你把这套流程做死，也就是说必须要经过分诊后才能医生问诊，那对于这家诊所来说，根本无法使用这套产品。
有些诊所还会把收费和发药统一让1个人来一次性执行完成，那么从流程角度来讲，就无须把收费和发药拆成两步完成。如果流程固化就会很尴尬，要么只能满足这家客户，要么只能满足另一家客户。
3、技术架构的灵活化
我们知道，电商app中，提交订单页是一个非常重要的页面，既要关联很多不同的业务模块，又要保证其稳定性和数据安全性，所以提交订单页的设计方式非常重要。
这是一个外卖平台的提交订单页，可以看到里面有很多信息，有配送方式相关的、有促销活动相关的、有积分抵现、电子券抵扣等。
很显然，随着业务的发展，营销活动会越来越多，每次新增一个优惠方式，就需要对提交订单页进行改造。有些公司甚至有多条业务线，都会有提交订单页，且不同的业务线的提交订单页中，可用优惠方式和逻辑也不尽相同。
如果我们每次都用写死的方式，那么可想而知，迭代起来会有多痛苦。
但是事实是，很多公司确实把这个页面在前端进行写死了。什么意思呢？一旦用户进入到【提交订单】页，每个人看到的条目都是一样的，只不过后面的数据（1张券还是2张券、抵扣可抵扣3元还是5元都是由服务端返回的）。
于是当业务需要新增一种促销方式的时候，单一产品线中，IOS端、安卓端、H5端、小程序端，就得对4端进行修改，要是像阿里这种内部有淘宝、天猫、聚划算、盒马等多条产品线的时候，那真的是要耗费极大的人力成本和时间成本。
所以从灵活化的角度来讲，对于前台业务到底显示那些可用促销方式，完全可以由后端返回，而不是在前端写死，这样的话要新增一种促销方式，只需要在后端进行配置，即可同步到4端，以及多条产品线中。
这就是技术架构中的灵活化思维，利用的好能大幅减少技术成本。
当然灵活化的应用还有很多，我这里只举3类例子，大家还可以结合自己的日常工作找一些可以灵活化处理的场景。
当我们再考虑灵活化的时候，本质上我们在考虑什么？
我们希望一套产品、一套系统可以尽可能的变得“健壮”，当他面对任何风雨的时候，都能屹立不倒。
这种灵活化大大的提升了产品的抗风险能力，同时在风险来临的时候，可以用最轻便、最低成本、最高效的方式进行解决。
说灵活化是一种思维，因为它可以被应用在生活中的方方面面，而不只是产品设计。
比如我们在考虑一件事该如何解决的时候，并不应该一言以蔽之，这件事发生在不同的情况下，所需要的处理方式是不一样的，对我们来说，往往需要针对不同的情况预设几种方法来针对性的解决，这就是灵活性思维所带来的执行上的变化。有些人只想了一个固定方案，结果发现当场景有所变化时，这个方案就行不通了，然后又没有提前准备Plan B，于是就陷入了僵局。
所以，多些灵活性思维，它能让你变得更加的从容。
以上就是“减少产品背锅的思维神器——灵活化设计”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站。
当然不久后我就知道，开发为什么偷笑了。项目上线后，自然最后也给自己挖了不少的坑，可谓是相当被动。
随着对产品的理解愈发深入、对技术实现更加了解，我在早期开始逐步形成了自己的设计方法论，其中很重要的一种就是“灵活化设计”。
灵活化是一种思维，是一种趋势。
01
为什么需要灵活化
市场经济中，人们需求呈现出一种快速变化的趋势，多样性、可选性、不确定性的特征越来越明显。
今天还在用支付宝扫码支付，明天可能就全部用刷脸支付了；今天还在优酷刷视频，明天可能就全跑去B端当弹幕大军了。
今天给用户发一张满减券，明天换着发一张折扣券；今天上了一个促销活动，明天就要更换一个新活动。
这种市场快速变化的特性将成为互联网行业、甚至是全社会在未来很长一段时间常态化的标签。
这就要求产品在设计过程中需要充分考虑、提前考虑这种灵活化的要求。
一家公司一年内可能有很多新需求、会做很多新产品、有很多新迭代、有很多新变化。没有东西是做好了就不会变的，拥抱这种变化，才能不断完善自己的产品。
02
灵活化体现在哪里
1、参数的灵活化
比如最简单的，开发会问这个参数要不要写死？
这个时候，你就需要评估这个参数会不会变化？如果经常会变化，那肯定不能写死，因为写死就意味着每次变化的时候，都需要开发更改后发布，麻烦且耗时，对用户也不友好（需要更新app）
再比如搞一个线上活动，如果活动直接写死在页面上，遇到一些突发情况想要下架活动，开发还要手忙脚乱的修改线上代码将其下架，如果提前考虑做个“可下架”的配置项，是不是就很轻松了。
2、流程的灵活化
做saas的小伙伴一定深有体会，那就是不同的客户的业务流程有所区别。
比如对于医疗诊所来说，主流程大致都是预约、登记、分诊、问诊、检查、缴费、配药。但是有些小诊所因为只有1个医生，不需要分诊，如果你把这套流程做死，也就是说必须要经过分诊后才能医生问诊，那对于这家诊所来说，根本无法使用这套产品。
有些诊所还会把收费和发药统一让1个人来一次性执行完成，那么从流程角度来讲，就无须把收费和发药拆成两步完成。如果流程固化就会很尴尬，要么只能满足这家客户，要么只能满足另一家客户。
3、技术架构的灵活化
我们知道，电商app中，提交订单页是一个非常重要的页面，既要关联很多不同的业务模块，又要保证其稳定性和数据安全性，所以提交订单页的设计方式非常重要。
这是一个外卖平台的提交订单页，可以看到里面有很多信息，有配送方式相关的、有促销活动相关的、有积分抵现、电子券抵扣等。
很显然，随着业务的发展，营销活动会越来越多，每次新增一个优惠方式，就需要对提交订单页进行改造。有些公司甚至有多条业务线，都会有提交订单页，且不同的业务线的提交订单页中，可用优惠方式和逻辑也不尽相同。
如果我们每次都用写死的方式，那么可想而知，迭代起来会有多痛苦。
但是事实是，很多公司确实把这个页面在前端进行写死了。什么意思呢？一旦用户进入到【提交订单】页，每个人看到的条目都是一样的，只不过后面的数据（1张券还是2张券、抵扣可抵扣3元还是5元都是由服务端返回的）。
于是当业务需要新增一种促销方式的时候，单一产品线中，IOS端、安卓端、H5端、小程序端，就得对4端进行修改，要是像阿里这种内部有淘宝、天猫、聚划算、盒马等多条产品线的时候，那真的是要耗费极大的人力成本和时间成本。
所以从灵活化的角度来讲，对于前台业务到底显示那些可用促销方式，完全可以由后端返回，而不是在前端写死，这样的话要新增一种促销方式，只需要在后端进行配置，即可同步到4端，以及多条产品线中。
这就是技术架构中的灵活化思维，利用的好能大幅减少技术成本。
当然灵活化的应用还有很多，我这里只举3类例子，大家还可以结合自己的日常工作找一些可以灵活化处理的场景。
03
灵活化是一种底层能力
当我们再考虑灵活化的时候，本质上我们在考虑什么？
我们希望一套产品、一套系统可以尽可能的变得“健壮”，当他面对任何风雨的时候，都能屹立不倒。
这种灵活化大大的提升了产品的抗风险能力，同时在风险来临的时候，可以用最轻便、最低成本、最高效的方式进行解决。
说灵活化是一种思维，因为它可以被应用在生活中的方方面面，而不只是产品设计。
比如我们在考虑一件事该如何解决的时候，并不应该一言以蔽之，这件事发生在不同的情况下，所需要的处理方式是不一样的，对我们来说，往往需要针对不同的情况预设几种方法来针对性的解决，这就是灵活性思维所带来的执行上的变化。有些人只想了一个固定方案，结果发现当场景有所变化时，这个方案就行不通了，然后又没有提前准备Plan B，于是就陷入了僵局。
所以，多些灵活性思维，它能让你变得更加的从容。
以上就是“减少产品背锅的思维神器——灵活化设计”的内容了，如果你还想了解其他相关内容，可以来 产品壹佰 官方网站。
