1994 年，中国正式接入因特网。将近 30 年的时间，学界普遍认为，经历了三个特征性的阶段。
第一阶段“建立信息获取”，互联网作为新兴媒介得到关注，门户类网站和搜索兴起，进入互联网的入口相对集中，信息从“被动接收”到“主动发掘”逐步转化。
第二阶段“建立信息传播”，人因属性进一步加强，人人皆可创造信息，以人为主体的信息链传播出现，刺激表达自我和沟通情感。流动的信息、社交化网络成为主流。
第三阶段“健全信息场景”，极大的用户量，催生了一系列的网络服务和商业机会，互联网产品变得更加的具体化和场景化。与此同时，移动互联网爆发，4G 技术的成熟，信息的流通进入个人生活的方方面面。
互联网的发展从最初的“集中式单向信息分发”到现在的“基于场景化的信息服务“，围绕的始终是“人”这个主体。
疫情场景之下，社会生产条件发生了更多微妙的变化。除个人生活消费需求持续得到满足，“线上办公、线上管理”的企业信息服务需求，也成为不可忽视的存在。
此类需求以企业团队为使用的主体，呈现强的群体办公协作性，填补上因疫情难以开展的线下工作模式，再次激活了各类产业对于互联网融入的期待。
在更早的时候，互联网呈现出的创造能力已经默默牵动着传统产业的变革。
各个产业领域积极探索融合可能性，例如在生产、流通、交易过程的效率提升，平台性资源的整合统筹， 洞察新的业务风口和营收模式等等，确实带来过成功的案例。同时，变革也伴随着未知的风险，成本激增让传统企业变得格外谨慎。
产业互联网不会是一蹴而就，它依赖很多基础条件的建设，也依赖人们对互联网价值的正确认知。
产业互联网不是简单加入互联网的数字化，信息化技术，它不止于在原来的基础上去增加因素，而是从底层逻辑去重塑产业模式。
产业互联网也不仅是为互联网企业去扩展范畴，而应是以互联网技术和精神去深化产业的发展方向，以虚心学习的姿态去服务和解决产业的难点，带来真实有效的价值，助力于产业的良性成长。
消费互联网（C 端）和产业互联网（B 端），在场景、角色、需求上都存在巨大差异。
C 端产品的成功经验，更容易让我们陷入盲目自信，把对“个人用户”的理解方式简单映射到对“企业客户”的理解上。
虽然产品服务对象最终仍是落到“人”这个个体，但强烈的专业属性，多环节多角色群体协作性，商业经营特性等，都将导致在“客户采用决策”和“服务体验感受”等基础因素的理解上有着巨大的不同。
我们也走过弯路，甚至一度沮丧，质疑设计在整个 B 端产品中存在的价值。作为跟随大趋势转型中的设计者，我们持续思考着这个新课题，也从中慢慢看到巨大的机遇。
作为探索 B 端的设计者，我们需要做好一些储备。
更多B端设计干货：
前言接触 B 端设计的小伙伴会发现，很多业务具有角色多，业务场景复杂，功能链路长等特点，所以在工作中会经常遇到以下几个问题： 突然被调配到新业务，拿到一个不熟悉的业务或者新产品，不知如何开展工作？
阅读文章 >“商业产品”是向特定客户群体提供能力服务，实现商业盈利的产品。本身具备“使用属性”和“商业属性”。
C 端
互联网产品服务于个人，使用者具有高的支配权和决策权。在获取成本极低且免费的产品占绝大多数的环境之下，“使用属性”是被提及的第一要素。
“产品体验”作为使用的增强剂一直是 C 端产品制胜的法宝，优秀的视觉效果让用户一见钟情，有效有趣的交互模式让用户不亦乐乎，加上对人性欲望的深刻洞察使产品功能变得极具“诱惑力”，最终独占用户尽可能多的投入时间，在用户停留的过程中去实现“商业属性”的变现。
B 端
盈利目的更加直接，“商业属性”成为关注的第一要素。
产品使用者和购买决策者通常为不同的人群，决策者从经营利益出发，思考的是购买成本、运营成本和最大化利己的交换条件。
不同决策者因政策环境、行业属性和心态等的不同，需要灵活的与之沟通的手段，厂商的“销售服务”能力是核心。
另外，经典商业场景中，货源和客户是极难对应上的，“销售服务”承担起把信息的不对称打通，带来直接盈利转化。
销售专员既要深度了解产品的全部能力，又需要掌握错综复杂的社会人脉网络和需求，特别是在重要的 KA 客户层面，优秀的客情关系能极大的助力赢单。
在任何产品稀缺，获取困难，单价昂贵，但客户又有明确购买需求的环境下，能连接一切，促成交易的沟通能力必然是非常重要的。
所以，在 B 端产品的生命周期中，销售环节传递出的建议往往是产品改善的重要指导方向。
互联网对传统产业的影响，同样影响着互联网企业对 B 端产品的建设思路，从 AWS、阿里等同质云厂商的发展历程看，平台化机制将越来越深刻的影响 B 端产品的售卖策略。
销售专员服务仍然会是商业运作不可或缺的重要一环，为保证健康的客情维系，甚至会孵化出“客户成功”的专业技术部门。
在接下来长远的时间里，B 端产品仍需要通过销售专员来连接 KA 客户“人”的情感（产品价值感、服务品质、尊贵身份象征、业务需求满足等），大额商品的购买决策，不会只是一次付费的行为。
同时，平台将会分担更多非 KA 客户的销售职能，改变现有销售侧重。
首先，平台化后，产品更容易被全面对比。
当变得触手可及，有更多的厂商提供到类似的产品能力和服务时，客户的心理就会从“我好像只能选用你“变成“我为什么选用你”。
客户在选择产品的时候可考虑的因素变得丰富，这个时候“试用模式”被广泛启用，产品的核心能力需要凸显，“使用属性”中“产品体验”的价值也将有所提升，以作为“销售服务”有利的支撑。
我们甚至可以看到 PLG 的形式得到强化，也侧面说明，使用者参与决策，影响决策者购买选择的趋势在加强。
和 C 端一样，人性将再次成为产品构建考虑的因素之一；但与 C 端讲究“感官享受”不同，B 端的体验设计一定是以“效率（更好、更快、更省心）”为第一位。
“效率”需要层次感的设计，让使用者少想一点，让机器多想一点。本质上工作是令自然人没那么开心的事情，更快的完成任务特别是重复式任务，一定是 B 端产品要解决的基础问题。
其次，平台化势必造就标准化。
在产品构建初期，由于对行业市场的不了解，以及对于赢单的渴望，产品往往呈现割裂堆叠、体验精分的状态，看似什么都有但都不行。
从我们曾主导过的“3D 可视化”案例看，最初觉得“客户根本不懂要什么，我们有能力引导”到懂得“客户也专业，还是出资方，需求尽量满足”，再到思考“客户需求有通用性，能达成标准交付”，再到发现“每个客户觉得他说的才是标准化，我们定义的标准难以成为标准”的一系列过程。
没能抓住行业需求核心，让销售、产品和设计一直处于凌乱中。
一千个人眼中有一千个哈姆雷特。平台化将让产品的客户触达面更广，意味着我们在经历前期洗礼后，必须明确基本功能和优势卖点，尽快建立产品的标准化和套餐化（可订阅可扩展），过滤客户的冗余需求，好产品绝非万能。
同时需要建立更高效的销售和运维的弱参与模式，缓解指数级增长的客户服务；也需要构建起设计组件的标准化，系列产品体验的一致化，以减少产品快速搭建过程的时间消耗和客户使用过程的认知疑惑。
再者，定制化的需求也永远不会消失。
第二次工业革命，商品的工业化取代了传统的手工艺体系，以包豪斯为代表的现代设计思潮开始关注新型生产力带来的社会变革。
工业革命让更多平民能使用上商品，所以如何在提高生产效率的同时带来商品品质提升成为包豪斯在近现代史上不可磨灭的贡献。
目前从事 B 端设计，致力于改善传统产业办公效率的同学们，何尝不是类似的先驱呢。
但是，工业化生产并不能消灭定制化的需求，这种定制化远不止是为了达成“差异化”。定制化是建立在有效标准化的基础上。
《王牌特工》里主角在萨维尔街 H Huntsman & Sons 定制西装，这家店在 1846 年营业至今，比第二次工业革命（19 世纪末）还要古老。劳斯莱斯仍是以“纯手工，定制化打造”为荣，依照客户的合理需求打造专属而尊贵的产品。
投入价值是为了得到更广的价值。
有人可能觉得 B 端企业级产品不可能达到这样的价值高度，我的理解是互联网还太年轻，我们把定制服务的价值想得太简单。
最后，人对信息处理的演化也是设计需要思考的因素，关于“信息过载”和“体验的代际差异”。
21 世纪是信息量暴增的时代。以安全产品为例，10 年前的全局防御系统只相当于现在海量安全系统的一小块。
攻防对抗升级，渗透形式多样性导致防御手段的多样性，从被动防御到主动防御再到动态防御，同时带来的就是防御平台的精细化。一个企业需要大量产品来应对不同的威胁，而安全运维的人力可能并没有上涨。
“信息过载”导致效率低下，B 端产品“信息聚合”“信息可视化”设计是必然的趋势，但现状的可视只是第一步，第二步是信息的倾向，第三步则涉及应对的机制。
深入了解使用场景，综合视角，克制功能铺张将是 B 端产品设计的趋势。
“体验的代际差异”是指，伴随人们高频使用互联网产品，体验阈值被不断提高。
正如电视控制组件，从黑白电视的旋钮开关，到彩电的多功能遥控器，再到互联网电视的简约功能遥控，人与设备的交互方式，基于技术变革产生了演化。
如今 B 端产品的使用者也都在使用着安卓系统、苹果系统，他们与 10 年前对产品“可用”的理解有着巨大的变化。
当有功能类似、体验更优秀（操作清晰，简单高效）的同类产品出现，即使迁移有成本，也会比以往更具更换的决心。
在 B 端“商业属性”优先的策略下，中短期内“重渠道建设”、“产品功能快速应标”等成为主要的目的，设计远离客户（设计者对行业了解深度不足）。
这个客观限制条件之下，控制台的体验打磨很难执行，“经典 UI”设计能输出的价值有限。幸运的是设计陪伴产品经历过一个重要的时刻，让我们意识到在 B 端可能的发展模式。
C 端向 B 端转型时业务遇到巨大的不确定性。B 端安全产品对企业系统和网络技术的理解要求高，对行业市场的了解也还存在较多盲区，紧接着一年的时间，尝试多种方向，产品需尽快找到赛道。
“产品死，设计也得死”是相当长时间悬在头上的“达摩克利斯之剑”，我们需要为业务生存主动去思考一些事情。
设计能做点什么？要不我们协助做“市场研究”？
以产品较坚定想探索的某一个方向出发，从主要市场玩家的“基本面分析：国内外发展历程、营收现状、经营杠杆...”到“产品分析：产品线矩阵关系、核心竞争点、收购的战略意图...”，再到“市场分析：市场策略、客户构成、收入结构和留存、渠道分析...”。
我们查阅 Gartner/IDC 等行业安全报告、头部产品白皮书和能收罗到的各类财报和新闻，加入设计团队的理解整合成多份报告，辅助产品同事在更完善的情报支撑下做出了关键决策。多次主动贡献的价值得到产品侧的高度认可。
此刻，设计者也意识到 B 端设计需要跳出“经典 UI”视角，为更完整的链路视角做好服务。
而后，我们主动学习 B 端产品生态全链路包含了哪些环节。
我们了解了公/私有云的销售模式，感受销售专员在“收入压力”之下的难处和渴求；了解售中签单的流程转化，让我们更加尊重构建辅助系统的项目专家默默的付出；了解了私有化部署交付过程中的痛点，各类接口的不统一和业务数据与安全数据混建的纠结；了解了售后运维用血汗堆建服务口碑，懂得不负责任的承诺和不靠谱的产品质量带来的惨痛教训。我们也看到在为“腾讯企业安全”大品牌对外发声，战略部、市场部和公关部同事一次次用心的策划。
B 端确实是团战模式，从客户的“获取、激活、留存、收入转化到口碑推荐”，各类角色在产品生命周期不同阶段中会有侧重的演绎。
以“尽力做好服务”为初衷，“经典 UI”无法企及的广大领域里，还存在多少设计者能去设计增值的地方？
自研产品三年时间，从几个到二三十个的发展。设计团队以腾讯云 UI 规范为底座，填充安全 UI 组件。快速学习企业安全领域知识，配合技术型产品、销售型产品同事构建和迭代安全平台。与此同时，我们给自己下了“助力销售”的要求。
首先，我们发现安全业务理解的抽象和复杂性，使销售专员难以短时间学习并有效告知客户。于是，我们凭借对业务场景的理解，把部分核心产品通过“短视频”的方式做输出，从销售同事反馈看确实有效。主要规范了两类视频：
然后，我们发现代表腾讯产品官方形象的白皮书由于撰写粗糙客户阅读困难，与产品经理、销售专员一起就内容构成、视觉设计和品牌性做了“最佳实践”，实际推动了大量白皮书升级，使有效性和品质提升。也因此得到安全文档建设团队认可，投入到更多类型的文档优化工作中。
我们也积极参与到从“商机”到“交付”管理的效能优化系统建设中，在项目管理专家的指导下为销售专员和售后运维同事提供使用更顺手的管理平台。最后，我们必然也有在公有云控制台的“销售转化”上展开研究。
“体验不好”是去年经常被客户点名投诉的问题。每被提及，深知我们在 B 端设计资历尚浅，先送上膝盖再跟进原因。实话说，心里是有窃喜的，“体验”问题终于能得到关注。
通过工单分析、客户深访和销售专员转述，我们了解到，除确实存在的“引导不足”“流程不畅”等设计问题外，客户表达的也包含对“产品与竞品对比存在能力缺失”、“售后跟进问题处理不及时”、“定制化服务没做到位”、“业务场景化理解有偏差”等多方面问题。
原来 B 端企业客户（含购买决策者）理解的“体验”和 C 端使用者理解的“体验”完全不在一个层面。
客户反馈是获知产品整体评价的重要形式，“体验”问题涉及产品中多种角色工作范畴，单一角色优化输出难以改变整体产品评价。
我们开始在思考是否可以为每种角色找到评定“工作效果”的可测指标，即建立“全链路的度量体系”。
我们坚持“度量”不应该做为产品间“客户口碑”的考核，而是检验产品中各环节角色在单个产品的当前生命周期阶段中的职责完善度，以期改善各角色的服务效果（品质），提升客户满意，提高产品整体的品质。
我们学习了“ISO25010”、“ISO9126”，头部产商“UES”、“KEI”等，其他垂类“PLUSE”、“HEART”等 14 家企业组织的度量模型，结合腾讯安全现状，最终产出了四个方面的工作。
第一，结合之前对产品生态全链路的理解，找到环节中代表性角色，通过多次访谈，以环节角色意见为主，协助梳理出可评价的主观指标和客观指标。比如我们配合“售后服务”“文档建设”构建指标，也建立了“设计效果”评测指标，也尝试促成“产品能力”指标建设（之后，由战略部同事引导建成的“卓越产品”内生指标和外生指标更具科学性）。
第二，针对各类角色关注的有效指标，抽取可形成主观性评价的条目，丰富和完善设计原先在做的“产品满意度”系统，使满意度从对“设计”和“功能”的评价扩展到全链路，并且可以针对产品生命周期的不同，选择侧重需要关注的环节进行深度测试。
第三，安全线提出“卓越产品”目标后，在核心层领导的大力支持下，构建了满意度“双星”体系，以“宏观满意度”和“微观满意度”两个视角持续赋能产品优化建设，作为外生指标的重要结论性观测指标。“双星”相辅相成，既实现了短期数据变动可视，又实现了关键节点可深挖下钻发掘问题。
第四，客户评价属于置后行为，在产品发布之前，需要内部各环节做好质量评测。设计正在构建一套带有安全属性并符合影响满意度关键因素的自检系统，以期提升出品质量。
产品（狭义）不是设计的全部，连接产品和客户的服务纽带上存在无数的体验触点，设计者应从中立观望走向和解与学习。从“全链路视角”看，设计能输出的贡献远不止如此，任重而道远。
“市场研究”、“助力销售”和“度量体系”等工作始终是在主动探索着 B 端设计的边界，此类建设需要在良好信任的基础下，长期进行经营。
回归本职，即使大环境上有所限制，作为设计者也无需过于感伤，“戴着脚镣的舞者”同样有机会展现出色的舞姿。在如何做 B 端更好的体验设计上我们不断在尝试。
“可视化设计”在 B 端有巨大价值。
C 端转型 B 端的早期，曾有前辈敏锐洞察，B 端产品的数据复杂程度远高于 C 端，复杂产品比简单产品在信息的传递上要艰难得多，所以数据需要经过再加工，如果数据信息呈现出时间和空间的属性，那么 3D 可视化或许是不错的解法。
之后，我们利用 3D 技术承接到一些企业项目。一方面是以业务场景实例，学习数据可视化中各类信息图的使用规则；一方面也通过项目，努力去了解企业管理视角下对业务的关注核心。
这段探索时期对后续的 B 端设计起到了一定指引作用。
例如在 B 端安全产品（SOC 安全运营中心）控制台的设计中，我们策划了“态势感知”页面，把多源复杂日志数据做了流向归类，按照攻击链路阶段“配置、扫描、投递、植入”等步骤做了信息可视的推演。
在“AI 智能检测”的功能上，产品允许客户自定义规则和脚本，但书写脚本需要极高的专业能力和巨大的编程工作量，在参考了 Scratch 类积木化编程和 Unreal（虚幻）的图形化编程方式后，我们协助产品设计了简单有效的“可视”编辑方式。
让日常安全运维的数据和功能操作更直观，较好满足了工作人员的效率需求。我们也从决策者的视角出发，构建出符合其阅读习惯和关注重心的可视化大屏。
以更宏观的数据面来展现业务的安全现状，从“漏洞”、“告警”、“内外部攻击”等关键场景去剖析造成现状的因素，让决策者可以快速的掌控形势，制定未来安全的部署策略。
在“数据可视化”、“操作可视化”、“流程可视化”的研究过程中，我们仍处在非常稚嫩的阶段，去年参与了 ChinaVis 大会，接触到更多领域内专家学者的深度研究，十分欣喜，持续保持着探索和学习。
“可视化设计”是 B 端的特色，“用户多样性”也是一个显著的特征。
B 端产品，即使划分出了“使用者”和“决策者”也依然很难达成有效的设计，在我们从事的安全领域，“使用者”更是面目模糊。
当前问题，很大程度是出于对使用者这个定义的抽象化，即使是有丰富经验的 B 端产品经理和销售专员加盟，也由于宏观抽象了使用者后，把多类不同使用需求杂糅到了一起，变得难以精准分析哪些需求是真，哪些需求是伪。
针对不同使用者的使用场景下，需求可能都为真。
设计同样遇到这样的问题，对于使用者我们的理解更加遥远，难以带入同理心和认知体系，最终沦为需求的执行工具。
我们曾在一个产品的满意度里洞察到神奇的现象，设计做的越深入则客户满意度越低，暴露出的问题并非说明设计的无用，而很可能是设计方向出了问题。侧面可看出，定位功能时对于使用者的理解存在巨大偏差。
“客户精准画像”是我们在投入建设的重点工作。
举例，我们会发现某一个安全产品使用者可以分为“内容审核员”、“质检员”、“供应商管理员”，而另外一个安全产品则分为“IT 运维人员”、“安全技术员”、“安全专家”和“IT 管理者”。他们是各自平台的共同使用者，但在使用平台功能时存在不同的侧重。
最初他们都被归属在“使用者”这个标签之下，只认为是单一性质角色在不同场景下的需求切换。
设计来源于对生活的细致观察。我们需要从客户角度出发，梳理出功能和角色的对应，针对他们的知识程度、工作性质和使用心态等去设计深浅不一，复杂度各异的使用方式，而绝非为了体现产品的专业度一味去加深专业属性的呈现。
同一个产品，在不同客户环境下，由于使用者的属性差异（哪怕只有一个使用者，也会有明确的角色标签）提出的问题总是千奇百怪的，当我们逐步去解析使用者，沉淀出各类角色的共性和差异，明确各种功能服务的目的，才可能真正明白，我们到底在为什么人提供服务，应该提供什么程度的服务，实际的服务效果又是如何。
B 端产品的复杂性，让“引导体系”建设变得尤为重要。
通过画像研究，我们会发现多数产品使用者专业程度并非很高。面对一个不熟悉的复杂系统，当出现使用问题时只有两种处理路径：“自助”或“求助”。
B 端往往是付费产品，找“售后”提供人工服务是客户的习惯性选择，但随着平台化普及，公有云产品逐渐成为主流，大量使用者的涌入会使咨询服务的工作量激增。
那么，考虑到成本和效率，还是让客户尝试着自己能解决问题吧。在这个事情上，我们除了优化流程减少使用者学习成本，也制定了“引导体系”（最优秀的产品无需引导，在 B 端产品上我们仍需持续努力）。
首先，我们充分体验了国内外几家云服务先行者的产品，根据产品的生命周期推导出使用者在“引导体系”中的三个阶段，分别是“1 新手期”、“2 使用期”和“3 迭代期”。
① 新手期（解惑）
我们提供一种快速开通的引导能力，例如“新手任务”或“虚拟教学”，遵循开箱即用的逻辑，以最小代价协助使用者进入系统了解核心流程和核心能力。
② 使用期（辅助）
又再细分出三个子阶段“使用前”、“使用中”和“使用后”，“使用前”结合上文提及的“产品功能视频”等手段快速讲解复杂功能的使用方式；“使用中”则进一步在使用者进入编辑状态后适当牵引录入（部分安全产品需要同时在几个控制台联调），并做好各类异常录入提醒；“使用后”是提供一种更持久的可供查阅的方式，例如“知识文档库”、“在线客服系统（需要建设基础问题应答系统）”等更全面的帮助系统。
③ 迭代期（提醒）
是指“新功能上线”或“对旧有业务逻辑变更后产生了新操作牵引”等产品迭代行为的引导。
随后我们也发现，“引导体系”非常庞大，建设时间长久，对于新业务来说也不需要所有环节都马上具备。
所以，产品处于不同的生命周期，需要优先补齐的引导模块也就不尽相同，于是我们又针对产品生命周期和引导的模块做了关联研究。目前“引导体系”已有理论框架，落地效果仍需要伴随着业务的发展逐步验证，我们满怀期待并做好不断迭代的准备。
B 端设计还有一个痛点，亦是我们努力在寻找突破口的难点，是关于完整的“用户角色代入”。
上文提及的“精准画像”研究价值极高，了解使用者画像后可以更好的协助产品定位需求，推理功能和流程设计，但这仍是在一个“虚构拟真”的场景中。
C 端产品由于学习成本较低，且多为“日常生活”需求，设计者无需高昂的学习投入就可秒变使用者，所以设计可发挥的主动价值更大。B 端产品（如安全）需要的专业技术能力远高于设计者短期能达成的水平。
为了让设计者有可能完成完整的“用户角色代入”，需要精巧的设计测试环境和测试内容。
参考人类学领域的“田野调查”研究方法，结合产品正好发起的一次内部测试“试验田”，我们为一个重点产品的重点运维环节，设定了专项局部功能研究。一周的前置学习和规划，两周的“新人上岗”培训和真实运维工作，发现出非常多的产品问题。
“我们假定的功能流程原来真实使用者不是这样去用的”，“功能使用者向我们描述的需求原来是跳跃式的”，“原来我们应该在这些地方重点强化甚至为他构建一个独立的功能”......
真实运维人员的“勉强”使用让我们非常糟心，他们其实很不爽，但把难用熬成了理所当然，没人可以帮助到他们，只因为他们就只购买了这款产品。
“田野调查”的代价是巨大的，在“真实环境的营造”、“真实设计者变真实安全运维人员的学习成本”和“真实的长期投入运维工作”上。但“田野调查”的价值也是巨大的，获取的不再是多层转译的信息，让设计者能身临其境去审视设计的效果，懂得为之服务的使用者最真的感受。
只有真正懂得客户，深刻了解行业的设计者才能在 B 端领域产生不可或缺的价值，形成自身的技术壁垒。做可持续的“卓越产品”至少得能拿得出这个气魄吧。
未来，“精准画像”仍会是我们能最接近使用者的手段，伴随业务成长，保持与客户沟通，长期服务的设计者也必将更懂产品，也许技术的改进，构建“试验田”的代价也会降低，最终 B 端的设计者能像 C 端的设计一样产出更多的价值。
至此，设计创新才开始了萌芽。
写到最后，貌似关于效率型改进还未阐述，B 端设计团队在这点的思考上投入一定是最多的，改进分“设计效能优化”和“产品使用效能优化”。
“设计效能优化”行业内有不少文章给出了很好的建议，上文也略有提及；“产品使用效能优化”则需要根据业务类型细致来分析，就留待安全设计的同学们后续再发布思考了。
更低的成本和更高的标准化并没能拯救诺基亚。设计者应该去实现“用户”的梦想，从文化中获取火花灵感，从经验中梳理科学的解决方案。
本次撰文的目的是希望与 B 端设计者一同面对现实，从更宽的视野去探究 B 端设计的可能性，也探讨设计者职能的转化。文中积累皆来自设计团队多年的尝试（部分研究），感谢团队的辛苦付出，感谢 B 端设计同行的相互帮扶。
寒冬很冷，以卓越为目标踏实前行，为更好的产品和更好的自己努力思索吧。
参考：
欢迎关注作者微信公众号：「腾讯TSD」
本篇来源：优设网
原文地址：https://www.uisdc.com/design-function-thinking
广告
