业务 设计师 课程 金三银四招聘季悄悄开始了。虽然去年到今年经历了一波裁员潮，但是依然有一波在 C 端做UI和产品的同学，逆流而上跳槽到 B 端领域做设计和产品了。虽然他们各自的业务和行业差异极大，但是不知道你有没有发现，他们都有个共同点，那就是收入都还相当不错。的确，对于 UI/UX 设计师而言，回老家考公是一种上岸方式，而 C 端转战 B 端也是一种上岸的方式。只是，相比于更容易理解、更贴近普遍认知的 C 端设计，加入更多行业背景、业务需求和专业流程的 B 端有着更高的门槛。为此，我们专门准备了这套 B 端设计入门私房课，给正在筹备上岸的你：课程原价169元，限时新课价直减40元，仅需129元！移动端扫码学习，网页端右戳学习 https://wei.xet.tech/s/2pMvzq入坑B端设计的绝佳时机！也许很多同学几年前就听说过「用友」和「金蝶」这些针对企业的商用软件开发企业，但是随着如今各行各业信息化建设，不止是传统的金融、仓储、物流等领域需要更加深入定制化的设计，而且教育、地产、医疗、销售乃至其他更加细分的行业，大都需要有自己的信息化管理系统。大概是在 8 年前，为了区别于针对个人用户（Customer）的 UI/UX 设计，有人提出了 B 端设计，也就是针对企业和商用（Business）的系统化 UI/UX 设计，彼时 B 端设计开始被提出，8年时间蔓延至今已呈大势之象。如今大量的企业有着自己独特的渠道、和同行截然不同的流程，在管理模式上也大相径庭 ，这也使得很多企业迫切需要贴合自身业务特征的定制化的 B 端设计。即便针对自身体系定制一套数字化系统成本高昂，但是效率提升后带来的利润增长更为可观，这使得 B 端设计成为了设计领域新的增长点，「钱」景无限！但是相应的，B 端设计所牵涉的「业务属性」，也对设计师提出了新的要求。设计师天然就是内容和信息的消费者，从事 C 端设计时，可以相对容易地代入身份，针对性地进行设计，而 B 端设计所涉及的行业不同，所牵涉到的专业性的用户身份也千差万别，业务流程可能完全找不到合适的参考，这一方面要求设计师需要通过专业的手段和方法来调研和梳理，摸清业务，另一方面也需要设计师有更加系统化的思维和方法，来为整个业务创建流程，搭建平台，统筹管理，而这也是 B 端设计不同于 C 端的重难点。这个时候，你就需要针对性地系统化学习了。事半功倍的学习路径很有必要！如果你是设计小白或者已经是 C 端的 UI/UX 设计师，那么这套课程可以带你以正确的姿势开始学习 B 端设计，如同你刚刚转到 B 端设计，这套课程同样可以带你重新收束 B 端设计的思维和知识点。课程会分为 3 个阶段：第一阶段带你着重了解 B 端设计的特征，概念和流程，明确方向第二阶段教你 B 端设计前期分析的方法和要点，深入业务第三阶段结合实际案例，循序渐进地教授 B 端设计执行的技巧下面是详细的大纲：课程原价169元，限时新课价直减40元，仅需129元！移动端扫码学习，网页端右戳学习 https://wei.xet.tech/s/2pMvzq用项目喂出来的课程讲师小煜老师是实实在在在大厂里，用一个个大型 B 端项目喂出来的资深设计师，从电商到金融，从 IM 到直播，踩过不同行业的坑，处理过多种截然不同的业态，面对千差万别的用户需求，在B端行业差异里逐步摸索出成系统的设计策略，又在共通的方法中，总结出应对不同需求的独特技巧，这套录播课程，就是她过往 B 端项目的总结。10 年前 C 端的 UI 设计当初是机会无限的蓝海，如今的人满为患，内卷严重。但是业务形态千差万别的 B 端需求旺盛，行业垂直且细分，需要懂得用户体验、具备系统思维、敢于探索需求、能够梳理业务的 B 端设计师，而任何一个细分行业的发展，起码都是按照十年来进行计算的。下一个十年，你可以从 B 端开始。课程原价169元，限时新课价直减40元，仅需129元！移动端扫码学习，网页端右戳学习 https://wei.xet.tech/s/2pMvzq本篇来源：优设网原文地址：https://www.uisdc.com/business-design-course
目标 业务 产品 很多同学问过我关于业务目标、 产品目标和设计目标相关的问题，比如：业务目标和产品目标有什么区别？产品目标与设计目标的关系是什么？设计目标时根据什么制定出来的？今天我们就来聊聊这三个目标之间的区别和联系。更多作者干货：设计师与 ChatGPT 如何共处？我总结了3个角度！最近挺多同学问过我关于 AI 的看法：ChatGPT 以及很多 AI 生成插画和图片的工具和软件，不仅为我们带来了惊喜，也让我们感受到了不少担忧。阅读文章 > 通常情况下，业务方、产品方和设计方是分开的三组人。一些追求敏捷发展的中、小公司可能不会区分得太清楚。不过这并不影响我们在工作时将业务目标和产品目标进行拆分管理，以保证目标更加清晰、更易落实。一、业务目标业务目标是业务人员针对业务领域或产品方向提出来的。业务方的立场是：卖出产品为公司赚钱，因而会兼顾售前、售后获得的用户反馈、公司的发展战略等方面来制定规划和目标。业务目标通常是公开透明的，它是整个业务产研大团队的共同目标，也是产品目标和设计目标的来源依据。业务目标的写法通常是：“XX 业务 / 产品今年将以 XX 为重点方向，预计将用户活跃度从去年的 20% 提升至 50%。”二、产品目标产品目标是由产品方根据业务目标、产品功能和用户需求制定出来的，产品方的立场是：将产品做得更好从而实现业务目标。产品会根据业务目标来为产品功能做规划，也即将业务目标转换成具体的功能模块建设需求。因此产品目标也会显得更加接地气和务实一些，它的写法可以是：“重点建设全新的 A 功能，做到人无我有；优化 B 功能的 XX 环节，增加 XX 服务，做到人有我优，将用户对 B 功能的好评率提升 20%。”三、设计目标设计目标是设计师结合业务、产品、用户等多方需求制定的设计工作方向。设计师的立场是：在保证用户体验的基础上完成产品功能设计，实现产品目标和业务目标。设计目标的制定来自于对业务目标和产品目标的拆解和落实，同时也要兼顾用户体验，平衡多方需要后找到最优解。 设计目标会指引你完成设计实操工作。它的写法通常是：“优化 B 功能的 XX 体验，在保证产品可用性的同时，提升用户在使用产品时的安全感，增强产品与用户的共情心智，提升 20% 好评率。”四、三者之间的关系业务目标是产品目标的依据，会被产品方转换成具体的功能建设规划。产品方会在建设产品功能的过程中实现业务目标。业务目标和产品目标都是设计目标的依据，业务目标会被设计师转换成整体的设计优化规划；产品目标会被设计师拆解成具体的设计执行方向。设计师会在保证用户体验的基础上，实现产品目标和业务目标。可以看到，越是处于合作的下游，需要考虑的范畴和责任就多。业务目标是相对纯粹的，它来源于公司战略和用户关系；产品目标是相对务实的，它来源于业务需要和用户需求；而设计目标则是相对复杂的，需要设计师站在业务视角、产品视角和用户视角来做全局看待，时刻思考如何取舍和融合，找到平衡点。在实际的工作过程中，业务目标、产品目标和设计目标三者互相成就，紧密咬合，不可分割。这也要求我们作为设计师在做设计目标和整体工作规划的过程中，应该从业务和产品的本质需求入手；在从视觉表现、交互体验、操作流程等方面来做设计执行时，不应是以“突出设计工作和设计方法”为出发点，也不应是以“为了增加某个好看的效果”为最终目的，而是“为了赋能产品/业务”，实现产品和业务的目标。在商业设计中，设计之所以有“价值”，也正是因为它能为业务创造价值。欢迎关注作者微信公众号：「长弓小子」本篇来源：优设网原文地址：https://www.uisdc.com/business-product-design-2
业务 产品 行业 年后有不少小伙伴们要开始找工作了，都会面临相同的问题：换一家公司，如何快速了解业务并展开工作？其实除了换工作之外，类似的场景还有：公司业务孵化出新产品被临时调配，或转岗遇到不熟悉的业务...作为职场人，公司招人的目的是来救火的，没有太多时间和精力来培养员工。面对新的环境能不能快速融入业务状态，也是对设计师能力的考验。那么当面对新业务时，应该如何快速接入呢？我将结合自身经历跟大家分享一些心得体会。更多方法：如何熟悉新业务？6个业务分析模型与方法送给你！作为互联网设计师，面对不断变化的业务内容和场景，不仅需要掌握基本的专业设计方法，同时也要求熟悉业务，在深入分析业务痛点的基础上，洞察设计创新机会点，助力业务发展。阅读文章 > 一、多渠道快速了解行业当投入新的领域工作时，在不了解业务的情况下，仓促投入工作中套用之前的经验在新业务上，往往无法提供满足需求的解决方案。原有业务中的用户、商业逻辑在其他领域可能很难适用。所以我们需要在有限的时间里，快速了解业务概貌，也为后面工作的开展做好铺垫。1. 查阅行业报告首先从宏观上了解整个行业的现状。我们可以通过研读行业报告，建立起对这个行业的基本认识。因为在行业报告中会提到相关行业的发展状态，政策导向以及未来的发展趋势。分析行业中包含了哪些垂直赛道、每个赛道都有哪些相关企业，目标公司的规模、融资情况和业务进展等。这里推荐通过以下两个网站查询：IT 桔子：关注 IT 互联网行业结构化的公司数据库和商业信息服务提供商。艾瑞咨询：可以免费阅读包括新零售研究、大数据研究、企业咨询、投资研究等方向的高质量行业分析报告。2. 关注行业资讯其次从中观上通过阅读行业资讯，提升业务思维能力。充分利用网络资源，阅读有关行业或公司业务的最新行业报道和评论，了解业务发展战略和面临的难题等，也可以看一些行业老板们的公开讲话，也会谈到公司及整个行业的未来走势。资讯的获取渠道有很多，包括各大门户网站、公众号、博客论坛等。这里推荐几个常用的专业网站查询：36 氪：信息更新快，时效性高。以全面、独家的视角为用户深度剖析最前沿的资讯。内容涵盖快讯、科技、金融、投资、互联网等。虎嗅：专注于有深度、犀利的优质商业资讯，围绕创新创业的观点剖析与交流。创业邦：更专业、更有深度。为创业者提供高价值的资讯和服务。3. 体验行业竞品然后再从微观上了解同类竞品，不仅看产品本身，还要比较行业地位，了解在目前的背景下，我们的产品是处于行业领先还是向竞品追赶的地位。它山之石，可以攻玉。通过关注竞品的差异，分析背后的原因，取其精华，为后期产品的迭代提供方向。二、深入业务提升产品思维设计师对业务不够理解，往往跟产品对接时只能进行“信息不对等”沟通，只有真正理解业务才能发挥更大的设计价值，挖掘更多的设计机会点，站在更好的视角为产品服务和决策，帮助到达更高的业务目标。1. 了解产品历史产品经理与用户走得更近，了解业务并分析竞品，他们对于这些领域有深刻的了解。多于他们交谈，或者从他们这里拿到之前相关的产品文档、会议记录等资料，可以帮助我们了解产品创建的契机、愿景、历经的过程等信息。另外查看 Sketch 等设计源文件更能直观了解设计的历史版本、试错过程和优化方案，帮助了解更多产品及视觉设计的信息。2. 了解目标用户不同的产品服务的目标用户也各不相同。用户的性别、年龄段、职业、喜好、习惯、消费水平等特征的差异决定了产品的方向。我们需要明确产品的用户群及对应的用户特征。当你了解目标客户现在如何解决他们的问题后，你可以更好地了解潜在客户现有的动机、行为和期望，以预测他们将如何对待一个新的解决方案。用户的使用场景也是设计中需要考虑的重要因素。举个例子，在房产经纪人使用的直销后台系统中，考虑到经纪人常用的电脑分辨率和工作场景，合理的字号设置和首屏利用率对于经纪人阅读和操作效率尤为重要。3. 体验并感受产品体验产品流程是一种快速熟悉产品很好的方式。很多产品的用户系统是包含多种身份角色的。我们在使用产品时要带着角色身份，有目的性地操作，避免陷入到设计师的视角陷阱，把产品体验变成了线上走查。举个例子客户管理系统中一般包含销售员、销售主管、大区经理、管理员等身份，不同身份对应不同的权限和使用功能。在使用的过程中，对功能流程中存在问题的页面及时截图，并记录下自己的感受和思考点，方便到后期项目迭代中有涉及这些点的时候，可以去进一步优化。4. 梳理业务流程业务流程往往是一件复杂的事情，特别是 B 端类产品，对于加深业务理解是非常重要的，因为这样能够最快了解整个产品的流转方式。在梳理的过程中，我们可以从专业词汇、角色、工作流等维度进行分析。① 专业词汇很多产品是服务于垂直的领域，所以不免涉及到专业领域的一些词汇来进行准确描述。比如在直销系统中，我们必须了解：公客池、营销客、线索、跟进等基本词汇，这些词汇的背后一般是比较庞大的功能或产品中的深层逻辑。公客池：按区域或某种特征组合在一起的客户分组，对全部经纪人可见并联系；私客：经纪人单独管理和维护的客户群，其他人不可见；线索：可从推广活动、广告、购买等各种渠道获得的客户简单信息，通过管理和跟进转化为客户。② 工作流对于复杂业务，产品流程中会牵涉多个角色，我们需要关注有哪些角色、角色之间的协同关系、工作场景、操作路径等。例如房产经纪人使用的直销系统，核心本质是一个客户管理的销售工具，我们首先对经纪人的日常工作流程进行梳理。为了帮助经纪人提升转化率也就是房客资源利用率，从购房分析、提供具体的购房方案、房源筛选匹配、到房屋营销建议、再到销售跟进、风险管控等整个流程，帮助经纪人优化应答时间、标准话术、沟通技巧、追踪频次、服务动作，并根据不同需求客户给出效率最优的接待服务方案，从而提升经纪人的作业效率与客户转化率，进而实现业绩增长。总结把握好换到新业务前两周的业务熟悉阶段，我们按照先整体再局部从大到小的思路，从行业入手了解行业竞品，产品是怎样的商业运转模式，再通过价值主张，了解产品各个功能模块的价值。充分利用好团队资源，包括产品、测试同学等，他们更了解业务以及产品的组织架构，知道产品的核心模块是哪些，清楚不同角色的之间的流转关系是怎样的。最后通过以上步骤，基本能够对一个新的业务有了基本的认知，希望本文能够对你有所帮助。如果你有更好的方法欢迎留言讨论，一起进步~欢迎关注「58UXD」的微信公众号：本篇来源：优设网原文地址：https://www.uisdc.com/learn-new-projects
产品 用户 业务 俞军老师曾说：“用户是需求的集合。”需求的诱导因素是复杂的，需求的表达形式也是各异的。B 端产品与 C 端产品显然面向不同的人群，满足于不同的需求，简单来说，B 端产品多从角色视角出发考虑需求，服务于企业或组织，偏向于满足降本提效与资源整合的诉求，而 C 端产品多从用户视角出发考虑需求，服务于个人或消费者，偏向于满足市场发展与体验升级的诉求。本篇文章希望能够帮助大家更形象地理解 B 端与 C 端的区别以及如何上手 B 端调研。一、B 端与 C 端的区别在了解差异前，首先要明确 B 端与 C 端的定义：B 全称是 Business，即商业，多指企业用户，使用的是具有业务管理思想的数字化工具，常见的 B 端产品有 ERP、OA、CRM、Slack、Notion 等。C 全称是 Customer，即消费者，多指个人用户，使用的是能够满足某一群体需求的客户端，常见的 C 端产品有例如京东、微信、抖音、微博等。在日常工作与生活中，我们都离不开使用 B 端与 C 端的产品。洗漱时，我们打开“网易云”听最近喜欢的音乐；出门时，我们打开“百度地图”查看路况并叫车；工作时，我们登录 Outlook、京 me、JoySpace 与营销中心等办公工具，进行邮件查收、业务沟通、会议记录与活动发布；下班后，我们在“美团外卖”挑选晚餐并下单，B 端与 C 端的产品就这样穿插在我们的生活与成长里，那它们在产品定位上到底有什么差异呢？目标用户的不同C 端面向个人用户，服务于在不同生活场景下的每一个人。C 端产品拥有更宽泛的受众群体，每一个核心功能都在解决大多数人的诉求，这也意味着，它需要更细致的用户画像，比如年龄、地域、收入、文化、职业、喜好等等。B 端则面向企业用户，服务于在不同经营场景下的每一个“企业”，企业可以是商家，可以是团队，可以是组织。B 端产品拥有更垂直但复杂的受众群体，它不需要收集这类人在性别、年龄与地区等维度的差异，转而关注这类人所属角色之间的差异。“营销中心”是京东内各业务方开展京东营销活动时的中心化工作平台，一个典型的 B 端产品。我们在调研过程中会通过岗位/负责品类/工作年限明确用户所属的群体角色，比如是运营还是营销，负责的品类是图书还是汽车，至于用户年龄多大、哪里出生与性格怎样并不会影响对产品需求的判断。使用场景的不同C 端产品的使用场景具有极高的自由度，它会出现在各式各样的状态下，甚至在同一时间里或一个任务下可以使用多个产品，比如在在外出旅游的晚上，打开“腾讯视频”追着最近爆火的综艺，打开“轻颜相机”美化下白天拍摄的相片，再去到“微信”发一条旅游主题的朋友圈。使用场景的碎片化与任务的随机性，使得 C 端产品需要始终注重体验的提升。B 端产品的使用场景则不同，用户是为了工作，工作包含特定的任务，任务具有明确的动线，因此用户需要长时间与沉浸式的使用，使得 B 端产品需要具备严谨高效的操作流程与简单清晰的页面设计，为了更准、更快、更好地解决问题。核心诉求的不同C 端产品对于开发者而言，核心诉求是拉新、留存、转化，通过对用户需求的挖掘，迭代优化出有价值的产品，大多 C 端产品最终目的为了盈利；但对于用户而言，核心诉求是满足自我情绪，通过“微信”与父母视频，满足思念的情绪，春节期间在“京东”购买新衣，满足能在春节收到货的期待。B 端产品的核心诉求是基于业务规范，让业务流转效率更高，员工学习成本更低。相比于 C 端对用户体验的极致化追求，B 端产品的需求更易受到业务形态或是企业战略的影响。更多B端和C端的差异对比：如何区别B端与C端的产品设计差异？我总结了26条对比！随着企业数字化转型，B 端产品越来越受到人们的重视，B 端产品也越来越丰富，越来越多的 C 端设计师转行到 B 端产品的设计上来。阅读文章 > 固然 B 端与 C 端存在各种维度的差异，看似 C 端产品对用户体验更为重视，但无论是 B 端还是 C 端，实际的使用者都“人”，C 端产品需要考虑商业价值与用户体验的平衡，B 端产品亦是，精准地洞察用户的需求，对企业效率的提升也大有裨益，但新人小白如何快速上手 B 端调研呢？二、B 端调研的小经验入职京东的第一个完整的项目是《通天塔用户体验研究》，通天塔是京东旗下一个快速搭建活动页面的平台，我们在京东看到的活动落地页大多是依赖于通天塔的能力。在调研过程中，作为新人的我，踩了很多的“坑”，也总结出些许经验，希望与大家分享，欢迎大家的批评指正。全面理解业务C 端产品是个体导向的，个体的偏好不影响他人的偏好，个体的痛点也未必是他人的痛点。但 B 端产品中的各方是广泛关联的，所以个体的偏好与痛点并不是随机的，也不是完全独立自主决定的，而是受到整个业务场景的影响。因此，在思考 B 端产品体验的时候，不应该仅仅思考其中某个个体的体验，还应思考他所处的业务场景。“模板组件不丰富”是关于通天塔的一个最高频反馈，也是产品侧希望优化的重点方向。作为新手研究员的我们应该避免在访谈时问出“您需要什么样子的模板？”，并草率地给出“进一步丰富模板组件”的建议，而是需要把侧重点放到对业务场景的分析以及业务需求的梳理上。比如，“您的岗位职责是什么？”、“在页面搭建过程中主要负责的任务有哪些？”、“参与搭建的页面展示在前端的哪些位置？”、“希望通过活动页面达到什么业务效果？”、“重点关注哪些维度的效果数据？”、“负责的是什么品类？”、“这个品类有什么特性？”、“品类特性期望在页面中以什么形式展示？”等等，以此，我们会更清楚当前用户的业务范围以及这类角色的业务诉求，更好地站在业务的视角出发提出更有针对性的优化建议，找到真正被需要的“丰富性模板”。总之，调研过程中需时刻牢记业务目标，最大限度地为企业赋能，避免在细节中“钻牛角尖”。深度熟悉产品在入职京东前，我在京东购买过各类商品，参与过各类活动，在没有系统性的学习下，我也可以熟练使用各项基础功能。但在第一次接触“通天塔”时，我遇到了许多问题，比如“我不知道素材组是什么以及如何绑定”，“在没有素材组 ID 可用于测试时，也不知道如何去其他系统里创建素材组”，我意识到 B 端产品远比 C 端产品难上手。在对产品不熟练时，直接去邀约用户执行访谈显然是低效的，因为“你对用户的调研”会变成“用户对你的授课”。所以在调研执行前，能够熟练使用 B 端产品是必要的，特别是用户日常高频使用的功能，减少调研时的“讨教”与因功能盲点造成的理解偏差。此外，即使研究员已经可以熟练使用产品，在执行过程中，用户的“实操”仍比“口述”更有效，引导用户直观地展示操作动线，会更容易地挖掘卡点与痛点，也能减少研究员在操作任务上的理解成本。拓宽竞品分析的边界竞品，可以理解为一个参照物，观对手，明优劣。C 端的竞品是清晰好找的，比如京东的竞品有淘宝与拼多多等，抖音的竞品有快手等，爱奇艺的竞品有腾讯视频与优酷视频等，但通天塔的竞品是什么？大家会说自然是各大友商旗下搭建页面的工具，但这类产品往往是企业自行开发，供于内部员工与商家使用，作为一名个人用户，是难以获得权限进行走查的。此外，B 端产品往往是服务于特定企业，具有个性化需求，难以从市场中获取相关信息。所以应该如何进行竞品分析呢？首先要敢于申请账号，想要全方位走查 B 端产品定需要足够的权限，但不能因此就放弃尝试。从申请一个账号开始，会发现部分 B 端产品并没有非常严格的使用界限。我在调研过程中，百度搜索了许多竞品，部分页面搭建的产品其实是同时面向 C 端与 B 端的，初次注册的个人账号虽缺少对一些高级功能的使用权限，但也足以给到一些启迪。其次，受访者的信息是重要的。在执行访谈的过程中，不要忽略询问受访者对竞品的态度，因为有些受访者有使用过相关竞品的经验或目前仍在多个渠道中负责搭建页面，他们对竞品能力的熟悉度与可提供信息的价值性要远大于个人走查所能带来的。以上就是个人对 B 端的理解以及在 B 端调研时沉淀的小经验，作为新手研究员，仍有许多不足之处，欢迎大家批评指正。欢迎关注「JellyDesign」的小程序：本篇来源：优设网原文地址：https://www.uisdc.com/business-investigate
指标 业务 机制 秉承 58 同城“用户第一”的核心价值观，设计团队建立以基础体验指标为评估标准、发掘体验问题的评估机制，并借助内外部业务专家视角，对 58 同城各产品的重点场景进行评估，优化业务场景，从而提升各业务线的体验，而这一套评测机制就是 QMD。QMD 始于 2020 年第三季度，历时 4 个季度，支持了 10+业务线的体验优化。但随着业务的高速发展，原有机制已经无法满足业务现阶段发展的要求。为了更好地支持业务的变化，在 2022 年上半年，58UXD 体验管理 QMD 项目组发起了体验评估机制的迭代与实践。我们将通过干货满满的三篇连载文章，分别从「指标模型」「评估机制」「组织实践」来全方位的分享体验评估机制的升级经验，欢迎大家的持续关注和探讨。本篇为大家介绍：我们如何为不同业务设计贴合业务目标的、灵活易落地的体验评估的指标。其他量化模型：如何清晰量化设计价值？试试这个超实用的GSSM模型！编者按：本文通过实战案例，帮你掌握一个能量化设计价值的GSSM模型。阅读文章 > 一、QMD 是什么作为产品的业务方、设计师时常会陷入体验量化的困境：“不清楚产品在行业内的体验水平”、“无法量化设计师贡献的价值”。于是，团队在 2 年前首次推出了 QMD1.0 体验评估机制。一方面能帮助团队从全局的视角去观察用户和洞察业务，让产品持续地提升体验，另一方面在组织内部带来了提升设计品质的驱动机制和文化。QMD 的全称为：Quality Measure Driven。从其命名可以看出，这套机制分为三大部分：质量目标（Quality）：是让设计师从体验设计的品质目标入手，将本品、竞品作为评估对象，这样以来能够定位本品、竞品之间的「差异」；度量指标（Measure）：以基础体验指标为评估标准的度量体验，并借助内外部业务专家、设计专家的视角，对 58 同城各产品的重点场景进行评估设计的「品质」；驱动机制（Driven）：通过驱动机制，解决自身问题，驱动追齐竞品，帮助设计师了解如何「提升」评估结果。自 QMD 推出以来，帮助各个业务线提升体验水平、赶超竞品，持续为核心业务线带来体验价值。二、评估机制的问题为了更好地赋能业务，我们定期对业务方、设计师等不同角色的进行深度的访谈，得到了大量的反馈：产品会不重视输出的问题、体验问题优先级低、遇到分数的波动难解释、评估专家个体存在差异、结论的责任边界模糊...等等一系列问题。为此，我们发起了 QMD3.0 迭代项目。通过对收集的问题进行归类，我们可以概括为两类：问题难推动落地、评估结论信服度低。于是先试着从现有的测评体系查找分析“难落地”原因，而“信服度低”将通过第二篇文章详细阐述。旧版 QMD 为我们从“界面”“操作”“一致性”三个维度带来了 10 个评估指标，但其制定的核心依据是“体验设计”。回顾旧版 QMD 所推动的内容，其出发点还是以“用户体验”为中心。基于这个出发点，收集了大量的用户体验类的问题，然而缺乏对业务价值的考量，这些问题找不到带给业务的价值。另外在评估方式上我们选择采用设计专家的启发式评估，让专家代入用户真实使用体验，在测评范畴上也未对业务价值的高低进行筛选。这就不难看出，我们之前难落地的根本原因：现有指标体系不契合业务价值。所以，对于新版评估体系的指标的预期，首当其冲地要将「业务价值」纳入进来，以「用户体验」和「业务价值」交叉重合的部分作为评估的出发点。与之对应的，我们评估的范围，也需要调整为仅测量 “高价值”部分，这样以来，指标覆盖的范畴就能实现从“大而全”到“精细化”的转变。至此，我们也确定了评估指标的设计方向——高度契合业务的价值。三、指标模型的迭代要想设计契合业务价值的指标体系，第一步是找到现有指标模型和业务价值的偏差在哪里？我们通过对业务价值的拆解分析得到三大偏差点。针对偏差点逐一提出指标升级的方向：契合业务目标、契合体验诉求、契合优先级 。1. 契合业务目标体验评估指标的制定，行之有效的方法就是利用 GSM 模型，通过对业务目标的拆解，来推导出能解释目标的关键指标。回到设计师日常的设计思路，其实就是从业务的核心目标出发拆解，得到各个场景要达成什么样的设计目标，再拆分用户体验层面的目标有哪些。新版 QMD 也是如此，通过对核心业务目标拆解，各个场景的用户体验设计目标就是评估指标，换句话说：平时我们怎么设计的，QMD 就怎么去拆解评估。2. 评估指标契合另一方面，随着业务的不断发展，58 同城覆盖的业务类型也千差万别：创新型、平台型、业务型等多种业务方向类型。而不同业务又处于引入期、发展期、成熟期、衰退期等不同的产品生命周期。为了得到灵活、能够契合不同业务的指标体系，我们针对指标构成和指标描述也做了调整。首先是指标构成，以往 QMD 针对所有的业务采用固定的指标构成。可想而之，很难满足各类业务差异化诉求。而新版的指标构成在原固定指标的基础上，以自选基础指标和自定义指标的组合方式，更加灵活地适配不同的业务。如图，58 同城某高速发展中的业务，其对于体验的诉求存在差异，剔除了“美观度”“品牌”“共鸣”等指标，但是结合产品特性，增加了“真实性”（即，能感知平台所提供的职位信息及内容真实·可信·有保障）的自定义指标。其次是指标描述，同一基础指标，我们也会和业务设计师、产品经理，共同定义指标的描述。不同业务在可控的范围内可以进行不同的描述调整。如图，同样的“共鸣”指标，在 A 业务增加了：价值感相关的个性化描述，在 B 业务增加了：保障感、时效感相关的个性化描述。使指标释义贴近我们业务的具体情况。3. 评估优先级契合第三，为了满足业务不同场景的重要程度，我们为这套模型引入了指标权重的概念。首先根据对业务总指标的影响大小给业务场景赋予权重，然后再通过场景中各指标的重要程度来赋予权重，通过调整场景&指标的权重，就能得到适配各类型业务的灵活指标。4. 验证指标设计合理性反思过去的评估机制，通过「制定指标-实施评估-输出结论」，虽然也能够对产品进行评估，但是缺少了对于指标设计合理性的关注。为此在指标模型的设计中，我们也增加了防错的机制，通过观测优化效果，形成「确定指标-实施评估-观测效果-验证指标」的完整闭环，在实践的过程中反复调整，确保了指标设计的合理性。小结最后总结一下指标的设计过程：首先发现&分析问题，找到“难推动落地”的根本原因——指标设计不契合业务诉求。针对核心根本问题。我们从“评估目标”、“评估指标”、“指标优先级”三大方面入手，设计出契合业务目标的指标体系。最后还增加了指标设计的验证机制，来确保指标模型的合理性。至此，QMD3.0，关于指标模型的升级就告一段落。我们发现在构建指标模型的过程中，“没有最好，只有最适合”，所以一切的出发点就是以契合业务目标的前提下，找到最适合业务的指标，以持续稳定地评估产品体验，进而帮助业务的落地问题。而体验评估机制不仅是切实帮助业务提升体验的工具，更是我们设计团队立足体验管理的重要构成。未来我们也将继续秉承“用户第一”的价值观，持续为用户带来更好的产品使用体验。预告一下如果说建立科学、易落地的指标模型是 QMD 评估机制的根本，那么可靠、高效的评估机制则是推动 QMD 落地实践的重要前提。接下来王楠将带来《设计师必备体验评估设计指南（机制篇）》，为大家深度讲解如何建立人人可信赖的评估机制。欢迎关注「58UXD」的微信公众号：本篇来源：优设网原文地址：https://www.uisdc.com/qmd
业务 指标 机制 本篇将介绍如何有序组织体验评估，并将详细讲解本次 QMD 升级的要点、难点是如何落地执行的。上期回顾：设计师如何做好体验量化？收下大厂的QMD评测机制（机制篇)秉承 58 同城“用户第一”的核心价值观，设计团队建立以基础体验指标为评估标准、发掘体验问题的评估机制，并借助内外部业务专家视角，对 58 同城各产品的重点场景进行评估，优化业务场景，从而提升各业务线的体验，而这一套评测机制就是 QMD。阅读文章 > 我们选用质量管理工具 PDCA 来组织体验评估，做体验管理。以季度为评估周期，一个季度完成一次 PDCA 循环后，我们持续迭代评估体系，从而更好的完成下一个周期的体验评估。一、策划策划的主要内容就是大家很熟悉的 5W1H 了。1. 评估目标-Why如第一篇文章所述，新的体验评估机制，评估目标从单一的提升体验质量，调整成契合业务目标的体验质量。参与体验评估，业务设计师的预期有：提升产品使用体验；提升业务核心指标。QMD 项目组需要兼顾参与评估业务的预期，目标有：采用可靠的评估机制，度量契合业务目标的体验，发掘影响业务目标的体验问题，确保评估结果可信、可靠并易感知；确保按照规划周期性做体验评估、同步结论、跟进优化；验证各个参评业务的评估指标、评估机制的可靠性。2. 相关人员-Who想要按照以上预期高质量的完成体验评估，离不开组织架构的支持。58UXD 设立了由交互设计师和用研工程师组成的体验管理组。由体验管理组来组织全部业务的体验考核、体验评估、体验展示、体验跟进等一系列横向体验管理项目。QMD 作为体验管理的重要工具，由体验管理组中的 QMD 项目组来牵头策划完成。有同学对 58UXD 其他体验管理工具感兴趣的话，可以在评论区留言。明确了组织方及其职责，根据新的评估机制，还需要每个业务 6 名评估专家（2 名产品、2 名交互、2 名视觉）。QMD 项目组采取了参评业务产品、交互、视觉交叉互评的方式，由第二篇文章介绍的评分者信度保障结果的可靠性。在新的体验评估机制下，有很多 QMD 项目组和业务设计师需要沟通协作的节点。为了高效运行评估机制，QMD 项目组在各个参评业务都明确了一位 QMD 对接人。各个角色的职责明确如下：3. 评估业务-What新的体验评估机制对参评业务也有了新的要求。出于可行性和投入产出比的考虑，我们根据以下 4 点，深入了解各个业务的情况，做出研判，最终确定了参评业务。当前阶段业务对于体验的重视程度如何；业务是否有明确的、可持续监控的目标；业务迭代的频率如何；业务是否已达到一定用户规模。4. 时间规划-When如前所述，新的体验评估机制关键节点多，时间跨度长，需要周密的规划和严谨的时间管理。QMD 项目组是以季度为单位做周期性体验评估的，所以在季度初就会做好整个季度的规划，并严格执行。同时采用周报制来及时处理意外事件，保障项目准时完成。另外值得提一下评估场次时间的确定，除了视评估专家的时间安排外，也需要考虑线上测评的版本是否符合业务预期，晚几天可能就到了发版时间，是否需要评估最新版，需要综合情况和业务协商。同时也要求 QMD 项目组在规划之初，就要留好类似这种情况的 buffer。5. 评估地点-Where确定好评估时间，就可以提前约会议室了。然而我们在 2022 年的 Q2 和 Q4，遇到了两次因疫情大量同事远程办公的情况。如此我们需要保证线上评估或者部分同学线上评估的结果可靠性。原理如第二篇文章所述，需要保障人员可靠性、认知一致性，标准化实施方案。6. 怎么评估-How给到专家评估，我们需要至少准备评分工具和主观问题反馈工具。这些都需要以评估指标为基础，我们从第一篇文章了解到指标的制定原理后，各个业务的评估指标具体怎么确定呢？首先，调整基础指标：我们知道业务的评估指标由基础指标和自定义指标构成的，我们在制定指标前需要根据新的指标体系需要，重新审视原有的基础指标。我们认为一个良好的基础指标，应该是清晰、准确、普适、易懂的；我们邀请专家对这样的指标进行评估，应该是对体验设计有指导意义的。所以对基础指标做了如下调整：评估指标由原来的一级指标改为二级指标，颗粒度更细，聚焦到具体问题；相似指标合并，二级指标由 15 个合并成 10 个；增加动效、语义等方面的评估；评估指引描述方式更直白、易理解；等等。我们把基础指标给到业务，由业务设计师参考以下几个原则制定个性化指标体系。GSM 模型（Goal- Signal- Metric）：方法在第一篇文章中；反向思考：场景拆解到什么程度，可以结合业务的实际需要，由希望监控的颗粒度有迹可循：场景的设计目标，需要是可量化、可监控的，一方面可以追踪优化效果，另一方面可以反向验证指标制定的合理性；因地制宜：评估指标需要足够细化、贴合业务场景。比如基础指标中的“品牌”指标，在基础指标中的描述是“”，是考虑普适性的描述方式。而其在不同业务中的具体元素、形式、原则等体验要素都差别较大，所以需要额外说明当前业务的“品牌”具体需要达到什么体验要求。有些业务会额外提供一份品牌手册，供专家评估参考；稳定性：指标体系内的元素需要在一定时间范围内保持稳定，尽量不因业务的调整而频繁变化。有了细化的评估指标制定指引，我们向参评业务做了详尽的讲解，并充分探讨其在各个业务的可行性。业务设计师按照要求，结合实际情况，制定了由总目标、影响总目标的场景、场景的评估指标、评估指标的详细说明四个部分构成的指标体系。而后交由 QMD 项目组审核，确定无误后，由业务设计师根据模版，自行制定体验评估要用到的评分工具和主观问题反馈工具，这里我们用的分别是 58 问卷和在线协作表格。二、评估1. 体验评估一切准备就绪后，就可以邀请专家来评估了。就像第二篇文章介绍的那样，为了保障评估结果的可靠性，我们对评估工具、专家、环境等都制定了标准化方案。下图是 QMD 项目组在专家评估前宣讲的评估目标、机制及评估注意事项。2. 信度评估专家评估后，我们就拿到了评分问卷和主观问题记录表的原始数据。首先最重要的一件事就是预处理评分数据，评估信度，完成校验闭环。我们采用的信度可靠对照关系如下：如果第一次信度评估可靠程度不高，则需要调整数据组，重新进行信度评估，直至信度可靠。我们并非每一场体验评估都一帆风顺，在疫情期间远程体验评估时，我们就遇到了无论如何调整数据组都不能达到信度可靠的结果的情况。发现了这种情况，我们立即响应，临时邀约更多专家，快速加测了一场。欣慰的是，两场评估结果合并后，经过数据组调整，评分信度可靠。3. 业务复议通过第二篇文章我们知道，复议阶段的目标一是矫正部分理解有偏差的主观问题，二是让业务尽快了解 QMD 的结论，感受到其可靠可信，快速迭代优化问题。所以：复议呈现给业务的内容有：评分、分数对比、对应的主观问题、截图等；需要留给业务复议的反馈空间；想要做体验评估的你，需要具备一定的数据分析基础和表格操作技巧。4. 输出报告报告是为了让体验评估结论更加直观、可信，便于查阅与传播。我们对报告做了一些调整：① 评分和问题对应展示；② 评分间差距标记更加清晰明了；③ 增加 QMD 项目组的优化建议。希望业务重视分数洼地、不及竞品的指标对应的影响较大的主观建议。高优场景/指标/问题判断标准如下，供参考：权重最高或较高；和均值比差 10%/8%/5%/3%以上；和竞品比差 10%/8%/5%/3%以上；同比/环比差 10%/8%/5%/3%以上。三、体验跟进 & 项目复盘前面两篇文章介绍的体验评估指标体系和评估机制，是我们通过现状分析、理论分析等综合确定的，此时我们需要校验两点：一是需要校验根据认知、经验主观拆解的评估指标是否符合预期；二是需要校验 QMD 机制全程保障的专家评估结论是否可靠。我们采取的校验方式，就是看体验评估的结论应用到业务的体验优化后，是否带来如预期程度的业务指标的提升。所以我们在报告同步后，下一次体验评估前，留足业务改进优化的时间，组织参评业务复盘 QMD 结论落地情况。由各个业务阐述以下内容：问题发掘&解决：QMD 报告分析&洞察、解决思路&方案、上线效果&数据、结论；项目管理：优化进度、迭代计划。同时为了激励、帮助业务设计师推动结论落地，我们邀请设计总监、设计负责人和高阶设计师从三个维度为业务复盘的内容打分、点评，包括逻辑合理度、指标结果相关度、进度。同时 QMD 项目组收获了业务设计师对于整个体验评估机制的一些想法，结合组织过程遇到的问题和思考，做了周期性的复盘。四、推广 & 改正通过业务复盘及评委打分、点评，我们了解到业务的大部分迭代效果都是正向的，小部分负向效果的迭代需要尝试其他设计方案。所以目前没有因为复盘结果而要调整指标的情况。由此印证 QMD 体验评估的结论是可靠的，整个体验评估流程也是可靠的。如果有业务出现按照 QMD 的结论设计方案，验证发现预期的业务数据没有提升或者反而下降，则需要反思指标制定、分析、洞察、解决思路、方案是否有问题，逐一排查关键环节，及时作出调整。如开篇所述，QMD 项目组也在每次体验评估完成后进行复盘，持续优化评估机制，目前整个流程已经形成 SOP，便于高效组织每次评估，跟紧业务节奏，打好配合。五、最后以上详尽介绍了我们 QMD 项目组，组织 58UXD 各个业务体验评估的过程与思考。我们认为整个体验评估体系的升级和实践，最关键的思考逻辑就是闭环管理，这个逻辑贯穿始终，让所有人为因素的影响降到最低，保障过程和结果可靠可信。我们设定的闭环管理一共有以下三个方面：在策划环节，各业务制定的指标体系、整理的评估工具，都由 QMD 项目组审核，确保指标拆解符合指引要求，评估工具准确无误；在评估环节，各个业务的专家的评分都需要评估评分者信度，确保评分可靠；在跟进环节，通过业务复盘了解优化效果，校验指标制定的可靠性，以及整个 QMD 新机制为业务体验设计带来的价值。分享不易，希望对你有所帮助。欢迎大家留言交流。欢迎关注「58UXD」的微信公众号：本篇来源：优设网原文地址：https://www.uisdc.com/qmd-3
业务 用户 站在 对于体验设计师来说，最常见的棘手问题之一就是：如何平衡「用户体验」和「商业化需求」之间的关系。一位同学就问过我这样的问题：“我所在的公司产品为了冲刺营收，搞了很多营销手段，导致用户体验相关的数据下降了很多。产品经理也不重视用户体验，认为 ‘没有用户来投诉’ 就行。我作为产品的体验设计师，感觉很难去做点什么了。产品的营收确实重要，但这样为了短期目标而忽视用户体验的做法是不是不太好？作为设计师应该怎么办呢？”其实这样的情况，我这几年在大厂的工作中也没少遇到过。设计师在这时提出的体验问题大多会石沉大海，不被采纳。这就会导致很多设计师对工作渐渐丧失“工匠精神”，感到心灰意冷。那么此时应该怎么做呢？ 我有三条建议：站在业务视角：明确目标站在用户视角：尽量补救站在产品视角：做好记录相关话题的探讨：究竟是什么决定用户体验的走向？我总结了6个方面！随着 4G、5G 的普及，移动互联网进入成熟时期。阅读文章 > 一、站在业务视角：明确目标很多业务在某些特定的时期，目标并不是“好的体验”，有时“快”比“好”更重要，“能用”比“好用”更有价值。有时设计不是万能的，也不是必须的。虽然优质的产品和极致的体验是我们一直在努力追求的目标，但是对于很多产品、业务甚至是公司来说，“好体验”并不能支撑它们活下去。如果条件允许，相信没有业务方会抗拒好产品和好设计。他们也并非看不到体验问题，只是这些并不是当前的主要矛盾和首要目标。在不以设计为核心的公司和业务中，配合业务完成目标是设计师最基础的本职工作。 此时的体验设计师就需要：1. 了解业务需求的目标与业务方做深入沟通，站在业务视角，透过现象看本质：一定要搞清楚业务每个需求背后的目标和方向。短期业务目标有时可能会因为某些限制而与用户体验相悖，但长期发展的大方向一定并不矛盾。2. 理解业务行动的依据就像作为设计师的你有不能减损用户体验的理由一样，业务营销的行为也有其背后的依据和逻辑。也许是这种营销行为在此时此刻更符合用户心理预期；也许是以往经验证明这样的营销手段并不会影响用户与产品的长期关系等等。理解业务的显性需求和隐性需求，才会拼凑出完整的需求，你的设计决策也可以以此为据。当你手里拿着锤子，看哪里好像都是钉子。设计师是和用户打交道的人，最容易做的就是放大用户体验的价值。因此只有真正理解业务行动的目标和依据之后，才会杜绝偏见，也才能够在业务目标的指引下做出更加恰当的设计决策。二、站在用户视角：尽量补救“考虑用户体验”不是业务方的必修课，而体验设计师作为用户和产品之间的桥梁，就应站在用户视角，尽可能地对方案做补救和优化。设计在这个时候就要起到“托底”的作用。如果你想要保住产品的体验质量，不能只做批判和喊口号，还要拿出解决方案和落实方法。在这种业务相对强势的时刻，就更需要你：发挥主动沟通和协作的能力；洞察用户和业务两方的目的和需求；提供充足有力的设计依据；评估和利用有限的资源和成本；统一协调相关方推进进度；预估可能会遇到的风险和卡点。设计师的专业能力和价值不是只在大型项目优化中才得以展现，这种紧要节点同样也是你锻炼的机会。在有限的条件为用户体验质量做托底，我们不应该把自己定义为“受压迫者”，而是要做解决棘手问题的“设计军师”。很多时候，我们都会感到自己受困于当下的环境中，力不从心，独木难支。但其实不是你没有机会，而是你能看到这个机会背后的层层阻碍，因此下意识的退缩不前或转嫁责任。但如果你想要进步，就要把阻碍当成是升级的挑战，迎难而上。最重要的是，要克服自己内心深处的惰性，把抱怨“我不能”转变成思考“我怎样才能”。思考如何突破当下的业务困境，本身就是一种专业能力的历练，也是一种设计经验的积累。作为用户体验的一道最主要防线，该说的我们一定要去说，该做的我们也要去做。虽然很多时候结果并不是我们能够控制的，但过程往往比结果更有意义。三、站在产品视角：做好记录对于一些成本比较高，在短期内难以优化和迭代的点，如果你有想法和思考，就找个地方记录下来，静待优化落实的机会。未来如果产品有更新迭代，也许就能派上大用场。即使最后没有机会优化或落实你的方案，在这个过程中的思考和探索，同样是对你设计能力的培养和锻炼。生活中有很多事情并不会给你即时反馈，大多是看不到短期成效和意义的。但是几年之后当你回过头来，就会发现未来的你正是由现在的自己一步步塑造而成。你的每一步路，都不会白走。以上，共勉。欢迎关注作者微信公众号：「长弓小子」本篇来源：优设网原文地址：https://www.uisdc.com/balance-experiences-and-needs
组件 场景 业务 在 B 类业务里，服务多产品、多角色、体验复杂，设计师该如何做好体验标准化，保障基础体验一致性？下面我将从实战案例同大家分享。更多B端设计干货：B端设计太复杂？掌握这三步帮你理清设计思路！写在最前B 端界面的元素众多，视窗范围大，布局设计多种多样，为了简化布局思维，我们通常给界面添加三个方向上的轴-X、Y、Z。阅读文章 > 一、业务背景以我们 CCO 体验设计团队为例，主要服务阿里体系的消费者、商家、经济体等业务领域。随着业务不断扩大、用户角色多、体验复杂、设计师人力有限、定制化需求不断增加，设计面临严峻挑战。业务多：30 多个产品应用角色多：覆盖消费者、客服小二、服务管理、业务运营、中台管理、客户 6 大类用户群体。体验复杂：设计师需兼顾用户和客户两个视角。从组织上，85% 设计师纵向支撑业务，15% 设计师横向做标准化，反哺业务设计师。标准化实质解决的问题是保障基础体验一致性。二、标准化怎么做核心通过页面梳理、抽象、分发、衡量，保障基础体验一致性。三、案例实战以数据可视化场景为例，讲述如何做标准化。1. 业务现状共有 11 个应用，涉及 89 个页面。2. 问题体验不一致：各个工作台页面架构、组件、样式野蛮生长，缺少规范导致体验不统一。低效：部分场景缺失，组件重复建设，大量定制；沟通协同内耗大，成本高。3. 策略体验统一：框架、组件、样式。提效：代码化、工具、交付机制。4. 体验统一包括框架、组件、样式。① 框架现有页面收集用户场景分析：页面归类：结合用户看数内容（例：概览、分析、详情）和交互形态（例：平铺、下钻），对页面进行归类。通过统计高频复用形态，确定典型布局。② 组件页面结构分析组件的收敛，需要先对页面分析，确定模块层内容。例：模块包含页头、筛选、图表、表格。模块层分类横向收集全部业务，将模块层分类。细分模块扩展形态，放到对应的篓子里。模块专项治理接下来，需要对每一个模块进行专项治理。比如图表模块，再拆再抽象成指标、图表、单选、多选 4 类场景。场景里再对主体和变体（也就是扩展形态）分类。③ 样式确定优化内容围绕视觉凌乱，要做的便是完善设计语言。设计师需要结合自身技术底层，补充缺失规范。例如布局、色板、字体、动效。确定组件范围通过统计高频复用组件，确定需要梳理的组件范围。布局图例位置：线上有 9 种，通过从业务场景按阅读顺序划分，最终收敛成 2 种。组件高度：真实线上情况，只能看 2 个指标，高度规范缺失。需要根据用户分辨率调研，提炼典型分辨率。比如用户是 win 系统，包含菜单栏、任务栏等默认高度，再减去本身页面页头等默认高度，得到 3 档。确定组件建议默认行高 240px。轴标签旋转角度：现状有顺/逆时针两种，通过分析标签类型，结合阅读顺序、轴与标签亲密度，确定默认角度为顺时针。色板通过场景梳理，确定不同组件使用的色板类型及缺失色板。补充语义色板：从业务里抽象 2 类场景，指标和柱/饼/环场景，定义颜色。例如带正面语义，用绿色，比如升、已到岗、正常。带负面语义，用红色，比如降、旷工、失败。字体结合自身业务场景问题，从场景、版权、风格、识别、极值共 5 个维度选择字体。举例场景一，纵向数据场景里，将市面上数据竞品用到的字体都横向铺开尝试，做排除法。比如 din 没版权，苹方非等宽字体，普惠 102 识别性弱。举例场景二，在核心数据呈现中，helvetica 品牌风格弱，普惠在 1 亿以上极值过宽。最终我们根据自身业务场景特征，用普惠和普惠 102，运用在对应场景里。并同前端提炼规则。动效首先，需要确定动效价值，明确动效需要解决的问题。这里围绕舒适度、活力、层级、反馈来讲。通过动效场景链路分析，确定优化范围。加载动效：围绕让用户认知过程更为自然。通过组件横向梳理、抽象图形、组合样式的思路，输出方案。比如这里共梳理 17 种组件类型，抽象成 9 类，包括点、线、面、饼、环、柱、文本、图标、词云，再进行组合产出方案。出场动效：通过业务分析、提炼场景、优化效果。比如这里共提炼 3 类场景，有通用、监控、舆情。围绕过渡不自然、卡顿、缺少情感化表达来优化效果。浏览动效：通过提炼场景，来强化元素之间的层级与空间关系。比如单个组件、联动、下钻场景下，围绕点击感知弱、重点不突出、缺少悬停态来优化效果。沉淀速度参数：将优化动效场景的速度参数，同前端约定规则沉淀组件库。5. 提效包含代码化提效、工具提效、机制提效。整体思路从设计组内到技术产研的提效过程。提效面向用户依次是：组件设计师、业务设计师、前端、产品。搭建目前还在进行中，这里主要从交付-工具-代码化来分析。交付内容业务设计师：sketch/figma 物料 (样式、组件、区块、模板、规则 )业务设计师：kitchen 工具（样式、组件、区块、模板）组件工程师：组件规范/组件官网交付机制新需求：通过评估复用性、抽象、内审、沉淀物料。现有业务：通过页面梳理归类、抽象、内审、沉淀物料。6. 衡量从物理到行为层，包括样式、组件、框架、组件交互 共 4 个维度。通过一致性评分衡量标准化覆盖的好坏。四、总结回归课程，在 B 类业务里，服务多个产品、多用户角色、体验复杂的场景下，在定制化+标准化团队阵型里，标准化实质解决的问题是保障 60 分基础体验一致性。总结：B 端体验标准化包括物料的产出、交付以及衡量标准。产出：包括框架、组件、样式的收敛来梳理、抽象页面。交付：面向 2 类用户群体，业务设计，需交付物料和工具。组件工程师，代码化需提供组件规范，组件线上化需助力组件官网的建设。衡量：一致性评分包括样式、组件、框架及组件交互。欢迎关注作者的微信公众号：「AlibabaDesign」本篇来源：优设网原文地址：https://www.uisdc.com/experience-standardization
产品 业务 客户 前言接触 B 端设计的小伙伴会发现，很多业务具有角色多，业务场景复杂，功能链路长等特点，所以在工作中会经常遇到以下几个问题：突然被调配到新业务，拿到一个不熟悉的业务或者新产品，不知如何开展工作？换了一个新行业，面对一个从 0 —1 的新项目，应当如何熟悉新业务？面对较为复杂的业务，经常和业务方沟通讨论不在一个频道，又不知如何着手。本文将从以下 4 个角度展开探讨，当设计师面对 B 端新业务时，应当如何快速熟悉业务并开展工作。类似方法；什么样的公司值得设计师全情投入？来看总监级的分析！之前分享的关于如何进入大厂的建议里，提过我们要学会利用跳槽这个工具做杠杆，帮助我们进入到更好的平台中，实现职业的升华。阅读文章 > 一、查行业和竞品首先，不要一上来就急着看系统。线上的功能模块只是实现需求和业务目标的手段，并不一定是最优解，能够为客户解决问题的方式有很多，不一定非得是我们提供的互联网服务。所以如果我们一上来就着急走数据看系统，很容易就会把自己的眼界，局限于这些产品的功能界面中。1. 查行业报告首先需要明白自己从事的是一个什么行业，这个行业叫什么，是做消费品的、是酒旅还是建筑地产等。提供企业服务有做 saas 的、有做 Pass 的、有做平台数据对接的、也有本公司自研系统，第一步要建立起对这个行业有一个宏观的认识。通过市面上的这些行业分析报告，可以了解到自己做的业务处在哪一个赛道，另一方面也能大概知道目前所做业务，在市场处在生命周期的哪一个阶段。比如下文就是艾瑞咨询关于中国 SaaS 产品的一个图谱，通过这些图谱不光可以了解我们公司产品所处地位，也能纵向知道公司产品的竞争对手有哪些。比如为企业提供 saas 零售电商服务的就有微盟、有赞、小鹅通等服务工具。想了解这方面资料的同学，可以通过艾瑞咨询查看：https://www.iresearch.com.cn/2. 查行业竞品看竞品不仅是要看产品本身，还要比较它的行业地位，需要了解我们的产品在大背景下，处于一个什么地位，是行业头部，还是在追赶地位。同时，还要关注产品背靠的资源和竞品相比有哪些区别。比如这两年大火的 Scrm 运营工具——微盟的企微助手，背靠的资源就是过去几年通过商城零售产品积累的客户。以及微盟于2022年发布的WOS新商业操作系统中，企微助手与微盟其他产品的超强融合能力。关于行业竞品，需要大家花点时间找一找，也可以通过相关的负责人问一问。这里推荐通过以下两个网站查询：36Kr 企服点评：https://www.36dianping.com/字母点评：https://www.zimudianping.com/#/3. 查公司战略了解公司战略并不是一句虚话，它涉及到你后期负责的业务的发展方向。比如微盟从 2020 年开始提出大客化战略方向，如果你是负责零售这一块的业务，你必须要知道你的客户群体是要以大客为主，大客和小客在需求痛点上是完全不一样的，所以这涉及到我们后期面对这些角色设计上的一些区别。再比如微盟 2022 年新推出的 WOS 新商业操作系统 ，除了提供微盟的标准化产品解决方案外，还可以让更多的生态伙伴产品参与进来共建产品，包括 PaaS 平台，可以满足商家的个性化需求定制。这也会涉及到我们在产品设计，页面框架层搭建的兼容性，需考虑覆盖各类业务、以及产品对外的一致性等。二、看产品和价值看产品，是指看产品的业务文档，而不是看 prd 界面，需要了解产品的核心价值和目标客户群体。这个阶段，需要看产品在什么样的场景下，帮助哪一类客户，解决什么痛点或者问题。这个阶段涉及产品一切的文档资料，包括业务背景、需求文档、宣传文档、产品白皮书、销售资料和公众号等，我们都需要尽可能多的，主动性去找相关资料和数据查看。1. 看产品的专业词汇很多 B 端产品都是服务于很垂直的领域，所以不免涉及到专业领域的一些词汇。比如 CDP 产品，我们在了解这个产品时，需要知道一些基本概念，比如什么是多渠道标签，标签的类型有哪些，什么是文本标签、多值标签、日期标签等；用户分群里的人群包、自定义人群和系统人群，以及常说的圈人条件是指什么。如果我们发现自己的产品还没有整理这些信息，我们可以通过竞品的官网，或者到竞品的用户手册、帮助中心等模块找到这些信息。我们还是拿 CDP 举例，下方就是就是火山引擎和 Growing IO 的帮助文档，熟悉了这些专业词汇，可以让我们可以更快的了解产品，当然如果你有时间，也可以帮助自己的产品去整理这一份文档。2. 看产品的价值怎么去看一个产品的价值点，这个较为复杂，我们可以借用一个工具叫价值主张画布（The Value Proposition Canvas），它可以帮助我们很好的去理解产品和目标群体之间的关系，清楚地描述出产品帮助客户解决了哪些问题，和创造了哪些收益。价值主张画布内容较多，感兴趣的同学可以看一下《价值主张设计》这本书，这里我们简单总结分为「价值地图」与「客户洞察」两个板块。价值地图：描述产品为客户创造的价值，包括产品与服务、创造价值、解决痛点产品服务：我们给客户提供的是一种什么样的产品或服务解决痛点：产品解决了用户的哪些难题创造价值：产品让客户获得哪些好处客户洞察：帮助我们理解客户，包括客户的任务、客户的痛点以及客户的收益客户工作：是指客户利用系统要做哪些工作日常及事项客户痛点：客户在本来工作流程中遇到的问题及阻碍客户收益：指客户通过购买该系统，获得的盈利来源三、理功能及流程1. 理产品功能大图一定要看核心业务或者产品功能的大图，理清业务功能模块、数据之间的来源去向关系，整个平台的数据是怎么流转的，以及最后是怎么形成逻辑闭环的。这时最好多向身边的同事多多请教，避免埋头苦干，可能自己纠结了半天的问题，可能都抵不过同事的一点点拨。比如近两年大火的私域运营工具 SCRM，其核心本质是一个社交化的私域运营工具，其 PC 端功能主要分为 4 块，引流获客 — 促销运营 — 营销转化 — 决策管理，下图就是是微盟企微助手产品功能模块大图。2. 理数据流程业务流程相对是一件相对复杂的事情，不同产品的流程侧重点不一样，有些产品的流程会牵涉多个角色，这个时候需要找到对应产品负责人，要到不同权限角色的账号，因为不同权限角色的账号功能也不一样。有了账号，了解每一个功能菜单帮助客户解决了什么问题后，就可以建数据走流程了。① 找到核心功能模块首先找到该业务的核心功能并熟悉它。比如拿 SCRM 产品举例，微盟企微助手、微伴助手和微盛企微管家都将「活码」这个菜单功能排在头部位置，一方面是从产品的使用频率考虑，另一方面它也是产品的核心功能模块。怎么找到核心功能模块？你可以通过产品的导航、或者产品官网的介绍，找到产品的核心功能模块。② 关注不同角色的工作和 C 端产品不同，B 端产品角色相对固定，我们需要关注有哪些角色、角色之间的协同关系、工作的场景、目的和操作链路。概括起来有以下三个内容：角色信息、工作内容、考核指标。角色信息：包括角色名称、工作职责、能力维度等。比如 SCRM 产品会有老板、运营负责人、员工等角色。工作内容：具体场景、内容描述、目标和期望。比如老板会看整体数据及基本分析结果，运营负责人会维护整个系统的信息和数据分析，包括创建派发任务等，员工更看重任务完成等。考核指标：一般会结合任务而需要完成的考核指标，这个和每个产品的特性有关。③ 体验并感受产品在体验产品的过程中，把自己带入产品的角色中去，用我们专业的眼光走查一遍产品，比如产品的框架设计如何？里面操作流程是否符合用户认知？各功能模块的交互是否一致？是否会有操作的错误的判断可以结合自己的交互走查表，不过仍需注意，不要陷入到产品的细节体验中去，毕竟我们要做的是熟悉各个功能模块。这样的好处，可以避免产品因历史的包袱问题而带来的眼界束缚，完全用一个全新的观念和心态体验新产品。在建数据流转的过程中，我们可以得到一个小白用户对于这个产品的使用体验，在使用的过程中，也可以记录下来自己的行为和感受。对于很多新的产品团队来说，一份新手用户对于产品的认知和体验感受也是一份宝贵的资料，因为等我们真正熟悉业务产品时，很有可能会忽视这些旧问题。在建数据的过程中，可以结合之前相关业务文档一起看，一边走一边了解每个功能模块的前世今生和具体细节，同时产品的数据流转一定也要多走几次，尽可能理清数据业务的流转逻辑。④ 特殊产品仍需和线下实践结合有些特殊化的产品，流程比较复杂，需要亲身经历和体会。比如拿物流的 WMS 仓储系统来说，如果不到现场亲历入库、出库、盘点和分拣等实体操作，光通过系统和文档，很难知道现场作业人员的所思所想，和不同角色所要关注的点。只有亲历了一遍现场以后，才会知道作业环境的嘈杂和混乱，所以有些特殊化的系统，还是需要自己体验走完一遍这个流程比较好，毕竟纸上得来终觉浅，绝知此事要躬行。3. 理交互规范有了对整个产品功能模块的了解，下面就是熟悉产品的交互框架，还有一些组件库。尽可能做到在实际设计时让这些组件做到复用，这样可以帮助我们节省很多时间，也可以避免很多交互上的错误。四、问对人说对话通过前面的一系列自主调研及建数据流转，对我们所要负责的业务有了一个较为清晰的认识，这中间我们也会产生很多问题，不免需要上下游的小伙伴们打交道，怎么和小伙伴沟通讨论仍需掌握一些方法。1. 问对相关业务人我们需要找到业务的关键人，特别是刚去一个新公司面对一个新业务的情况下，这个时候需要了解业务的人员组织架构，找到对应的负责人，当然我们不可能上来就让人家给我讲讲业务和人员架构。找到对应负责人。比如我们可以这么说，不知道你有没有时间，或者你是否能够推荐团队里面的大佬能够给我讲一下，以便我们后续更好的配合及开展工作。问问题不要过于笼统。在和对应的业务产品沟通的时候，你不能直接说，你能不能给我讲讲这个功能或者业务，这个问题太过于概括和开放，对方一下接不住这个问题。如果对方没有做准备，很有可能在他和你讲的过程中，还会涉及一大堆技术和行业词汇。2. 说对话的一些有用技巧把问题整理好，可以集中性的问，不要一个个的去问，以便不停反复占用别用时间，毕竟谁也不喜欢不停地被人打扰。如果是一些抽象复杂的问题，提前发给人家，让对方也有个准备时间。在向别人请教的时候，如果能够带上纸笔作记录更好，以表示对别人的尊重，等到回到自己的工位后，也可以自己画出产品的业务的流转图，加深自己对于产品的理解。如果可以，给别人带上一杯奶茶啥的，毕竟没有人有义务无条件帮助你。相关技巧：超全面！给用户体验设计师的提问清单在用户体验设计师（UX）应该掌握的各项技能中，如何问有意义的问题是一种经常被忽略的技能。阅读文章 > 关于新入职的同事，或者被调到一个新业务时，我们需要向当前业务骨干设计师请教业务问题时，也需要掌握一点说话技巧。我曾在群里看到一位前辈分享过一个表达话术，和大家分享下：总结关于了解业务，我们整体的思考框架是，先整体再局部从大到小，从行业入手了解行业竞品，产品是怎样的商业运转模式，再通过价值主张这个工具，了解产品各个功能模块的价值。找到产品的对应负责人，了解业务或者产品的组织架构，知道产品的核心模块是哪些，清楚不同角色的之间的流转关系是怎样的，将角色之间的流程串联起来，就能够达至了解业务。最后，我们对产品的掌握了解差不多了，其他的非核心模块，可以在后期做项目的时候，一边做一边了解。希望本文对你有所帮助。参考文献Yves Pigneur《价值主张设计》欢迎关注作者微信公众号：「小高杂谈」本篇来源：优设网原文地址：https://www.uisdc.com/systemize-your-business
价值 业务 目标 UX/UI 设计师在日常工作中是否遇到以下疑问：1.方案由上游主导，设计师没有发挥空间怎么办？2.如何从设计视角出发梳理体验优化建议？3.如何向各方证明你的优化建议是有价值的？要回答以上问题，首先得理解设计价值究竟为何。设计价值相关模型：如何清晰量化设计价值？试试这个超实用的GSSM模型！编者按：本文通过实战案例，帮你掌握一个能量化设计价值的GSSM模型。阅读文章 > 一、如何理解设计价值设计≠艺术，设计从诞生之初就是为“解决问题”而存在。在体验设计场景，如果业务方是“需求提出者”，那产品经理和设计师就是从不同视角切入的“问题解决者”，而用户既是“需求源头”，又是“方案验证者”和最终“价值创造者”。下面我们详细解读「设计价值」与「业务/用户/产品」三方的关系：1. 设计价值源于业务目标，产于业务价值变现商业设计本质上服务于业务，因此判断设计价值的关键是：是否真正地帮助业务解决问题，助力业务目标达成。换言之，设计价值就是设计师通过设计思维/策略/方法，直接或间接帮助业务创造的那部分价值。设计不能脱离业务自嗨，不能“为了强调设计的存在而设计”。 有效设计在于对业务诉求的精准满足。我们构思设计方案时，脑海中始终要回答：实现了哪些业务目标解决了哪些业务问题创造了哪些业务价值2. 通过对用户需求的洞察和满足，为业务创造价值业务价值最直接的来源是用户价值的变现，因此，想要实现业务价值 要服务好用户，这为设计价值的实现提供了有效抓手：设计师可以通过洞察用户需求，完善产品功能、优化操作体验的方式助力业务目标达成。P.S. 用户价值 = 产品给目标用户带来的核心价值，即：帮助用户解决了什么问题，满足了什么需求，提供了什么服务。3. 产品 PRD 是“第二参考视角”对于资深设计师来说，产品 PRD 不一定是最优解，它更像是提供了解决问题的第二参考视角，产品侧在理解业务目标的基础之上，从实现角度产出了初步解决方案，为设计师打开思路。不同阶段设计师在面对同一份 PRD 时，有如下处理方式：初级：不知其然，表象复刻——直接按照PRD方案输出相应设计；中级：知其然，表象优化——对PRD方案进行查漏补缺，提出体验层面优化建议；高级：知其所以然，透过表象看本质——综合业务/产品目标，挖掘用户原始需求，提出当下最优解。二、3维推导设计目标当设计师拿到 BRD & PRD 后，如何综合多维视角制定设计目标和策略？下面列举了笔者在日常工作中重点关注的维度。1. 业务视角：明确定位业务会从商业角度提供清晰定义产品边界和价值变现模型，从 BRD 中可以提取以下重点信息：产品/需求的目标用户类型和特定场景范围；给用户带来的核心价值（帮助用户解决了什么问题/满足了什么诉求）；用户价值变现模型和策略（如何通过满足诉求进而实现用户价值变现）；业务价值可量化指标我们需要注意以下两点：关注北极星指标，比如某些场景侧重“留存”，有些侧重“转化”，这会影响设计侧重；在产品发展初期，了解业务线未来的布局和规划，可以帮助我们把握设阶段性计节奏。2. 用户视角：匹配 & 完善需求用户是一切需求的源头，仅从业务视角出发定义需求是无本之木。因此当设计师碰到业务需求不明确，或者对产品方案存疑时，最好的办法就是回归用户视角。用户需求挖掘一方面可以丰富和完善业务目标，另一方面也帮助我们审视当前业务需求是否与用户诉求吻合。通过用户分析我们可以得到：目标用户特征；典型场景下核心诉求、任务和关键行为；关键行为对应的可量化指标P.S.为了挖掘多维度用户诉求，我们可以根据具体场景将用户细分，如：角色：如 B 端/C 端；熟悉程度：小白/普通/专家；客户价值：高价值/一般价值；目标强弱：强目标/半目标/无目标；兴趣/偏好：价格敏感/小众人群；阶段：获取-激活-留存-收益-推荐；流程：开始前/进行中/结束后...3. 产品视角：产品策略 & 实现约束在业务主导的场景下，产品经理往往是需求的“第一经手人”，我们需要在 PRD 中捕捉到产品对业务需求的理解和转化策略。另外，产品视角也阐释了在落地实现层面的约束限制，特别是前台与中/后台的依赖关系。从 PRD 中可以获取以下重点信息：产品目标和策略；功能范围和核心流程；前中后台能力支持；实现成本和风险点在消化 PRD 过程中我们需要注意：① 从产品系统视角审视需求：多数情况下，我们接到的需求是点状的，可能是某个子模块的子流程/功能，此时我们可以用更系统的视角向上追溯，定位模块所属能力矩阵，找到模块与模块之间的联系，这有利于精准把握需求，保证链路场景闭环，为后续由点到面驱动更大层面体验优化作准备；② 不要忽略实现层面的限制很多功能不是“不该做”，而是当下“做不了”或“性价比低”，一些优化方案提出前，我们需要从产品角度考虑现有中后台能力支持、研发可行性、运营人力成本等，避免设计“空中楼阁”。综合以上业务、用户和产品三个维度，我们更加精准推导设计目标。需要注意的是，设计不是万能的，大多情况下设计只能通过“影响/实现局部用户价值”间接助力变现，我们只需关注可以通过设计手段参与、干预和落实的部分即可。一个设计目标的完整表述 = 通过「XX 设计策略」帮助目标用户「实现 XX 价值/满足 XX 需求/解决 XX 问题」，以助力「XX 业务目标/变现方式」达成。（在实际表达中可以适当精简）三、方案推导 & 价值量化确立明确的设计目标和策略后，下面进入设计实施和验证阶段，这里推荐两个基础的推导模型。1. SKS 模型：从策略到方案SKS 模型，即策略(Strategy) 影响因子(Key factor) 解决方案(Solution)。设计目标中的策略是一切方案推导的源头，我们需要找到影响策略实现程度和效果的关键因素，将其视为可控变量，并以这些变量为切入点进行方案尝试，最终衍生多种解法。比如：我们把提升 Banner 的点击率作为策略，那影响 banner 点击的影响因素可能是：形式是否新颖、配色是否亮眼、是否有动效引导、利益点是否突出、行动按钮是否吸引人点击等等，每一个影响因子都可以衍生出多种设计方案。2. GAM 模型：从目标到指标上文提到，设计手段通常是以间接方式助力用户价值实现，进而赋能业务目标达成。那如何量化设计价值呢？我们可以使用“GAM 模型”，即设计目标(Goal) 高价值行为(Action) 衡量指标(Metric)。具体方法如下：① 设计目标反推高价值行为一个设计目标实现，一定是由链路中一个/多个高价值行为促成。比如用户在真正“下单”前，会访问商品详情页，浏览商品详情页信息，加购物车等。② 用行为指标度量设计价值用数据刻画和度量高价值行为的指标变化，进而度量设计方案的价值。 我们可以尽量多维度拆解高价值行为和相应度量指标，维度越多，关联性越高，判断误差越小。四、小结事有轻重缓急，不是所有的需求都需要走上述方法进行设计分析，要学会辨别重点的、有发展潜力的需求投入更多设计精力深入研究。后续笔者将通过具体的设计项目，详细阐述如何运用业务产品用户三重视角，推导改版目标和设计策略，敬请期待《设计师如何提升专业价值-实战篇》。参考文献：《五步推导，让你成为体验设计专家》《谷歌 HEART 用户体验模型》《如何理解「设计价值」？又该怎样体现？》《互联网产品经理应该具备的 3 种视角》欢迎关注「JellyDesign」的小程序：本篇来源：优设网原文地址：https://www.uisdc.com/increase-design-value
产品 行业 业务 在我们日常的沟通当中，很多时候大家都会将自己的产品，以“B 端产品” 这样宽泛、含糊的方式进行阐述。但是 B 端产品由于服务对象不同、发展方向差异，也就导致产品本身就会有很多不同的分类。今天就和大家分享 B 端产品的四种分类，以及对于设计师而言，这些分类会给我们设计落地、职业选择造成哪些影响？往期回顾：B端设计指南：从 4 个方面帮你掌握「审批」的知识点一直以来，业务都是 B 端逃不开的话题，你可以在许多文章当中看到我们的改版方向是因为业务需求、设计的思路是因为业务需求。阅读文章 > B端设计指南：网页布局方式科普栅格一直都是很多同学非常疑惑的地方，无论是栅格的日常使用，又或者是栅格在整个产品当中的作用，一直以来都有非常多的疑惑，今天就来聊聊栅格在实际工作如何使用，以及产品之间究竟有何区别。阅读文章 > B端设计指南：栅格的定义和使用方法在一个 B 端页面当中，关于栅格的使用方法，你或多或少都会有所疑惑。阅读文章 > B端设计指南：6800字干货帮你掌握快捷键设计前言键盘，在很多人的眼中，就是一个信息录入的硬件设备。阅读文章 > 垂直业务型产品垂直业务型产品是针对企业垂直独立的业务需求所设计出来的 B 端产品。这类产品的出现，主要是围绕某一个复杂业务场景，去解决这个场景当中企业经营、管理的实际问题。比如以 CRM 为例：CRM 的全称客户关系管理系统因为它是客户关系管理系统，而使用这类产品的主要角色就是销售员工，他们在进行商品售卖（特别是交易周期较长的商品时）需要销售人员通过 CRM 进行管理客户。而作为企业为什么要使用 CRM 产品？其实是因为企业本身会有较强的管理需求，我希望能够通过 CRM 去监督每一个销售人员究竟是否认真完成工作，是否合理合规高效的与客户进行跟进沟通，因此可以通过 CRM 满足企业的管理需求。但“销售”这类角色往往非常特殊，它存在于各行各业，比如楼下提供保险业务的销售人员、楼上在线培训的销售人员、自己公司 B 端产品本身的业务销售人员。而大多数 CRM 产品考虑的不是针对每一个行业单独去制作一款 CRM，因为销售团队在使用的过程当中，就会存在很多共性，产品便可以通过共性去抽象一个针对多行业的客户关系管理系统。垂直业务型通常属于 B 端产品当中难度较高的产品类型，因为不同的业务，往往作为设计师需要了解的不是简单的这个页面长什么样，而是这个业务下，员工应该怎么用，怎么用才是更为合理的，而在很多招聘信息当中，就会发现企业更喜欢去招聘有过类似经验的设计师。当然作为设计师，如果选择进入一家垂直业务性产品的企业，应该更多的去阅读行业相关的书籍，比如想要做好 CRM 产品，你必须了解什么样的销售人员，具备什么能力，才是一名资深的销售。通过了解行业人员的具体使用细则才能更好落地设计。行业属性型产品行业属性型产品是针对某个行业定制的一系列，从上至下、从内到外的产品功能。这类产品主要是围绕一个具体的行业去构建整个产品的解决方案，目的是这个行业的商家，在使用了这款产品过后，就能够解决它目前经营过程当中的问题。比如以在线教育行业为例，小鹅通应该就是在线教育行业的头部产品，去观察它的产品功能模块你会发现它会涵盖课程详情的内容管理、学员知识付费的交易管理、对产品进行营销的 Marketing、成功付费学员的客户关系管理，而这些功能模块在其他产品当中都可以单独拿出来，当做一个大型的 B 端系统的功能。行业属性型产品更多是以这个行业当中需要用到的产品出发，考虑就不再是单一的老师角色，而是一个课程培训行业所涉及到的所有工具，都希望能够通过行业属性型产品去解决。在设计上，行业属性型产品不会过于复杂，功能都会相对比较简单，因为对于这些商家而言，不需要过于复杂的系统，只要你能够满足它的日常工作即可。比如小鹅通，就是属于在线教育行业的产品，它与纷享销客当中的客户管理就会存在明显差异，无论是从功能还是界面的复杂程度来说，都完全不一样。可以看到筛选、视图、表格操作，等多方面的交互、产品规划，都会有明显的差异。协同办公型产品协同办公型产品是通过软件实现工作协同、办公自动化，让企业高效运转的产品。大多数情况下，企业内部的办公管理没有太多个性化诉求，因此会购买成熟的办公协同产品：比如飞书、企微、钉钉、泛微目前较为常见的协同办公产品包含：在线文档、OA 办公自动化、IM、在线会议、项目管理、研发管理等产品。协同办公产品，在企业当中通常只会有一款软件。比如在一家企业 使用了企业微信，就等于它会去使用腾讯会议、腾讯文档、tapd 等多款关联性的产品。在设计层面上，协同办公型产品是最接近 C 端产品的特性，因为他的使用人群很多，并且使用的角色也复杂多样，因此在产品设计上，对于 视觉交互往往有着更高的要求。运营管理型产品运营管理主要分为运营与管理两个系统。运营是针对自己本身就有 一款产品 A（不限于 C 端 B 端） ，为了满足产品 A日常界面的展示与维护，需要专业的运营类后台系统所支撑。比如淘宝、抖音、小红书，这些产品，他们都会有自己的内容审核 、广告投放等多个后台系统。运营的主要目的就是审核，日常的数据资料维护，比如以 sspai 为例，在少数派的网站当中，有作者进行投稿，因此必然会存在对应的运营人员进行内容审核，同时少数派还会有会员、商品购买，因此能够推断出少数派的运营后台一定会包含类似成员管理、会员管理，订单管理等前台系统已经拥有的功能，来执行网站后续的运营工作。而管理则是针对系统当中的商户、用户、租户的“信息资料”进行管理。主要会涉及到：商户的门店信息：饿了么的商家服务后台，商家可以进入到系统里面去配置门店的具体信息、售卖的菜品、对应的活动等等，而饿了么就是通过这样一个平台能够规范商家在系统当中的行为，能够对他们进行有效的监管。租户功能的开通：租户主要针对的是 SaaS 产品，也就是购买 SaaS 产品的客户，而我作为产品提供方，想要对每一个客户进行管理，就会有一个租户平台进行管理。比如在我们一个租户管理系统当中，为了让客户成功对每位租户的信息进行快速操作，在设计上并没有优先去考虑设计原则，而更多是将操作外置，让信息快速传递的同时，能够快速操作。同时使用的客户因为都需要进行上岗培训，这样简单的操作也能让他们更容易理解。用户信息的分析：对所有在平台的数据进行分析管理。比如在 B 站当中，就会存在大量的用户，一旦有人发言出现问题，或者言语行为过于暴力，那一定会有系统来管理这样的特殊情况。而用户给到的数据我们还能够对其进行更为细致的分析。最后其实一款 B 端产品并不是固定在某一个类型当中，更多是随着市场的不断发展进行变化，因此要去理解的是这个软件背后的业务诉求、推导他们的功能模块，盯着一款产品“发呆”（其实就是去想想，多理解），当然这对于 B 端产品的类型，有什么自己的想法也可以在评论区发表自己的看法～全面了解 B 端产品设计：如何理解需求？在上一篇《全面了解 B 端产品设计：基础扫盲篇》内容中，我们已经知道，B 端的设计难点不在于精美的外观和复杂的设计，而是要符合产品的实际需求，并有效提升业务运营的效率。阅读文章 > 欢迎关注作者的微信公众号： CE青年Youthce本篇来源：优设网原文地址：https://www.uisdc.com/b-product-type
业务 阶段 需求 “一入 B 端深似海”…就这一句来开始话题吧，希望跟大家分享一篇小心得：「在 B 端产品设计中踩过的坑+趟过的泪之如何快速融入业务」，希望对想要往 B 端发展的同学有所帮助，毕竟你越了解业务，业务越需要你。阶段一：把握好入职前期的业务熟悉阶段（大概 2 周时间）刚入职的前 1-2 周，是很好的业务熟悉阶段，在这个阶段不会有迭代项目的设计压力，也不会有产品/开发/测试同学来沟通 UI 问题…但我狠狠的错过了这个好时机，所以挥泪总结如下：1. 一定要拥有一个最全的测试账号（测试环境+线上环境）B 端产品用户往往是兼具多种身份角色的，「员工 A」、「管理员 A」、「管理员 B」、「管理员 C」等等身份，这些身份权限既可能交差，也可能毫不触及。所以拥有一个兼顾所有功能模块的测试账号，是了解业务的第一步。2. 带着角色身份，有目的性地操作前期在使用系统的时候，千万别站在一个旁观者的角度，去审视这款产品。既没有把自己当做「员工」去体验整个实施过程，也没有作为「管理员」去创建管理项目，在业务前期迭代设计中只起到了美化原型图的作用。当然这种「没目的性的操作」还会带来另一个非常不好的点就是：对功能的记忆点很模糊，一顿猛操作后自我感觉良好，认为已经搞懂了业务逻辑…却没有去思考为什么当时要这样设计（是只为了满足业务的被动需求还是设计方案的局限，又或是基础技术方案的限制，站在不同的角色场景中，体验是否顺畅合理，是否还有其他更优化的设计方案）。这些「思考点」其实都可以简单的记录下来，到项目迭代中有涉及到这些点的时候，可以再去深挖。阶段二：拿到产品需求后的准备工作（立项-概设阶段）这个阶段需要输出设计方案的思考点，立足用户场景，满足业务需求，与产品经理密切沟通需求与设计方案。1. 本次迭代涉及到了哪些模块，是否在前期都有线上的实操体验？如果前期没有操作体验过，那咱就在了解「需求」想要解决的用户场景后，带入角色的去体验模块。2. 是全新功能设计还是既有优化？这可以初步的判断一下时间排期，设计的优先顺序，是否需要用到「体验画布」去拟定方案，是否需要参考「竞品分析」等各种辅助设计工具（这些都是需要花时间的，紧张的迭代周期不可能满足所有需求都应用到这些）3. 沟通（产品经理、测试、其他业务线的设计同学）在需求分析阶段最需要紧密联系的人就是产品经理，了解他们在业务设计阶段的方案，去参考其他竞品是否有利于我们的产品设计。但产品经理站的角度往往仅是满足被动的业务需求（功能层面上）。在满足功能的同时是否有更好更顺畅的体验设计（体验角色是偏「学员」身份多一些，还是满足「管理员」身份多一些），这是我们需要跟产品经理沟通–梳理–拟定方案的。充分「利用」好测试同学，因为他们其实才是最了解功能模块的人，每天不计其数的操作，让他们甚至比产品经理更加熟悉模块。产品需求是否设计合理，测试其实更有主动权。如果你所在的公司拥有多业务线，其实在一些共性的功能模块上，还可以多多与其他业务线的设计同学们联系，视觉+交互上是可以借鉴，既能满足公司品牌调性一致，也能多一项设计参考，共同进步嘛…4. 形成自己的需求清单我之前用的方法是直接把产品的需求文档打印出来，在上面做笔记，但后来发现这种方式不仅费纸，效率也不高。现在直接在 sketch 文档里专门建立一页，把「业务背景」、「目标」、「产品解决方案」、「设计方案思路」「…」都罗列出来，随时都可以跟踪记录下每一次讨论的结果。在后续的画图中，是否画着画着就偏离了「目标」，也可以随时检查。阶段三：设计实施阶段（不要局限于同类竞品设计参考）阶段四：走查阶段你是不是也会遇到视觉走查不完整的情况，有些模块细节点会被遗漏。因为走查阶段是在开发功能都提测以后，但最充裕的时间可能都没有 2 周（中途还有开发调整修改的时间、有些功能点还需要反复去看）所以时间很紧。如何才能保障至少走查两轮呢。之前一直都是在现有的测试项目上根据迭代的功能测试，走查的界面特别零散，很容易遗漏。但如果一开始我们就创建了「专属账号」，在熟悉整个流程的情况下，对新迭代的需求进行复核，操作就会是连贯的，步骤是紧密的，就会把很多细碎的点串联起来了。写在最后希望大家别只顾着卷，被工作节奏打乱了自己的脚步…文章写得有点幼稚，但希望能对小白菜们带来些帮助启发，大家一起进步。学会「交互设计五要素」，帮你更快Get到设计关键点！B端浪潮下设计师的「尴尬」供应链资源整合是企业发展态势。阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/b-end-business
信息 用户 业务 在决策类产品中，用户的行为路径一般从信息分析场景到信息决策场景。系统关键信息密度的高低是影响用户决策速率的重要因子。因此我们建议从「信息拆分与重组」、「功能高效聚合」两个层级出发，以提升关键信息在页面模块中的的密度。B 端有效信息密度提升设计框架的颗粒度由粗到细可总结为三个层级，分别为基础层、功能层与信息层。首先是基础层，B 端产品多场业务景、多用户角色、多任务流程的关键性差异决定了业务侧信息是一切设计的出发点；再者，需依据业务场景定义、角色定义与任务流排布的相关内容链接与聚合产品功能；最后，基于以上信息，使用交互与视觉相结合的设计方法，降低用户与系统的交互成本，引导用户聚焦产品核心能力，提升关键信息在页面中的密度与触达效率。「信息拆分重组」：在 B 端系统中，信息拆分与重组是依据业务与产品内容对信息进行重新组合，以求达到低跳转、高密度、有效触达的设计目标。「功能高效聚合」：在 B 端系统中，功能高效聚合是依据业务场景与业务逻辑对产品功能进行重新整合，旨在单位时间、单位面积内的带来更多商业效益/效率提升。案例一：入库计划-销售计划确认产品设计方法：信息层拆分与重组。项目背景：基于对计划方式的调研及整理，结合业务侧对于销售计划确认模块提供参考信息过少、浏览体验较差等问题，对明细表格及其他部分进行整体体验升级。用户痛点：销售计划确认明细表格的浏览与分析效率低下，导致线上计划确认难。设计目标：依据业务逻辑对表格信息进行拆分与重组，减少并优化用户眼动轨迹，提升信息展示密度。案例二：全流程数据概况产品设计方法：功能高效聚合项目背景：对全流程进行数据可视化，分环节数据监控，同时展示时效等更多维度数据，便于业务快速定位异常并跟进处理。用户痛点：用户在产品方案中无法快速获取到履约率相关数据，在一定程度上影响数据分析与决策的效率。设计目标：依据业务逻辑排布浏览分析全流程数据任务的起点、过程与终点，缩短优化用户眼动轨迹，提升信息触达时效。最后以上就是「关键信息密度提升设计」的全部内容啦～录入流程设计、任务中断回溯设计已经发布，感兴趣的小伙伴记得阅读收藏哦～后续会为大家带来「场景化设计」等 B 端的设计方法，希望能给正在从事或准备入局 B 端的的小伙伴带来启发，也希望跟大家一起探讨更多的 B 端设计方法。B端案例实战！执行类产品的录入流程设计指南执行类产品中，信息录入是用户工作中最常见的场景之一，用户按照要求录入信息提交给系统，系统整合信息以完成执行结果。阅读文章 > B端决策类产品设计指南：任务中断回溯设计在 B 端产品线特别是在决策类产品中，针对在较长时间段内任务中断回溯的场景的设计方法在 B 端产品线中，特别是在决策类产品中，经常会出现因为需要决策的信息量多、任务处理周期长而造成任务（主动 or 被动）中断，用户反复多次进入任务处理流程的情况。阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/density-lifting-design
业务 希望大家 流程 hello~好久不见~~这次分享内容是一个比较不错的从业务侧到产品方向以及最后推导出设计方案的完整流程~相信对于很多小伙伴设计思路方面会有一个比较大的帮助，也可以更好了解一个产品设计推导方式，为了方便大家理解我加入比较多的说明和分析，希望大家能有启发和帮助。就像最后说的，设计环节除了输出业务给予的需求，同时能够影响业务结果的商业价值，希望大家的设计都能为整个项目业务赋能（赚大钱）最后祝大家新春快乐啦~（记得一键三连）（PS：该项目设计部分分享已经过相关负责人许可）如何系统化的思考设计改版？我总结了这个流程！最近有小伙伴问我，设计改版时候要怎么启动，该怎么思考？阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/momo-redesign
张大湿
落霞与孤鹜
飞翔的企鹅
在路上
表哥
