需求 风格 模型 一、AI 绘图背景与趋势随着互联网行业发展和技术的进步，设计师也有越来越丰富的手段来应对多种类型的产品需求；比如说 3D 渲染、各种自定义的插件已经成为设计师的工作日常，在不断的提高大家的工作效率；包括最近火热的 AI 绘图，也时常出现在设计师的讨论话题当中。AI工具大盘点：2023年，让这20款AI工具帮你更高效地完成工作~2023年，让这20款AI工具帮你更高效的完成工作~大家好，这里是和你们聊设计的花生~2022年是AI技术大发展的一年，我都快记不清为大家推荐多少种AI工具了。阅读文章 > AI 绘图模型令人叹为观止的画作1. 模型的种类与画风目前市面上，AI 绘图在商业设计领域，目前还鲜有人尝试。我们团队通过网上大量的资料和学习，针对 AI 的先有几个工具进行了研究和试验，看看高阶的 AI 模型能否满足我们的诉求。由于市面上存在大量的 AI 绘画工具，每个工具擅长的画风也各有所长；例如 MidJourney；画面注重细节的构建和表达；Stable Diffusion，画风更偏写实；Disco Diffusion；笔触较明显，适合油画风格；包括每一类型里不同的模型也会有不同的效果，例如基于 Stable-Diffusion 开发的 NovelAI Diffusion Models，风格更偏二次元；基于 AI 绘图具有「低成本、批量输出」的特征，而商业化运营需求也带有「日常、高频」的属性，例如日常大促、节日促销活动的 H5 页面、电商 banner 等；所以我们想将 AI 绘图应用在商业化设计流程之中。尝试打破效率边界，利用低投入高产出的方式为团队提效。二、商业设计如何拥抱 AI在进行具体的 AI 绘图实验之前，我们先把商业化运营设计需求分类，以活动类型、周期、对应设计复杂程度，可将其分为为 S、A、B 三个级别。其中 S 级别以专题大促为主，页面以为 banner 和 H5 为代表；A 级别以平台活动为主，同样是 banner 和 H5 需求并存；B 级别为日常促销，以 banner 需求居多；由于以上几类日常运营图的需求频次较高且生命周期不长，在极快的项目节奏中会较多占用设计人力及项目时间；同时因为 AI 绘图模型具有低成本、批量产出的特征，所以我们尝试用 AI 绘图工具来辅助完成日常的运营设计工作。另外值得一提的是，每类模型的擅长风格不同，我们选用的是时下最火热，也是学习资料较多的 MidJourney 来做尝试。三、B 类商业运营设计需求：轻量手段快速达成面对常规运营 banner 需求，之前团队合作流程是由产品、运营同学按固定周期提需求到设计部门，按需求排期，定量投入设计人力逐步交付。既然工作流程上已是最短路径，那么我们尝试把目光聚焦在需求本质上，将 banner 的结构拆散，可以发现绝大部分的 banner 都由这五类元素构成；那么是否能够利用现有成熟的 AI 类技术平台，直接生成商业运营设计 banner 成品（或半成品）呢？我们接下来就尝试一下。1. 对比和尝试我们首先横向对比了国内外智能出图平台的各项能力，以关键功能类型作为衡量指标，得到了一张能力图表；那么横向来看，各平台的能力可以划分为两大类模版绘制、AI 绘制结合模版设计；第一类在线模版绘制；大量模版可以供挑选并调整，支持线上编辑并输出；第二类 AI 绘制；优势是速度极快快、批量出图，但图像的质量没有保障，需结合模版能力一起使用才能质量可靠的设计图；综合效率和结果两方面来考虑，我们选择第二类方法，如上图所示网上有多种平台可供选择，大家可以根据需求自行选择恰当的平台来进行实验。2. 方法总结在具体操作流程上，跟我们常规的设计作图略有不同；大概分为 2 个阶段；首先我们需要选择配图主题类型、活动类型、人群，这决定了图片风格和商品素材的表现；并输入对应的文案标题，即 banner 图的文案显示；随后可得到批量生成的初稿；点击任一初稿，进入线上编辑环节，利用丰富的在线编辑能力对 banner 图做调整，例如图层查找，替换商品素材、装饰素材，更改字体等等；在智能编辑模块中简单处理后即可得到可用的设计图；经过大量实验后发现，这类方式更适合于电商类型的 banner 图；同时在经过对产品、运营同学的简单培训后，大家也可以非常迅速的做到上手并产出 banner 图；这也与我们的预期判断是匹配的；四、A 类商业运营设计需求：AI 辅助生成除了 B 类的日常促销活动外，我们也会经常遇到类似上图的 H5 头图的运营设计，面对这类需求通常需要在探索风格，绘制画面细节上花费较长时间，我们尝试通过 AI 模型辅助出图解决这个难题。1. 工作流程介绍在正式开始作图之前，我们需要对 MidJourney 的能力区间、工作模式建立基本的认知。MidJourney 允许用户以对话的形式，通过以输入描述词的方式，经过 AI 模型运算后得到其返回的图片。2. 利用 MidJourney 垫图能力辅助设计头图；针对 A 类平台活动类运营需求的绘制工作共分为四个步骤，分别是风格定义，垫图描述，调整与输出；首先先通过参考图，明确出我们倾向的风格和特征；第二步我们需要用到「以图生图」，在 discord 中将参考图发给 MidJourney，并结合意向风格，构图和其他特征添加上恰当的描述，可以得到初稿；不断调整图像与描述词，最终逐步接近目标效果；头图生成好之后，搭配上文案的字体设计与装饰元素，可以看到最终的效果如上。利用 AI 模型辅助生图，可以使繁琐的工作量可以得到有效压缩，从而把大家从繁杂的工作中解放出来。五、S 类商业运营设计需求：AI 智能生成除了较为基础的 A 类运营设计需求外，面对专题大促的运营需求需求，其展示周期更长，且对于设计质量要求更高，常常会涉及到 3D 场景的搭建和渲染工作，相对于 A 类需求，S 类需求通常排期时间更长，同时对设计师的能力提出更高要求；那么针对画面设计要求更高阶的运营需求，除依靠设计师个人能力来应对之外，会否有更高效、便捷的办法呢，我们同样可以通过 AI 模型绘制的办法来尝试解决这个问题。1. 工作流程介绍基于前面对于 MidJourney 的基础了解，我们接下来看下利用 MidJourney 辅助输出运营设计图的工作流，分别是风格定义、撰写描述、二次调整、输出 4 个步骤；① 风格定义首先是风格定义，由于 AI 绘图具有高度的随机性和风格化的特质，而运营设计更注重理性的构图版式。所以在正式进入绘图步骤之前，我们需要提前明确画面大致的风格调性，这样才能保证后续 AI 产出的方向不跑偏，并更准确的获取我们想要的图像；我们以电商运营广告中最常见的美妆类别举例，通过观察可以发现，美妆类的图像具有明显的风格化特征，比如居中或对称构图、明亮的环境光等。所以这些特质就将成为我们输入的词汇，同时也是输出筛选步骤里的重要依据。② 撰写描述MidJourney 模型出图有两种模式，最常见的是 text to img 文本生图；以及 img to img 以图生图；文本生图即通过一段文本描述告诉 AI 模型你想要的画面，由它帮你绘制出来；以图生图是通过一份原始图片，配合文本描述，来绘制跟原始图片类似风格但又不尽相同的图片素材；无论哪种方式，都需要明确一个关键的概念「Prompt」，也就是「关键词描述」。Prompt 关键词描述可以理解为与 AI 创作沟通的媒介，我们需要将脑海中构想的画面用恰当的提示词（语句）描述出来，并通过它来缩小 AI 想象的空间，它才能听懂、理解并产出令人满意的画面。另外值得注意的是，相同的描述文本内容，词语的顺序、前后词汇的关系对于内容的产出影响差异也会非常的大。所以关键词描述的写法至关重要；Prompt 的大致写法由几个部分构成，主体部分，环境氛围，构图，风格化，以及其他设定。我们接下来通过 Prompt 描述公式，一步步完成一张美妆运营图的设计。首先是主体内容的描述，通常可以拆解为，存在几个「什么样的」的主体，在做什么动作，并附带了其他的什么动作。例如：There was a pink lipstick and a glass bottle of perfume；可以得到如上的主体内容，香水口红的图像。其次是为主体内容添加场景或环境，例如给定某些地点或物件。比如案例中，我们指定背景花朵、自然植物，以及倒影等词汇。通过观察以上四张图，可以发现模型中「Nature Plants」这个词汇对画面有较大的影响，决定了不同风格的背景以及复杂程度。同时也能发现，尽管只相差了一个描述词，但前后结果仍存在较大的差异，所以大家在调试画面的过程中可以从词汇逐个调整，以尽量减少画面的随机跳变；然后是构图与镜头，比如左侧两张图强调景深，右侧两张图强调了构图位置等；接下来是风格化与参考方向，可以添加上艺术家名字或平台名字，或直接将图像风格写出来；比如说 3D 渲染还是 2D 画风，可以从上图的结果中明显感觉到两者的区别。最后是图像的设定，例如--q 5，代表最高图像质量；同时你也可以通过类似「8k, ultra realistic」这样的词汇来对画质做强调。第二点是画幅，--ar 3:2 表示横纵比为 3 比 2 的横幅图像，--ar 9:16 表示横纵比为 9 比 16 的纵向图像；-- v4 代表最新的第四代计算模型；最终通过以上五个小步骤，我们可以得出一大批风格各异的草图：再通过第一步的风格调性做筛选，可以初步得出不同类型的初稿，以满足不同的品类需求。③ 二次修正，进阶调整当取得满足需求的初稿之后，我们可以使用 MidJourney 的进阶功能，来提升图像质量或对图像画面做调整；以下是几个使用频率最高的的调整功能；首先是通过点击成图下方的 U 按钮，可以放大对应序号的图片的比例，来提高其分辨率；第二种，通过点击图片下方的 V 按钮，可以基于原描述词，生成对应序号图片的变体，画面对比母版，图片的细节会出现随机变化，例如上图的花蕊、香水瓶的外轮廓；第三种是 Light Upscale Redo & Beta Upscale Redo，这两个功能都可以提升画质并细化效果；最后一种也是变体生成方法，值得注意的是，需在「/setting」中开启「Remix mode」功能后，再次点 V 功能，此时可以二次编辑关键词；例如上图就通过「Remix mode」重置了图像的尺寸比例。④ 调整输出将二次修正后的图像，经过设计师轻量化的调整工作，例如修正细节，添加文案后，即可看到最后的效果。以上就是利用 AI 绘图技术辅助生成 S 类商业运营设计图；可以看到其优势是短时间、大批量生成可供选择的风格背景图；同时能配合需求本身，通过 AI 模型的变体加二次描述词编辑，来满足我们的个性化要求。结语以上则是本文的全部内容，如果你也想通过 AI 绘图的形式来辅助提高自己的工作效率，以下几点值得仔细阅读，首先 MidJourney 前期有免费的体验额度，当额度用完后需要付费使用。其次免费用户生成的作品不能商用，只有付费用户才拥有该图片的所有权。由于 AI 绘图的版权政策时常存在变动，所以也请大家关注 Midjourney 官方信息，以免带来困扰。随着 AI 模型能力的飞速迭代升级，现有的短板能力也会不断补齐，因此我们可以相信在不远的将来，设计师利用 AI 模型来开脑洞并辅助出图是趋势所向，但并不是说我们需要完全依赖 AI，因为设计本身是理性而浪漫的工作，仅靠随机性做设计是完全不可取且不靠谱的。更合适的思路应该是，设计师首先定义好规则与框架，从 AI 模型提供的成百上千个结果中寻找到最匹配我们诉求的结果，从而辅助我们更快更好的达成目标。另外面对日新月异的的智能工具，我们应该保持终生学习的心态，做好时刻接受新事物的挑战，才能在越来越激烈的竞争中立于不败之地。欢迎关注作者微信公众号：「腾讯ISUX」本篇来源：优设网原文地址：https://www.uisdc.com/aigc-design
用户 需求 产品 一、如何看待被小需求覆盖的工作日常？方法有两种，第一就是对日常工作情况分析，第二就是找出产生问题的原因一个设计师一般同时负责多个项目，多个产品老师同事提了不计其数的小需求，有的需求太小，一点挑战都没有，没有价值，做了对自己没有提升，许多设计师觉得自己做小项目没有价值，实则上是设计师自己的视角局限导致看问题比较片面，没有认识到自己实际的价值。每个设计师都觉得没有空间展现自己无限创造力、才华和艺术品味，感觉这一身的艺术细菌都被浪费了我们常常认为我们是固定的，世界是可塑的，但大多数情况下，世界是固定的，我们是可塑的。所以我们应该改变心态，认真对待小需求也能够提升个人能力，展现创造力和逻辑性。此外，调整工作方式，从解决问题的本质出发，认真分析问题，想清楚如何解决，不再随意思考随性设计从而产生随机结果。工作需求很琐碎，如何制作完整吸睛的作品集？前言我们今天讲一下如何整理自己的作品集，好多人呢辛辛苦苦工作一年了，完了之后发现没有什么拿的出手的东西，今天做一点需求，明天做一点需求，做的东西零零散散的，发现没有什么可提取出来的，最后到总结的时候抓头挠腮的。阅读文章 > 二、怎么解决这种情况，有哪些门道？我们是不是经常遇到这样：但不管是什么需求，都需要设计师明确业务流程，在了解业务基础上才能够梳理清晰思路。1. 分析目标用户，了解用户人群当我们拿到一个需求的时候，我们需要对业务有所基本的认知，以买保险为例，完成投保的步骤分为以上四步，用户首先进入到保险首页，浏览保险列表页面，点击查看保险详情，最后决定购买保险完成投保。用户人群：目标用户人群中，男性用户占比较高，且大部分处于婚育年纪的家庭车主，上有老下有小，生活的重担和家庭责任使他们具有较高的风险意识，注重品牌效应，追求品质，但大部分并不了解自身需求。现存问题：不知道应该买哪种保险？性价比高吗？适合全家购买吗？理赔方便吗？是官方平台吗？有哪些保障权益？2. 横向拓展功能矩阵，竖向梳理全流程我们还需要对用户行为有个基本面的了解。投保四个步骤分别对应什么样的用户行为？根据用户行为去做出什么样的设计决策呢？这个时候就需要设计师们做进一步的思考了。横向拓展思考，梳理产品框架。引入场景建立基本认知。提供辅助决策，产生价值认同。帮助用户做决策驱动，激励转化。竖向梳理全流程。用户使用流程包括了点击买保险入口、进入浏览保险列表、查看产品详情页、用户投保完成。而影响用户行为的因素有三点：提供可持续被感知的动机，吸引潜在的用户，利用保险应用场景引入到用户生活当中，给予用户基础认知将复杂的保险内容简洁化，降低用户认知门槛，让用户清晰了解到产品是否适合自己当用户被动机吸引进入到投保页面后，驱动用户做出决策需要建立在信任基础上，用户首次接触新产品时会选择熟悉的品牌，结合信用背书，让二者产生连接，增强产品可信度此外，保险产品具有一定的周期性的，我们不仅需要考虑用户行为上的痛点，还要思考产品周期对用户决策的影响。3. 了解覆盖保险周期用户所处的保险阶段分为：新手期、决定期、犹豫期、复购期，处于不同保险阶段的用户对于保险内容有不同的诉求，需要在框架和内容上去适配他自身的认知和意愿。与市场营销、产品运营策略相结合相关案例分析。三、实际案例分析1. 在上个版本的续保详情页存在了几个问题：当前详情页无法得知购买的是哪个保险，保险的特点和客户群体不清晰用户不清楚什么时候到了续保阶段，以及为什么会欠费信息层级不突出，文案信息冗杂，增加了用户了解产品内容的压力续保详情页和其他页面视觉差异不大，引起用户视觉疲劳根据以上的问题，可以给出对应的优化点：突出保险本身的优势，强调已保障天数明确费用计算规则，确保费用清晰明了加强保单与缴费明细的内容主次层级对比，强化产品信息统一保险页面设计风格相关展示：再来看个例子，下面是个保险复购期间续保 H5 优化。在上个版本存在的问题是：用户无法得知距离保险失效还剩多少天。产品升级前后对比弱，升级的内容无法有效并且直观地感知。设计风格上和投保详情页不一致，无法从品牌上传递信任感。根据以上问题，可以给出对应的优化点：明确失效保险名称以及天数的关键信息强化升级前后的对比，从内容信息上强化视觉展示这个页面要跳转到详情页，所以没必要展示全部内容，信息在一屏内展示完成视觉上统一设计风格同样，弹窗也有可以优化的地方突出保险额度和关键的保险信息增加已有多人完善信息，让用户产生从众心理把完善内容包装成用户福利，只有幸运用户才可以享有其他页面需要保持统一的设计风格四、这些对我们有什么启示呢？产品工作流程：产品设计流程：无论是接到一个大的项目还是日常小需求的维护，设计师都应该多去从业务流程去思考产品的痛点，找到业务流程中每个步骤间设计目标，对工作不同阶段要有清晰的认识。运用设计方法了解我们的用户、了解产品核心诉求。欢迎关注作者微信公众号：「产险设计事务所 PIDO」本篇来源：优设网原文地址：https://www.uisdc.com/demand-analysis-2
需求 项目 原型 随着羊群人数的不断增加，使得大部分同事改成居家办公和线上会议。线上会议的特点不用提前抢会议，不用担心会议时长，顶着 40℃的高烧，听者需求评审会，也不知道烧了多久，睡了多久，会议开了多久....需求评审会经常被大家吐槽时间久，最终问题得不到解决似乎是无法破解的问题。我记录了最近几次 PM 组织的评审会过程，发现一些问题，并想到一些可以改变的方法。需求评审干货：需求太多怎么评审？来看京东内部的实战案例！面对功能优化类项目，如何做好需求分析？阅读文章 > 问题 1：开场一句话背景和模糊的收益介绍背景和收益必不可少，这是团队成员在初期达成目标一致的必要过程，并且通过说明相关成员能够认同该项目的价值和意义，通常一句话轻描淡写是不够的。建议：充分做好会前功课和线下沟通，保证会上快速达成一致老项目要介绍上一个版本历史数据分析结论或者用户反馈问题分析结论。新项要使用SWOT等分析方法，明确自身的竞争优势，市场规模等核心问题。竞品分析讲结论。不要挨个讲竞品，也不要讲字号和颜色等细枝末节问题（可以在需求文档中给予参考建议），注重战略层面和功能层面的差异介绍，以及那些适合自身与竞品之间的差异。本次要解决的问题，也就是具体我们要做什么。不需要复杂的论述，简单列出本次需求点，一目了然。清晰表述项目价值。讲明白本次优化能给项目带来多大的价值，以及是如何推导出来的，让团队成员信服。价值一定是可以衡量的，我们常听到项目的价值是提升用户体验，但实际既没有用户满意度等用户指标，也没有具体收益等业务指标，那这就是不可衡量，全靠感觉，项目后期对于方案的讨论分歧点会很多。不要一开始就甩锅给老板。很多PM在开会时功课做得不够，被问到一些无法回答的问题时直接说这是老板让做的，如果觉得需求有问题可以去找老板，这样的结果大家以后对于项目态度都会变成应付了事，PM自己的工作后续也很难推进。问题 2：上来就讲原型，陷入细节纷争PM 喜欢画原型喜欢讲原型应该是不争的事实，还有一些 PM 对原型的精美度要求还很高，于是需求确认前就找交互设计师按照自己设想完成交互设计，很多不完善、不合理的地方也很强硬的要按照自己的来。需求评审会上来讲原型很容易让团队成员陷入界面的细节争论不休，开发又会追问每个逻辑，评审会你一句我一句就乱套了，同这时通常设计也会与开发一边，表示出不满。建议：清晰且详细文字的描述产品逻辑及字段清晰表述产品中所有的字段、数据格式以及相应的逻辑。让开发能看懂所有功能逻辑、操作逻辑、展示逻辑，设计能看懂产品需要用户如何操作以及限制条件，通过文字能明白整体需求逻辑关系。尽量使用文字描述。我们发现当图和文字同时出现在文档中时，设计师和前端更偏向于看图，后端会细看文字描述的逻辑，这样到了打法阶段容易形成分歧，导致新的问题产生。产品画的原型会影响设计师的思考，造成设计师被带跑偏，甚至一些强硬的PM要求设计师按照原型来，这样一来设计师不想给自己找不痛快，就按照美工的标准应付完工，并没有发挥真正的价值。问题 3：需求评审开成技术评审很多时候在评审会上，开发人员会从能不能实现聊到怎么实现，然后聊到各服务端如何来配合，一聊起来就没完没了，线上会还可能随时就拉个新成员进入参与讨论，需求背景又要被重复。此时的需求还没有定论，占用大量会议时间讨论技术实现明显是不合适的，浪费大家宝贵的时间。建议：做好会议把控，控制问题讨论边界PM在会议中要起到把控的作用，会上不讨论技术实现方案，只讨论需求是否合理，技术可否实现，如果当时不能确定能否实现的，需要记录todo在规定的时间内反馈。对于一些不确定的技术问题，或可能存在争议的难点，最好在开会前就能和技术负责人了解清楚技术背景，做好功课，防止在评审会上被牵着鼻子走。问题 4：跑题跑题通常是不知不觉的，甚至全体参会人都享受其中，越聊越嗨，忘记了开会真正的目的。印象比较深的是一个方案要主管确认，主管从这个方案聊到了另一个项目，开发顺着另个项目聊到了项目进度和遇到的问题。整个评审会成为了另一个项目的汇报会，到最后也没确认当前方案。建议：明确会议目标，时刻关注会议方向PM会前要和主管确认好方案，以保证内部一致性，会上主管只要回复确认没问题即可。放下面子敢于说话。很多时候PM不太好意思打断大家的对话，这样就不能把跑题扼杀在摇篮里。总结一下，就是立足本职做好自己职责范围内的工作，承担好项目角色。如何组织一场高效的设计评审会？高手总结了这份模板！编者按：设计评审的目的和意义是什么？阅读文章 > 如何顺利通过设计评审会？我总结了3个注意事项！编者按：如何通过设计评审？阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/review-meeting-efficiency
组件 结构 需求 什么是设计中的解构思维，解构思维怎么产生价值？本章结合 B 端场景进行了应用解读，通过对组件深入的解构理解以及对业务需求的解构设计，示意解构思维如何来解决 B 端业务需求和组件运用的问题，反映了解构思维的运作模型与价值体现。往期干货：遇到设计瓶颈无法脱身？五大章节帮你正确应对！前言：每个设计师都会遇到瓶颈，至于瓶颈期挣扎了多久各有不同。阅读文章 > 一、设计中的解构思维（解释解构）1. 广义的解构思维是什么“解构”一词富有哲学色彩，早期的出现是哲学家雅克·德里达不满西方几千年来的传统哲学思想，而提出的一种批判方法，是指对一切存在事物或现象的原因及本源研究，得出的稳定结构及其中心进行消解，每一次解构都表现为结构的中断、分裂或解体，但是每一次解构的结果又都是产生新的结构。解构具有消除二元对立、打破固有传统、去中心化、多元开放、包容差异等特点，对当下世界的多元化包容性都带来不小影响。而其思想内涵也在不同行业中生根发芽，在服装、建筑、平面、影视行业中处处可见解构，以此为根源，20 世纪 80 年代“解构主义”作为一种设计风格的探索开始兴起，解构主义用分解的观念，强调打碎，叠加，重组，重视个体，不见本身，反对中心化或总体统一而带来的支离破碎和不确定性（例如肤色阶级的种族歧视、早期重男轻女封建思想等）。如何理解呢？“解”有分解、拆解、理解的意思，而“构”具有结构、构造的意思，字面意思就是对事物的内容结构进行剖析。通常解构被认为是对传统认知里的结构进行质疑和破碎重组，并建立具有新意义的结构。例如你一天放了 7 个不同声音的屁，通过解构，我听到的不再是屁，而是音符，经过谱曲，我成就了一首。好的翻译也可以视为解构，这个过程就是译者对本质含义进行理解并使用新的语言结构释义，其表达的本质没有变，却拥有了更为生动明了的译文。2. 体验设计中的解构思维一般结构形成表象，表象反应本质，但需求的构成是由其他本质推动的，这些本质既能形成 A 结构，就必定能造就 B 结构，所以解构主义不认为结构与表象能代表本质，设计中解构思维可以帮助我们跳出传统的条条框框，就好像在说时代变了，你那套不行了。体验设计的范畴中，我将解构思维简单概括为：不停留于结构表象，敢于质疑、深入本质，再创结构，是一种打破设计相关秩序然后再创造更为合理秩序的思维主义，是对本质的深入与多元化的理解，而体验设计中的本质常常是以需求作为出发点，以用户和场景作为合理性的准则，以解构出具有体验或商业价值的方案。一把舒适的椅子如何设计，从人体工学椅子到懒人沙发，依旧是一个不错的解构案例，原来舒适的椅子可以这样。3. 解构与拆解、原子理论的区别拆解是对某个事物按照一定逻辑或结构进行分解拆除，目的是获取更全面或更深入的信息与理解，从而加深对本质的理解，拆解并不影响事物本身的结构或中心，而解构主义则是出于对结构或中心的质疑展开的，并试图找到新的侧重点或视角来理解本质，目的就是建立具有意义的新结构，同时在建构的过程中，还会用到更替、融入、结合、间离等手法，而并非是线性的拆解组合，在体验设计的应用中，我认为解构有益于深入研究，以及跳脱竞品或传统结构设计的思维局限。原子理论在 B 端组件系统中有深入的应用，像搭积木一样，重心是找到可以复用的最小单元，然后利用这些单元组装出更复杂更庞大的结构体，并且对这些单元的资源进行重复性利用，以减少生产过程中带来的资产冗余、不一致、低效率等核心问题。侧重点是交互层与功能逻辑，是一种工具化、模块化的思维，主要是业务解构后进行 B 端交互页面搭建的工具。但是在传统 B 端业务设计的背景下，解构思维可以配合业务情况对组件传统的“组织”及以上的结构进行破坏重组，以诞生新的结构并更好契合业务。二、再说说 B 端组件系统（解构对象）1. 组件系统的诞生背景B 端向来是以业务操作为主，而在繁琐的操作过程中，尽管界面或场景不同，但是有很多操作行为或操作内容具备较高的一致性，为了减少对应资源的反复设计与开发带来的时间浪费与资源冗余，这些对应常见的交互组件被系统化了，同时在不断探索更基础或高频率通用的组件单元，以便后续的研发设计中可以随时调用，于是组件系统诞生了。2. 组件系统的核心价值从内部研发视角来看，已经提到的减少资源冗余与效率问题便是核心价值了，从界面设计与品牌调性来看，使得产品样貌与操作更为统一规范，便于资源管控。而从外部视角来看，一套开源的设计系统还能赋予生态上的改变，一套基础完善的 B 端组件系统可以支撑内部庞大的业务的同时，也可以赋予友商或帮助其他小微企业研发中后台，对于业务生态、研发生态都有好处，收获口碑的同时，是一种文化价值传递，也是影响力的渗透。3. 什么时候搭 B 端组件系统从技术难度工作量以及研发周期来看，显然不能短期获取回报，往往只能在业务生态需求量大、涉猎业务复杂或是发展迅速才有较好的价值体现，当然了不差钱为行业生态做贡献也可以啊，尽管如此但也不是说不建议设计组件系统，具体也要看研发背景与组件系统搭建程度；① 研发背景参考要素大部分中小型企业，业务不是特别复杂，研发资源很有限，那就直接考虑开源组件系统好了，用现成的真的便捷太多，并且也不会涉及到到数据安全的问题。如果要搭建组件系统，那就需要考虑自身研发资源(时间、人力、成本)硬不硬，然后就是业务复杂程度是否大多开源的不能轻易满足，这两点很重要。② 组件搭建程度情况第一层实现设计产出加工件：借助 Sketch、Figma 等主流 UI 设计软件搭建界面常用的组件库，用于内部设计资源流通，快速搭建 UI 界面，保证界面组件统一性和效率保障，搭建起步不要考虑全面，先从最基础最常用的开始搭建。第二层沉淀对应代码库：设计师有了可复用的设计组件还是比较初步的，重要的是研发工程师对可复用的组件开始沉淀，并建立资源库，研发过程中可能会伴随业务需求一起完善，对于已研发的组件可以同步记载完善交互，然后规划版本逐步完善。第三层设计代码一体化：设计与研发的组件完成版本一致，实现组件从视觉效果到交互效果反馈完整，状态齐全，引入即用，实现真正意义上的组件系统。③ 进行系统二开维护基于业务情况与开源组件系统进行二次开发，来建立沉淀自家的组件系统，如果这么做首先考虑的还是研发背景情况，进行二开可以节省不少时间，并且可以有更多差异化定制化的空间，需要注意的是目标二开系统的灵活性、扩展性等核心问题。三、用解构思维深度理解组件（开始表演）1. 从表象到数据背后我们通过 B 端中后台的表象开始解构，映入眼帘的往往是各种功能的导航、操作入口、信息反馈，很清晰很明了，各种操作都被组件结构所包揽并示意。似乎已经看到了组件的作用，但又好像看见的还不够，我们再次深入，组件的背后是便于操作，而操作的背后是什么，似乎很接近了，我们结合界面交互的构成结构换个视角看问题，如果没有这些组件，任务还能进行吗？显然具备代码能力是可以的（毕竟有些开发天天就是对数据 CRUD，不理解就问研发 [手动狗头]），那么现在看来组件的作用就清晰明了呢，“组件是提供间接的代码操作工具，便于我们通过界面交互来控制代码数据的交互，帮助减少操作的门槛与理解成本”，我把这理解为组件的底层价值。2. 解构组件的功能逻辑组件本身注重的是行为逻辑，即交互逻辑，非业务逻辑，是业务逻辑构件的工具。从交互视角切入，基本的交互原则是组件本身必备的，要易于理解、易于操作、及时反馈，而组件运作的本质逻辑我理解为对数据的约束、反馈与数据交互，什么意思呢？你听我说人话：① 约束作用看看以下图片中的举例，直观感受一下组件约束能力的价值。第一组是没有注重组件约束功能的，而第二组是采用了合适的组件约束能力后的效果；通过以上对比，不难看出输入输出的信息都得以约束和规范化，从数据、从业务、从浏览都产生了极佳的效果。而在不同场景下这些约束会有差异，为的是更好满足业务需求，因此就诞生了具有不同约束能力的各种组件，这里再枚举一些例子；② 反馈作用反馈即通过数据加工产生更容易理解的表象，以及在操作后的提示反馈。反馈可以告诉我们有什么是什么、帮助理解这些信息有多少类目、理解这些信息有什么特征、理解这些信息量情况、理解此处有何操作等，尽管相同作用的反馈可能有不一样的样式，但这并不影响统一性，差异化只是满足不同场景或不同容器特征而已，例如会话窗口通知与文本 tips 同样是信息反馈，那么显然会话窗口更加重视信息接收程度，出现场景更加正式醒目；而这整个过程的反馈基本上围绕“映射”原理进行，从代码层获取信息框架再通过界面释义，就像是一段巧妙而精准的翻译一般，业务是否吃透、组件用的是否得当、体验是否良好，都要看这“映射”的功夫下足了没有；③ 数据交互具备数据交互能力，即可以通过组件对界面上的数据发生变化以达成任务操作的目的，说人话就是可以直接帮助我们控制界面元素和数据增删改查，例如搜索就是利用组件输入查询的关键词，并通过按钮或键盘发起数据索引，最终获取反馈信息帮助我们完成任务。B 端数据交互的类型相对是比较简单的，主要包含了富文本、图片、动图、音频、视频为主，复杂的地方在于特殊格式的兼容和深入编辑的需要，因为要有指定的解码器支持文件的显示以及操作存储，这也就意味着可能需要制作新的配套组件，或是引入其他的组件进行二开，例如代码编辑器大多 B 端公开系统是没有提供的，这就需要新开发或新引入。3. B 端组件的同质化现象在第一台携带操作界面的计算机诞生时组件就有了，时过境迁，计算机界面的交互组件也配套设备输入输出的特征逐步定型，对比当下主流的开源 B 端组件库，不难发现基础的组件只存在细微交互动画与视觉差异，功能逻辑基本一致，这是源于多年来计算机的快速发展沉淀下来的人机交互认知与共识，一切看似有标准但又没有绝对的标准，约定成俗一般。尽管 B 端组件还有一定个性化或差异化的空间，但大多也只是视觉表现层的一些调整，并且面对市场大众化的组件认知与趋势，很难做出别致的差异化了；也许在 B 端组件发展的道路上，只会同质化越来越严重吧，没有新型业务需求驱动，可能现有的基本组件就定型了，而市场上的组件系统也会被广泛的应用与习惯，当广大用户养成了认知与操作习惯后，就更没办法对组件做出差异化了，这会违背大多用户的认知与操作习惯，所以对组件本身进行解构创新的价值不大，解构的重点是功能用途的深入理解与应用。4. 组件对设计师的价值B 端重业务、重效率、少个性，而 B 端组件同质化正在加剧，那么设计师也就没有必要去过分考虑组件的差异化或个性化，聚焦新型业务的交互组件或是业务需求设计才应该是众望所归，而组件系统的概念与组件的理解应用也应该成为设计师的标配能力，“组件”一定是 B 端设计师的重要价值，却一定不能是核心价值，所以了也不要老是说 B 端的设计师们就是在搬组件了，这墙砌的不好吗？四、解构思维让组件得心应手1. 用好组件，先从需求解构开始不同组件的功能用途首先要理解，至于使用什么组件取决于需求的数据交互以及约束条件和反馈需要，而这些条件均来源于需求，这个过程中，要发挥好解构思维的精髓，那么第一件事就是说“这是个伪需求”，一定不是思考如何执行需求，而是从质疑需求开始，接着就会开始对需求拆解厘清，当需求的结构被你摸清时，你就能感知到需求是否合理，是否有更优方案。然后就可以跟需求方说说你的观点，我早些时候也是得益于这种思维模式，能够加深对需求的理解，同时跟产品有来有往，对方也更愿意主动来探讨，当然呢，需求方是不是傻*心里也就更有数了。要开始需求解构呢，就要先清晰需求的结构，一般来讲即构成需求的背景、场景、人群、流程、目标、模式等问题，然后拆解分析找到关键因素攻破。当我们完成需求解构后，就需要进一步通过对需求的流程、信息、关键词进行提炼，以匹配需求实现所需要的组件，匹配的本质是依据信息特征和功能要求，即信息的图文视频音频类型、格式兼容属性、数量单位、映射反馈、逻辑含义、约束条件等关键词，整个解构过程可以用以下这个模型来概括；案例一：组件区块解构案例中，在这套传统数据表格里，我们需要添加部分微型数据图表信息，提供给部分角色查看和比较前后行的数据差异，那么是你会如何进行解决呢？传统选手使用添加“查看图表”操作，通过点击后利用抽屉或弹窗承载图表数据；并在图表显示面板上补充了切换上下条数据用作比较；解构选手把传统表格给改了，采用了可扩展表格，并将数据图表以卡片的形式嵌入了表格，通过点击展开查询图表数据，可以随时展开和收起数据的图表信息。两者间有何差异：传统往往是做加法，解构则是对现有结构做改变。这个过程中解构的是表格扩展数据的各种可能性，以及需求本身的目的是什么，而结合起来找到一种新的表格方式来实现需求。尽管后者方案表格代码需要做更多调整，但是优势显而易见的，在保障能够实现的情况下，约束了表格横向的宽度延伸、展开数据支持二次加载减少了请求并发、支持多行数据展开图表对比，尽可能减少了操作步骤。案例二：解构树状列表需求需求简述；要做一个树状结构的表格，用于呈现控制节点的基本信息和关系示意，主要是提供给节点管理角色使用，构成的主要信息框架如下：传统设计中，提供设计的关键信息与关键词基本已取得，我们可以根据需求开始构建页面了，第一步搭建支持展开收起的表格，用于反馈节点的层级关系，表格 Title 主要由节点名称、描述、Owner 名称、工号、部门抬头、分布域、节点开关构成即可，开关进行操作时进行二次确认弹窗确认即可，大致原型图如下：解构思维怎么设计呢？第一步质疑结构：为什么是树状，为什么是表格，这个结构主要包含了什么，重点是什么？表象反映出了什么样的本质？这样带来了什么问题？第二步破碎拆解：带着问题对结构拆解，对构成的各方面深入理解，找出新的发力点以及更全面的信息。——需求结构特征：树状结构、信息显示、开关操作——需求本身的问题：信息优先级、节点数量规模、默认显示节点、是否支持过滤、关联数据或功能情况——需求结构化：需求对应的场景、参与和使用的角色、服务的作用影响、底层逻辑与流程、交互的信息框架当然了，需求结构化的方法并不是固定的，可以如上将构成的因素厘清，也可以通过服务蓝图或运作模式来将不同阶段进行拆分和理解。——拆解结构深入理解：对结构构成的多方面进行思考，找到关键因素或核心价值，并重新审视结构，来帮助构思新的需求方案。以上需求通过对需求服务对象和需求方进一步沟通，了解到节点管理者更关注树状结构的关系、节点的名称、描述、分布域信息，然后才是负责人跟开关操作，并且节点分为三大类型，有时候会先注意是什么类型，然后办公时会根据名称路径去找想要指定操作的节点，其实节点数量一般在10-30个之间，并且一般都是从第二级开始操作，后续数量上也不会怎么变化，节点与节点之间的互通则由开关直接影响...第三步重塑结构：经过解构我们将构成聚焦放在节点管理员身上，并获取了更为全面和有价值的信息，接着我们进入建构阶段，思考如何更好的满足节点的层级与流通性，当前现有的数据支撑和遗漏可用数据有哪些，数据的显示并不是难点，我们开始思考哪些组件区块具备层级关系与流通状态示意能力，在呈现时，如何更好服务节点管理者的使用场景，带着这些问题我们开始重新对需求进行设计，以及匹配合适的组件搭建原型。第四步匹配资源：放弃了树状表格，但是延续了树状结构特征，对于节点的类型重新补充了进来，而信息也重新调整了优先级，使得整个需求结构更加完善合理，原型阶段，我们通过拓扑结构来取代了表格，支持子集展开收起，并且以卡片来承载节点信息与操作，节点之间的卡片也用不同颜色的线条示意流通性，在有限节点中，也更好的突出了个体，默认也直接显示完所有二级节点，大致原型图如下：案例小结对于解构思维应当施加一定的灵活性，要识别是否具有深入和颠覆的解构价值，没必要过度的解构，解构以后的建构也很具有挑战性，你要思考优化结构赋予价值。另外有时候经过解构思考后，结论与原本的需求结构差异不大，甚至你也认同原本的方案，这并不冲突，这说明原本的设计者也是严谨或靠谱的，并且深入理解的过程是宝贵的，在体验设计的范畴，解构思维应该是为我们提供别样的视角，帮助我们深入本质解决问题，并不是为了生成新的结构而解构。五、解构思维对 B 端的价值1. 突破对传统结构的思维局限产品设计中，常常开玩笑说就是互相抄来抄去，要是竞品毙光了，都不知道接下去怎么设计了，很多时候我们看问题常常凭借经验或直觉看表象，未能深入或大胆的批判人家的不好，对权威提出质疑，而解构思维正好反其道行之，以使得我们对竞品分析或用户研究后不会拿出一个显而易见的结果，却没有深入的结论做业务抓手。解构思维可以去中心化去权威化，帮助我们深入并注意到构成个体的价值，以为业务带来更多的可能性。2. 业务优化或改版的得力助手看起来没什么问题，或是对方案没有底气，那就试着解构一下，先把页面里的业务拆出来，在把业务之间的关系和逻辑才拆出来，当你解的足够清晰明了时，面对不同场景或角色特征，需求优化的方向就开始清晰了，解构思维能让你变得游刃有余，是业务分析和理解的一把好手。3. 深度理解组件原理与应用以前总是问这个组件怎么用，其实应用解构思维后，才发现原来是自己太懒了，没有进一步的对组件进行思考和理解，其实运用解构思维想想人家组件为什么这么做、还能怎么做、什么场景下用，马上就通透了，并且对于组件的模块化改造也是有着相当的作用。六、结语早些时候，我以为的解构，就是对某个结构进行拆解加深理解，而之后又意识到还要用一些颠倒、反转、重组、叠加等一些列手段进行建构，目的是形成一个不同于以往的结构，再后来才发现解构也没那么简单，解构主义更注重的是对传统观念中的结构发起的质疑，从而引发新的深思，将本质不再停留在结构与表象本身，并试图找到新的或其他合理的点进行重新建构，最终带来不一样的结构或价值体现，这种例子也在当今多元化的世界处处可见，稍加灵活的应用，解构也会是不错的工具。当然了解构已经在各行各业开出了不一样的花，怎么理解怎么运用会有所不同，这里主要也是分享了在体验设计领域中我对解构思维的理解与运用，算是抛砖引玉吧，你有看见什么好例子吗？评论里告诉我，我们一起解构解构本篇来源：优设网原文地址：https://www.uisdc.com/deconstruct
需求 用户 流程 经常在设计群潜水的时候，都会碰到有小伙伴问相同的问题：换了一家公司，如何融入团队开展工作？刚好最近自己也是换了一个平台搬砖，所以想结合这段时间自身的经历，来跟大家聊聊，作为交互设计师，我是如何快速进入业务状态开展工作的。相关干货：B端设计师如何体系化了解业务？4个步骤快速搞定！前言接触 B 端设计的小伙伴会发现，很多业务具有角色多，业务场景复杂，功能链路长等特点，所以在工作中会经常遇到以下几个问题： 突然被调配到新业务，拿到一个不熟悉的业务或者新产品，不知如何开展工作？阅读文章 > 为什么强调“快速”，是因为对于一个职场老鸟来说，公司招你的目的不是花时间培养你，而是来救火的。如果不能快速进入业务状态，就会招来周围同事的质疑，尤其是对于像交互这种“可有可无”的职位而言。所以，如何在新的环境中快速融入，快速产出就显得尤其重要了。一、了解团队当前协作流程与痛点由于公司之前没有交互设计师的岗位，所以当我进入到团队中时，首先主动了解的是在没有这个角色之前，团队是如何运转的，以及遇到了哪些阻力。这样我才能找到当前团队协作的问题，并通过这个岗位的优势去解决，从而凸显自身的价值。在通过与产品、技术、设计等部门同事的简单沟通后，归纳出如下两个问题：1. 产品交互流程靠口述，理解偏差较大在跟旁边的技术同事沟通得知，由于之前没有清晰的交互流程产出，只有产品出的简单的线框图，导致大部分交互流程靠开发想象，再加上产品的线框图是通过生成 axure 云端链接的形式存放，经常会出现打不开、找不到的情况。产品就通过口述的方式进行流程的宣讲，从而导致的结果就是开发出来的与产品的预期偏差太大。而针对这些现状，结合之前的工作经验提出了两点优化建议与方向。① 统一团队协作工具与项目文件当前技术同事在开发的时候，需要不断切换链接去看对应的产品需求、交互流程、设计稿，不仅繁琐，经常也会出现由于项目文件命名不同对应不上的情况。所以在我的建议下，开始使用同一个软件来承载这些文档，同时将相同项目的文件采用统一的命名规则，从而提升技术同事查找相关文档的效率。② 规范交互文档的内容输出之前交互流程的产出由产品兼任，由于没有那么多时间考虑页面细节，就会导致部分页面流程的缺失。所以在我加入以后，针对当前团队的特点，优化了之前的交互文档的结构，同时与产品协同产出，将业务规则与交互说明落到对应的页面上来，进一步提升技术同事的开发效率与准确度。2. 需求经常变更，设计与开发返工率高需求变更往往是导致项目不能按时交付的主要因素，在与产品经理沟通中得知，导致这个问题的主要因素是开发出的页面流程与前期需求沟通的时候不一致，所以如何确保需求准确的传达给技术跟设计同事，对此我将整个链路拆解出了四个阶段，即：需求评审、交互评审、页面与流程宣讲、实现跟进。① 需求评审需求评审是之前团队已有的流程，但是之前评审需求时，每个角色都有自己的想法，由于没有将需求做页面化的呈现，导致直接将不确定的需求给到设计以后，设计开发出的需求不符合前期规划的预期效果，就会带来返工。而在我加入以后，在进行需求评审的同时，我会主动去归纳此次需求范围层的内容，并快速生成可视化的效果，展现产品与功能雏形。这样做的目的是能让各个角色根据当前的信息架构来判断是否是大家达成一致的效果与流程，减少因需求不明确而带来的返工。② 交互评审交互评审，是我加入以后主动去推动的流程。一般是在产出整个功能所有页面的信息架构跟流程后进行，主要目的是拉齐需求方看看整个功能用户的操作链路是否满足前期讨论的需求。而且在这个阶段也可以避免一些因交互形式的改动而带来的开发工作量的增加，从而导致项目延期的风险。③ 页面与流程宣讲页面与流程宣讲，是在我补充整个页面与流程的交互文档后进行，主要目的是面向负责此次项目的设计与开发同事，通过同步此次方案的背景、迭代的内容、用户交互的页面流程与规则、需要获得哪些数据、设计注意事项等内容，来减少开发设计过程中因前期功能不熟悉而带来的理解偏差。④ 实现跟进实现跟进，主要跟进设计阶段与开发阶段。设计中，要时刻看看设计进度以及是否很好的表达出了原型中的信息层级，而开发阶段主要是对于一些极端情况做出解释与定义，防止模凌两可的状态导致流程的不通畅，同时在测试结束后还要做一轮验收，主要查看功能是否完善，极端情况是否考虑周全等。二、主动熟悉业务，框定后续工作方向当我加入到团队后，就立马接手了需求,其实这么迅速的投入到工实际项目中是不太利于方案的产出的，因为在不了解业务背景的情况下，很容易陷入“我以为”的状态。所以在做这个紧急任务的同时，我也在利用有限的时间去完成如下三件事情，帮助自己更好的开展后续的工作。① 了解产品商业模式交互设计师不是一味的站在用户的角度去考虑问题的。产品体验设计的再好，如果不能带来公司效益的增长，也会无济于事的。所以主动了解公司的产品商业模式，不仅能很好的在产出方案的时候平衡商业与体验，同时也能在主动推进产品体验优化的时候更好的选择合适的方向。② 体验产品流程体验产品流程是一种很好的方式，来帮助自己快速熟悉产品。通过对每个模块，每个流程的拆解，不仅能知道该功能设计的目的，同时也能知道当前的流程存在哪些问题以及可优化的方向，为自己建立整个产品的功能架构图提供了很好的帮助。③ 获取产品节奏产品在不同的阶段，需要解决的问题都有所不同，获取产品的节奏能更好的明确后续的工作重心与方向。举个例子：当我加入到团队以后，在跟上一级的沟通中了解到了现在产品的商业模式，于是我就开始针对产品几个能影响到用户增长与订单转化的流程着重体验，找出优化的方向，比如注册登录流程。因为不同于常规 C 端的注册登录，当前产品需要用户注册后开通会员才能正常查看内容，该链路的体验好坏决定了产品的付费用户数量，所以我觉得对于产品是至关重要的。但是在我进一步跟上一级的沟通中得知，产品当前的存量用户还可以，而且大部分的新用户并非通过 app 主动注册的形式产生，所以产品的注册登录流程并不是现在最主要的，而是在于结合产品运营，如何让现在的存量用户活跃起来。所以在获得了产品的节奏后，我重新调整了对产品的体验优化的方向。三、切换视角，站在目标用户的角度做设计切换视角对于交互设计师而言尤为重要，因为这个岗位的价值就是为用户设计合适的操作路径，从而达到“降本增效”的目的。在产出方案的过程中，越多的站在用户的视角，意味着产出的交互流程越接近用户的使用预期。在我加入团队没多久，就接到了一个内部 OA 系统的交互需求，该需求产品经理已经在前期做了简单的功能设计，但是由于没有设计用户的操作路径，所以需要我这边来进行补充与协助。我就以这个为例，来拆解一下在做交互需求时，我是如何站在用户的角度去思考与设计的。公司的OA 系统主要是用来维护核心用户，根据用户的属性不同做分层运营。新需求是需要增加一个“记需求”的功能，用来记录用户的诉求，从而方便后续的跟进。已有的线框图如下：接到这个需求后，我并没有急于去做后面的交互流程补充，而是通过跟目标用户的交流，了解了他们使用这个功能的场景，再切换自己的视角，试图站在用户的角度，来重新审视现在的交互行为的合理性。第一个交互行为是用户查看记录好的需求。当前的设计是放在用户列表的顶部，并以卡片切换的形式查看。此交互形式虽然能提高需求的重要层级，方便用户查看，但是对于需求的数量有要求，如果相同重要层级的需求过多，采用这种形式展示就会增加用户的操作成本，那该如何优化呢？通过对用户使用场景的调研，明确该操作是目标用户的常用操作，且需求量会很多。针对常用操作，要做的就是减少用户的操作路径，方便用户触达。所以选择了跟客户列表用 tab 切换的形式展示；而针对数量多的特性，信息列表无疑是很好的选择，能承载更多的内容，同时也能让 tab 切换后的页面形式保持一致。接着我们就需要根据当前的交互形式，对场景跟目标用户的需求做进一步的拆解。信息列表虽然能承载更多的信息，但是内容一多，查找起来就会很困难，如何让用户找到一个或者一类需求呢？我就继续补充了该信息列表的搜索跟筛选功能，通过搜索能定位到具体的需求，同时为了提升搜索效率，增加了关键词联想的交互规则；而筛选是将同一特质的需求摘取出来，那如何定义需求有哪些特质呢？我通过功能的目的进行拆解，该功能是记录需求方便后续的跟进，根据跟进的目的以及用户的使用场景，定了需求的筛选维度：时间、重要程度 。然后为了让整个操作形成闭环，在用户记录需求的时候也增加了自动获取时间以及让用户定义重要程度的功能。第二个交互行为在于用户记录需求，原始的线框图是以选择项的形式让用户操作，但是为了能尽量覆盖大部分客户的需求，设置了不同维度不同层级的选择项，这就会导致一个问题，增加了用户记录需求的时间，那该如何进行优化呢？在与目标用户的沟通中发现，他们一般记需求是发生在打电话跟客户沟通的时候，而需求的内容往往不固定，之前的方式是采用手写的方式记录。结合使用场景与用户习惯，将之前选择的交互改成文本输入，同时为了进一步提升用户记录需求的效率，在用户进入记需求的面板时，直接唤起键盘，方便用户直接输入。四、敢于发声设计师往往自我定义为“执行者”，尤其是刚进入新的团队，在人生地不熟的时候更不敢发声，但是衡量一个设计师的专业性，不仅仅体现在他的产出物，还要看看他对于过程的思考与论证，而这些都是要表达出来的。在我加入新的团队产出交互方案后，就主动推进交互评审的进度，拉齐其他部门进行整个方案的宣讲，指出之前流程可能成为用户操作阻力的地方，以及自己整个的改版方向与目的，为什么最终选择了这个交互方案，最后还对自己的方案定义了考察的指标，方便后续对于方案效果的跟进。也正是敢于将这些内容说出来，才得以迅速的在团队建立良好的口碑。五、总结以上，就是笔者根据最近的经历，分享的一篇关于如何快速进入业务状态的文章。后续也会继续分享自己在实际工作中，关于产品交互的心得与感想。经验有限，欢迎大家批评指正与交流。本篇来源：优设网原文地址：https://www.uisdc.com/quickly-enter-the-service-state
需求 边界 功能 引言售卖软件服务的公司，最理想的状态就是开发一套通用的解决方案或产品，而几乎不用接收任何定制化需求（定制化需求大多会被内化成通用产品的新功能）。这种经营模式下，公司全部的业务和技术力量都可以集中在这一套标准化产品上。因为人力充足，那些为了提升体验满意度而做的努力就很容易有结果，设计师基本不用太过担心投入的成本。但很多公司面向的客户形态无法做到这种理想状态，这些公司对外交付的版本一般都是基于主线版本的定制化版本。为了效益，客户当然越多越好，交付肯定越快越好，这就意味着评审交互设计师输出的交互设计方案时，体验至上不再是首肯的目标，按时交付才是。所以支撑外包项目的时候，交互设计师如果没有边界感，输出的交互设计方案在后面的评审阶段将会被不断推翻，无法落地。前面虽然说了标准化产品维护过程中设计师不用过多考虑实现成本，但标准化产品也会有迭代周期，在一个有限的迭代周期内，也同样需要考虑边界问题按时完成版本迭代任务。那么交互设计师支撑外包项目或版本迭代项目时都需要有哪些边界感呢？今天我们来谈谈需求边界和技术边界。更多兆日UCD干货：4000字干货！9个方法帮你掌握UX文案写作相比美观的视觉设计，清晰的文案在界面呈现中同为重要，好的文案不止赋予产品更好的体验，也能够拉近用户与产品的距离，优化文案也常作为可用性测试后改良产品用户体验的落脚点。阅读文章 > 一、需求边界1. 什么是需求边界需求边界是指在一个明确的目标或产品版本中，为交付具有规定特性与功能的产品、服务或成果而必须完成的有限工作范围。该范围可控，不会在外力驱使下随意更改。2. 为什么要有需求边界试想，如果项目经理对客户的需求来者不拒，会有什么后果？项目无法按时交付，造成亏损。如果在开发阶段，需求依然充满变数，会有什么后果？开发人员可能会暴走继而影响团队士气。如果提前定义好需求边界，就等于给下游制定了明确的工作目标，也利于项目排期和进度把控，从而避免出现上述问题。3. 如何找到需求边界① 如何找到项目中的需求边界项目在启动阶段，对外需要一份正式的合同来确立合作关系，对组织内部一般都会有《项目工作说明书》《商业论证》《项目章程》等文件来建立内部协议拉通内部目标。其中，《项目章程》会对整个项目的需求范围做出最原始的定义，一般包含概括性的项目描述、项目产品描述及项目的总体范围要求，此时定义的需求颗粒度最大。就比如，某银行项目在此阶段的需求就是“上线企业 OA 产品”，这就明确了需求边界，我们要做企业 OA，而不是做企业网银。如果项目进行到一半，客户忽然要求我们做企业网银产品，那完全可以拒绝，因为超出了需求边界。（不过站在商业角度，遇到这种情况商务员应该会无比激动，因为来年的 kpi 在向他招手。）接着，在项目规划阶段最重要的前置工作就是进行项目范围管理，项目成员需要收集需求、定义范围、创建 WBS（工作结构分解）。这个阶段的 WBS 就是为了打造项目章程中定义的最终产品、服务或成果而进行的需求细化。此时，定义的范围就可以作为我们进行交互设计工作的指导性文件。（因为在这个阶段不细化需求和分解任务，就无法进行准确合理的项目时间管理、成本管理等的规划工作）。接着上面的例子，项目启动阶段，《项目章程》里定义的需求边界为“上线企业 OA 产品”，接着在项目规划阶段，就需要跟客户沟通确认具体的《功能清单》（见图 1-1，此文件是项目管理过程中非常重要的文件，如果没有此文件，项目监控过程将无法进行）。比如说我方通用解决方案里该产品是包含 18 个功能，但客户可能只需要其中 15 个，然后还要补充几个我方通用解决方案里没有的定制化功能。这个功能清单就是需求边界，也是我们开展交互设计工作的立足点。《功能清单》示例如果设计师在设计过程中为了提升体验而增加了额外的功能，比如说客户的需求是对发票拍照存档，交互设计方案中拍完照还能 OCR 识别发票信息，这个设计方案就超出了需求边界。单纯站在体验的角度上看，真是个很棒的点子，但站在项目管理的角度上看，这是“愚蠢”的，要知道，项目经理时刻担心项目进度不可控，一定不会让需求蔓延。但如果评审交互设计方案时是客户提出了增加发票 OCR 识别的功能，设计师了解需求边界的话就不会一口答应导致后面落子悔棋的尴尬局面。（如果客户提出了任何非交互设计的变更提议，我们都不要一口答应，可以说会后跟项目组讨论下再给您答复。）我们也可以了解一些项目经理针对需求变更的处理技巧：需重新评估需求的变动成本，跟客户说明，修改合同；寻找其他简单易实现的方案替代；告知用户在下一迭代版本中进行规划。当然，也会有特殊情况，为了维护客户关系或者按投入结算或者有什么需要达到的 kpi，项目对时间和成本没有特别要求，对需求变更有很好的包容度，那我们可以尽情发挥我们的设计才能，而不用受需求边界的约束。② 如何找到小迭代需求的需求边界上面讲项目规划阶段的《功能清单》就可以当作项目的需求边界，但是一般这份功能清单中的功能颗粒度较大，还是需要把一个个功能看成一个个需求，分别进行业务需求、用户需求、功能需求的剖析和拆解。另外，公司标准化产品的维护过程中，需求往往是市场声音或是公司上层产品规划策略亦或是专家走查的待优化问题，这时候如果没有专门的需求分析师或产品经理，交互设计师接收到的往往不是拆解后的业务需求、用户需求、功能需求，而是“一句话需求”。我们如何找到这种需求的边界呢？我们先了解几个概念：业务需求、用户需求、功能需求。业务需求描述的是用户为什么需要这个产品，用户需求描述的是用户使用该产品必须要完成的任务，功能需求描述的是开发人员必须实现的软件功能。下面举个例子来说明 3 个维度的需求，真正的需求边界就会浮出水面。某个项目的《功能清单》中，有一个“码上付”的功能，进行客户调研时，客户说“因为当前系统跟另一个系统无法进行数据交互，所以在当前系统不知道用户有没有申请成功，希望点了码上付申请弹出一个弹窗，提示用户不要重复申请。”按照客户的需求描述，方案如图 1-2：客户描述的方案该方案违背了交互设计的“防错原则”，增加了用户的“试错成本”，那必须按照客户的要求做吗？再次分析客户的描述，可以发现客户描述的是功能需求而非业务需求。运用需求分析方法和技巧挖掘它的上层需求（因篇幅有限不再讲述分析过程），可以得出以下结论，业务需求是：“防止用户重复提交码上付申请”。接着分析，能满足以上业务需求的用户需求是：1.用户申请成功后不能再进行申请操作（系统阻断用户的重复申请行为）；2.用户能看到“请勿重复申请”的文字提示（靠提示让用户自主停止重复申请行为）。这些用户需求对应的功能需求是：用户提交过申请后，将“码上付”入口置灰禁用，并在入口处打上标签“已申请”，如果申请成功该入口就一直置灰禁用，如果申请不成功该入口需要变为启用状态以便用户再次申请。但是客户的描述给出了技术边界（后面会详细讲解此概念）：当前系统跟另一个系统无法进行数据交互，所以当前系统不知道用户有没有申请成功，这就导致上面分析的用户需求的第 1 点是无法满足的，除非我们要求客户去改造关联系统而且客户愿意配合，否则我们只能去修改用户需求：让用户看到“请勿重复申请”的文字提示。靠用户自己规避重复操作行为。用户需求一旦修改，对应的功能需求也会随之变化：在申请码上付的按钮附近给出醒目提示“如果您已申请过码上付，请勿重复申请”。最后的交互设计方案如图 1-3：修改后的方案通过以上案例分析，我们可以把业务需求、用户需求、功能需求抽象为依次耦合并依次包含的关系。用户需求和功能需求可能会根据技术边界或其他约束而改变，但业务需求不会改变，也就是说小迭代需求的业务需求才是真正的需求边界。从图 1-4 可以看到，一开始设计师输出的方案肯定是满足业务需求的前提下，用户体验最好的方案，但有些用户需求+功能需求组合超越了技术边界和其他边界。我们评审设计稿的过程，其实就是不断将用户需求+功能需求修正到各种边界内的过程。（业务需求一般是在描述需要解决的问题，至于如何解决，就是交互设计师可以发挥的空间。如果业务需求都变了，那就是需求变更，需要走需求变更申请流程。）备注：以上案例将业务需求描述为“防止用户重复提交码上付申请”而不是“阻止用户重复提交码上付申请”，大家可以思考一下有何不同？用户需求+功能需求修正前后对比二、技术边界1. 什么是技术边界技术边界是指在现有技术水平可以被实施运用的有限范围。2. 设计师为什么要了解技术边界一个合格的交互设计师，能灵活运用各种交互设计方法输出体验最佳的概念方案是基本要求，但只站在体验最佳角度考虑问题所出的设计方案会是最终方案吗？显然经常不是。为什么会出现这种情况？除了一开始的需求不清晰不准确导致评审交互设计方案时还需要不断反向修正需求的原因，还有一大部分原因是体验最佳的方案无法用现有技术条件实现且重新开发成本太大。设计方案评审的过程，其实就是一拨需求干系人在不断寻找业务需求、技术边界、最佳体验之间的安全区（见图 2-1）的过程。如果交互设计师能熟悉技术边界，一开始输出的方案就往安全区里靠近，会大大缩短设计周期，否则只能一遍又一遍被按在地上摩擦。安全区示意3. 如何获知技术边界① 新产品项目的技术边界新产品项目的技术边界受制于上面提到的《功能清单》，比如设计的过程中，设计师觉得界面上展示一下头像会使信息更具识别度，这时候就需要去查阅功能清单中有没有上传头像的功能，如果没有该功能项目经理也不允许增加该功能，我们只能修改设计方案：去掉头像或者改用通用头像。其他更细节的边界几乎是无法提前预知的，只能在设计方案评审阶段或开发阶段暴露出来，反向修正设计方案。因此，设计师支撑新产品项目，一定要提前熟知功能清单，有的放矢。② 已有产品升级项目的技术边界如果是旧产品的升级项目，技术边界相对就多一些，因为要考虑现有系统的兼容性和现有技术的复用性。设计师动手前要体验产品，浏览客户提供的产品资料、用户手册等，尽可能多地提前预知和确认技术边界，这样可以减少设计方案的修改次数，提高效率。还有一些明显的技术边界，在需求沟通阶段就能暴露出来，比如上面的案例中，客户一开始就提出“两个系统目前无法进行数据交互”这个技术边界，但还有一些边界只能边沟通边发现。比如设计师觉得通用头像区分性别更具情感化，所以设计方案中女性用粉色通用头像，男性用蓝色通用头像，评审的时候就需要询问客户系统能不能区分性别，如果没有又无法增加该功能，我们只能修改设计方案：所有人员用同一个颜色的通用头像。如果评审时没有确认此细节，开发实现的时候就会找设计师沟通，影响开发进度。③ 界面结构体现出来的技术边界界面结构能反映技术边界。如果已经确认是在现有的技术能力范围内补充新功能，那设计师就需要分析已有同类功能的界面结构，以免随意变更界面结构导致新功能界面结构无法跟已有同类功能界面结构匹配，加大变更成本。举例说明，某银行要上线公司的一套主线产品，且要增加一个功能模块，该功能模块的审批流程需要复用基线产品的技术。一开始考虑用户可能出于催办等目的，需要在表单申请界面看到完整的审批流程，所以设计新功能模块时，将审批流程平铺显示在了申请表单页面上（见图 ）。基于交互经验输出的方案中间多次设计评审会也未提及这样设计有何不妥，最后开发做到这里，查看原有功能申请表单页的代码，发现同类功能的实现逻辑是将审批流程显示在了弹窗里（见图 2-3，显示在弹窗里而非当前页面上的历史原因是为了不破坏原有表单的界面结构）。现有实现的样式开发急轰轰来找设计师：“你这个界面实现不了啊”、“我们之前是这么实现的啊”、“要改也是主线产品改，但肯定来不及呀”，项目经理也急轰轰来找设计师：“按照现有技术实现的方式改下交互设计方案吧”、“项目交付时间快到了，别发散了啊”，在多重压力下设计师就得硬着头皮按照弹窗的样式，把所有表单申请页面全部改一遍（不改干净，新加入项目的开发人员会思考半天，然后来问你：这里为什么跟其他页面不一样，是有什么考虑吗？或是碰到“直男”开发，真的就按错误的交互界面实现）。按照现有实现修正后的方案如果对已有产品不熟悉，对已有的界面结构不熟悉，类似的情况会经常发生，这无疑增加了时间成本和沟通成本，是项目大忌。所以，设计师一定要会识别界面结构体现出来的技术边界。三、其他边界“国家制度、法律法规、行业标准”也是设计工作的重要边界。比如，理财产品界面一定要打上“市场有风险，投资需谨慎”的提示字样，不可用高回报高收益宣传口号诱导用户；再比如，保险产品宣传时必须明示是保险产品，且不得与银行储蓄、基金、国债等进行收益比较。硬件设备的操作方式也是设计工作的重要边界，比如说使用遥控器操作的终端界面，要特别考虑遥控器操作的局限性，不可让用户输入大段文字，可通过手机扫码填写的方式替代；再比如，操作触摸屏时，不能像操作 pc 一样出现右击操作。还有，设计规范也是设计工作的重要边界，如果不考虑设计规范一致性，会增加用户的学习成本。除了上面展开讨论的需求边界和技术边界，还有后面提到的“制度法规”、“硬件设备”、“设计规范”，还有很多因素共同决定最终的交互设计方案。设计师可以在平时的工作中培养自己洞察边界的能力，以便输出更加成熟的方案。四、如何在各种边界内做出好设计1. 须具备需求分析的能力设计师接收到需求之后，要能判断接收到的是不是业务需求，最好把业务需求用自己的语言描述出来拿给需求方确认。（如果团队分工明确，一般产品经理会把基于各种边界条件分析好的业务需求和用户需求给到设计师。如果团队无此角色，就得靠设计师自己识别。）就像前面提到的例子，如果业务需求是“阻止用户重复提交码上付申请”，而不是“防止用户重复提交码上付申请”，那性质就不一样了，阻止是不允许用户重复提交，那就得逼着客户和开发调整技术边界。但客户实际的意图是提醒用户最好不要重复提交，但允许重复提交。确认好业务需求，如果时间充裕，可以先不考虑技术边界，输出一个体验最佳的方案，然后再根据自己已知的不可抗力约束逐渐修正方案，如果时间紧张，这一过程可以在脑海里构思，直接输出修正后的方案组织评审。2. 具有洞察边界的能力但又有打破边界的勇气考虑各种约束久了，我有时候设计方案首先考虑的是开发能不能实现，好不好实现，这真的大错特错。设计师需要有技术边界感，但不能让技术边界感凌驾于体验设计之上，否则交互设计师就失去了存在的意义。例如，之前提到的发票 OCR 识别功能为例，应客户要求，要在主线产品的发票夹功能基础上增加发票 OCR 识别的子功能，该需求还要内化成主线功能。其中添加发票的界面，原来的界面结构是左图所示，页面的主体信息是发票照片的预览图像，加入发票 OCR 识别功能后，我考虑到万一将来有些客户不上发票 OCR 识别功能，或者识别不出信息的情况下，还是得按 4-1 左图展示，所以基于新旧系统和无数据场景的兼容性，我没有改变原有的界面结构，只是在预览图下面增加了识别信息的展示区域，即 右图展示。不破坏原有界面结构输出方案（左图为原有页面）但对用户来说，识别出来的发票信息才是他重点关注的内容，预览图只是个辅助信息，按照这个心智模型，首屏的主体信息应该是识别出来的发票信息，但上面的方案，首屏的主体信息是预览图。后来 UI 同事在进行视觉设计的时候，询问了开发能不能改变预览图的样式，得到开发负责人同意后，UI 同事按照信息层级关系优化页面（见 4-2 左图），而且跟开发沟通增加了一个扩展功能：没有成功识别到信息场景下和没有上线发票 OCR 识别功能的场景下，预置几个各种发票类型都会有的主要信息字段，让用户自动填入，见 4-2 右图（原有的发票夹功能，只有一个备注字段）。当我还在考虑开发尽量少改动时，UI 同事打破边界的勇气和灵活变通的智慧深深地给我上了一课。扩张边界后输出的方案3. 总结这篇文章讲了交互设计应具备的几个边界感，希望能帮助设计师快速输出安全区内方案以缩短评审修改周期，但请切记不可完全被边界束缚住手脚。交互设计师仍要站在体验最佳的立场，去争取扩张技术边界和其他边界，给设计打造更大的安全区和发挥空间。扩张边界后的安全区示意欢迎关注团队微信公众号：兆日 UCD本篇来源：优设网原文地址：https://www.uisdc.com/sense-of-boundary
情绪 工作 需求 经常听朋友们抱怨“上班如上坟”，我自己也是如此，但随着工龄的增长，我的“上坟感”无论从频率还是时长上都显著减少了，究其原因更多是心态和沟通能力上的成长。今年看了两本讲述职场的书，分别是李诞的《脱口秀工作手册》和杨天真的《把自己当回事》，今天想结合书中的部分观点，分享几个让工作变“简单”的小技巧，希望能帮大家减轻上班的“痛感”。降低焦虑干货+1：设计师职场焦虑怎么办？我总结了这4个方面！前言：越来越频繁的听到同龄人对工作前途的焦虑，30+的年龄在互联网公司就算你是 leader 或者专家级的岗位，失业后再次找工作的过程也是非常坎坷。阅读文章 > 一、可以有情绪吗常被教育“有情绪”=“不专业”，但我想，我们中的大部分人都无法将情绪与工作完全剥离。情绪无非来自一些工作阻力、压力或沟通时的冲突，既然不可避免有情绪，那不妨掌握一些面对情绪的方法：1. 处理情绪一旦发现自己有情绪了，不妨先暂停。如果是源于沟通产生的冲突，可以先记下双方分歧点，各自再回去找找资料，想想解决办法，约个下次同步进度的时间。如果是工作压力，就买点好吃的，睡个好觉，和朋友抱怨抱怨，看看工作之外的事物。先保护好自己的情绪，才能更好地投入工作。2. 表达情绪暂停重启后无非两种情况，若是一时冲动，就继续投入工作，如果仍然觉得这件事不对，那就好好表达。可以和领导或合作方说，你认为这件事情哪里不应该是这样的，这样做让你不适/委屈/难过，怎么做的话你觉得会更好，如果你不知道该怎么处理，也可以直接问：“我不知道该怎么做好，但我想解决这个问题，你有什么建议吗？”。如果你实在是情绪到达极点了，虽然不建议，但偶尔通过生气、哭闹释放出来或许也能解决问题。李诞在手册中说，在新人时期，生气、哭、都没有问题，你表达了情绪，其实也是在向领导和合作方表示你对工作的认真，对问题的重视。3. 不能一直拿情绪当武器虽说要表达情绪，但在表达的时候要切忌拿情绪当武器。如果你说“要这样我就不干了”很可能可以解决当下的问题，但这种解决方式一需要依靠对方的共情力，二对你沟通能力的提升没有任何帮助。别人可以因为认可你的态度或同情你的遭遇，妥协一次，但不可能次次依靠态度解决问题。况且，当你把情绪当武器时，也会伤害自己，如果你只能通过生气推进工作，那你的工作最后会只剩下生气。更好的方式是厘清原因，如果是表达问题，通过理性客观的说服替代情绪武器，如果是环境问题，可以对流程提出优化建议，靠流程来解决。4. 情绪不是被操控的杨天真在书说到：“如果有个人过来对你说：‘你控制不了自己的情绪，就说明你还不够成熟。’那么我会认为这个人根本就不懂得沟通”。所言极是，懂得沟通的人都明白只有情绪稳定才能更好地推进工作。情绪是被保护的不是被操控的。我们说不要拿情绪当武器，其实也是在保护对方的情绪。如果一份工作需要你不断地压抑自己或用情绪做武器，而对方完全不在乎你的情绪，或指责你不会控制情绪而不去解决情绪背后的问题，那说明你处在非常恶劣的职场环境中，接下来该做什么我就不多说了。二、主动沟通，保持客观上文我无数次提到沟通，但具体要怎么沟通呢？我发现即使是工作了很久的朋友，也经常陷入：遇到不公 难受/生气 找朋友吐槽 被建议去沟通 不敢沟通 不了了之 遇到不公 难受/生气...这样的死循环中。为什么不敢沟通，无非就是怕关系闹僵、怕暴露问题、怕意见冲突。然而我想说的是，意见冲突是工作的必然，关系问题可以通过沟通技巧解决，而暴露问题是解决问题的最好方式之一。1. 意见冲突职场分工一定有它的合理性，既然我们做这份工作，拿这份钱，就是要说在这个岗位上该说的话的。岗位分工就是这样，需要多方的声音来对冲，方案都是在磨合的过程中产生的。而且也需要每个人为了这个岗位需要坚持的“执念”发声，才能达到最好的解法。只要表达清晰客观，这种冲突就是好的。至于在意见冲突的情况下如何表达，不妨想清楚这几个问题：设计依据是什么？设计方案对用户有什么好处，对产品有什么好处？对方的工作诉求是什么？他的权利范围和边界在哪里？他是否有决策权？他所提出的要求是在他的工作范围之内还是之外？如果我不能满足他目前的要求，我有什么备选方案可以提供？2. 暴露问题很少有项目能一帆风顺地进行，遇到磕磕绊绊的时候，年轻的朋友总是习惯独自处理好，假装无事发生，做好了的情况下事倍功半，做不好的情况下就成了背锅侠。更好的处理方式其实是及时汇报：当前的进度到哪了？遇到的困难是什么？接下去打算怎么解决？既能让领导知道项目的困难程度，也能及时纠正解决思路，保证项目如期完成。如果是上线后才发现的问题，汇报方式也是分三步：造成这个错误的原因是什么？我的解决方案是什么？我用什么方法让这个错误以后不再发生？诚然，我们可能会面对能力的质疑或问题的指责，但及时沟通暴露问题既是分摊责任也是更快解决问题的方式。只要你提前找好解决方案，这些问题都会是你项目经验上的闪光点。3. 保持客观如果是遇到“人”的原因受了委屈不敢沟通，一个最简单的办法就是提事不提人。比如与你合作项目的设计师偷懒又不听劝导致你必须付出额外的工作，你可以这样反馈：这个项目设计人手有点不足，我已经尽力在加班赶进度了，但我担心这样下去可能会影响上线计划，是否可以多派个人手。这样既表明了自己最近持续加班的情况，暴露了上线风险，申请了人力，又没有指责同事。同理可以适用于其他职场关系的场景，核心就是客观，不说负面话，提事不提人。一些职场成功学总是会建议大家在职场中保持真诚，但不得不说真诚是需要超高的情商加持的，如果无法保证自己的真诚不被误解、不误伤他人，可以试试保持客观。三、接受有意义的失败当然，沟通不能解决所有的问题，总有沟通失败的时候，这时我会建议你放平心态，顺其自然。1. 理论是持续发展的虽说设计有一些既成的理论，诸如要保持一致性，标签应该是那样，面板应该是这样。但事实上规范是人定的，理论是总结出来的，拉长时间线看，理论是会发展的，规范是可以被讨论的。举个例子，以前我接收到的理论是 action sheet 和 activity view 是两个不一样的组件，面板不能叠加面板，而随着发展，action sheet 和 activity view 的边界开始变得模糊，苹果系统也开始出现了面板叠加面板的交互。坚持已有的规范或理论，或许能产出设计上定义的正确方案，但如果“设计正确”并不被当前阶段认可，适当的接受“创新”也未尝不可，在碰撞过程中我们或许就能触碰到原则的边界，理解规则定义的原因，探索现存规则的局限性，这些都能帮助你对专业有更深的理解。2. 重要的是经验而不是这个需求很多朋友会担心，这个需求做不好，会影响以后整理作品集，也无法展示自己的能力。其实大可不必这么焦虑，按每两周做一个需求来算，我们一年会做 26 个需求，其中只有 2-3 个需求能被我们放入作品集，加上我们和面试官之间存在着信息差，完全可以摘取出最好的 2-3 个需求，利用信息差整理出一份出色的作品集。我们做设计的目的不单单是把当前这个需求做好，更重要的是通过做这个需求磨练自己，成为一个优秀的设计师。适当地接受有意义的失败，当你明白原来这样做会造成那样的结果，这样是合适的而那样是行不通的，你就会成为一个什么需求都能兜得住的设计师，就能把每个需求都做好，甚至可以把做得有瑕疵的需求以完美的方式表达出来，也能回答上所有的质疑。3. 这只是一份工作很多人会瞎操心业务或公司的死活，觉得自己这个按钮没做好这个需求明天没上线这个业务就被我搞砸了，大可不必！这只是一份工作，关注自己，你要成就的是你这个人，不要把自己和公司的命运绑在一起，公司和业务的好坏应该由拿着这份工资的人担这份责任。甚至这个需求都不属于你个人，不要过多地干涉，你要做的是通过完成公司的项目实现自我成长。你是且只是自己事业的第一负责人，不要把自我成长的责任强加在公司上，更不要瞎揽壮大公司的责任。欢迎关注作者微信公众号：「白话说交互」本篇来源：优设网原文地址：https://www.uisdc.com/3-career-skills
按钮 形式 需求 签到的存在不仅可以增加用户的黏性，也是激活用户参与度的关键因素之一。签到按钮在 UI 设计场景中，算是较为常见的一个类型，一个好的签到按钮不仅可以提高用户的关注度，也能激发用户的点击欲。这就是给你的一个关于签到设计的小需求：这个小需求看起来很常见，交互设计也许给你的是签到两个字，也有可能帮你画了一个外框。总归它是显得很普通的，是不是没有一点设计感呢？那我们如何去增加设计感，还要有自己的特色，做出一个差异化的签到按钮呢？让我们带着这个问题，和黑马哥一起卷起袖子开干吧！签到功能交互设计分析：签到功能该怎么设计？从12个方面详细解析！本文是关于签到功能的视觉汇总分析。阅读文章 > 一、签到设计的类型在开始案例实战之前得先梳理一下关于签到设计的类型，方便我们挑选出最适合当前产品的风格。1. 纯文字形式纯文字形式属于最为简单的样式，有直接文字展示、文字带下滑线、文字加箭头等，这个形式不是很建议，缺少设计感和用户关注度。2. 按钮形式为了提高签到的点击属性，通常以按钮的形式设计较为稳妥，也就是我们说的签到按钮。按钮通常是带圆角的和全圆角形式，也分为线性外框、面性外框、质感外框等。想要设计得比较突出，通常会在按钮的质感上面进行视觉表现，增加光影质感和纹理图形等装饰。比如：极光风（弥散光）、流体渐变、图形纹理等都是不错的方向。3. 文字加图标形式在签到按钮的基础上，进行进一步强化就会配合图标或者图形进行视觉感增强。图标设计的角度出发发挥性也比较大，便于设计师做出更多方案。图形的角度可以是 IP 形象的结合，不仅可以提高情感化设计，也能做出差异化的设计方案。4. 微动效的形式微动效相较于静态表达来说，自然是要更为突出一些，签到按钮动态形式也是较为常见的存在。如果想要突出签到设计，微动效的表达是不会让你失望的。5. 特殊造型形式常规的形式依然离不开按钮的表达，为了打破常规形成差异化的设计，在签到按钮造型上面也是可以进一步深思的。在能够体现出点击属性的前提下，我们可以结合产品属性和业务特征，探索出符合属性范围的造型，也能使得签到设计更有特色。小结当我们梳理了一些常见的签到设计类型之后，就可以结合需求选择比较贴合的形式。当然，也可以创造出不一样的设计，下面就和黑马哥一起来演示一下吧！二、签到按钮设计实战需求：为一个充电桩产品设计签到按钮，需要体现出产品的服务属性，也要能变得更有特色。UI 设计师拿到这个需求都会觉得：这个也太简单了。于是就会快速的做出几个样式，虽然毫无设计感可言，但是老板喜欢就可以啦！不过，如果老板不喜欢呢，有没有思考过如何留有后手。1. 分析总结无论需求的大小，个人都会先进行一些简单的分析和总结。要知道别人做出来都是啥样式，然后再总结这些设计都有什么方法论。也就是本文开篇总结的一样，虽然很简短，但是总结有助于让自己更有把握。2. 梳理关键词关键词梳理可以打开我们的思路，虽然只是一个按钮，但是我们也可以通过关键词发散出更有意思的设计表达。比如充电桩这个产品我们可以梳理出哪些关键词呢？3. 绘制草图如果根据关键词都去进行电脑绘制比较耗费时间，先进行一些初步的草图有助于灵感的快速表现。4. 确定思路通过草图我们可以发散思维，选择出几个具有代表性的方案进行电脑绘制。这里黑马哥选择了电池这个表达作为示意，不仅可以体现充电的概念，也能体现出设计差异。5. 绘制初步造型只要思路确定了，绘制起来就比较快啦！快速把电池的造型绘制出来，然后再结合按钮的特征进行微调，以满足“签到”文案在造型轮廓中的布局。6. 初步配色确定造型后进行了初步的配色，利用大色块把整体的配色关系体现出来，这里也要思考动态表达的色彩关系。7. 质感深入很多设计师都只是进行简单的层级表达，缺少质感深入的技巧。我们要通过色彩变化体现出造型的结构特征，也要通过光影处理把电池的质感强化出来。8. 字体处理大部分情况下对于 UI 设计师来说都会选择一些常规的系统级字体，不过这里作为一个按钮来说我们在字体的选择上面可以突破。这里我选择了阿里妈妈数黑体作为签到的字体，然后也进行了一些质感处理，贴合电池按钮的设计表达。9. 最终效果通过对字体和电池造型的绘制，完成了这个不一样的签到按钮。我们再将按钮放到界面场景中看一下，最后结合界面的背景做一下投影等处理，这个关于签到按钮的小需求就搞定啦！小作业以上的静态方案算是完成了，这里也给大家布置一些发散的小作业。如果要做动态表达，你会如何做？如果这里要体现签到送礼，不改变当前设计基础的前提下，你会从哪些方面入手？欢迎大家进行思考，尝试去完成这个小作业，大家有什么新的想法也可以微信黑马哥进行交流。三、小结通过一个关于签到按钮的小需求和大家进行了一些设计交流，设计的思考带有一定的主观性，我们在自己的需求中还需结合实际的情况做出调整。需求不分大小，每一个从自己手中出去的设计方案，我们都要尽力做到最完美，体现出自己的职业态度和设计能力。本文观点仅作为个人经验表达，如果觉得不错我们互相进步，如有不足欢迎大家留言补充。欢迎关注作者的微信公众号：「黑马家族」本篇来源：优设网原文地址：https://www.uisdc.com/sign-in-function-design
场景 用户 需求 在产品设计中，我们经常会听到这些声音，“这个设计没有考虑用户的使用场景” “用户行为和场景不匹配”…… 每个人都有说到“场景”一词，但好像我们对于“场景”的理解又不太一样，那么场景到底是指什么呢？理解它又能够帮助到我们做什么？基于场景化的设计又当如何做呢？本文通过以下四个范畴，简要阐述一些场景化设计的一些概念，以帮助我们更好去理解它。更深入的场景化设计干货：万字干货！九大章节帮你掌握场景化设计思维编者按：本文从《无界面交互》一书说起，总结了场景化设计思维的知识点，帮读者掌握场景化设计。阅读文章 > 一、什么是场景化设计1. 什么是场景了解场景化设计前，我们先理解什么是场景，在实际生活中以及各类词条中，对于场景的定义会有些区别。百度百科，场景是电影或戏剧等艺术作品的场面，泛指人、空间、时间和事件构成的情境。梁宁《产品思维 30 讲》，将场景分为两个部分，“场”是时间+空间，“景”是情境和互动，当用户停留在空间的时间里，有情景并让用户产生互动，就是场景。书籍《About Face 4 交互设计精髓》场景是利用故事情节或者情境的叙述，通过叙事的手段方法设计用户目标的交互过程。不难发现，这里对于场景的描述都提到了人、空间，时间，以及要做的事情，大家一下就能联想到了 4w1h 分析法，简单描述就是谁（who），在什么时间（when），什么地点（where），通过什么行为（how），要做什么事件（what），这就组成了一个具体情境，也是我们经常讨论的用户场景，我们也可以简单称之为场景五要素。举个例子：小明早上起来后就去洗手台刷牙，人物小明，时间在早上，地点在洗手台，行为是用牙刷刷牙，目的是清洁口腔，这就是一个完整的场景。2. 什么是场景化设计有了对场景的定义，那么就不难理解什么是场景化设计了。场景化设计就是结合我们的产品需求，通过场景化的思考方式，即场景五要素，针对不同的场景结合需求制定不同的设计目标。二、场景五要素设计案例分析场景不是凭空猜测想象的，它需要有上述提到的 5 个要素中至少 2 个以上才能构成一个情境，下面我们分别从人（who）、时间（when）、地点（where）、行为（how）和目的（what）5 个要素在一些设计案例中的运用。1. 人（who）① 千人千面我们经常听到的千人千面，实质就是针对不同的用户画像，提供精准化的内容，比如头条新闻、微博推荐等，都是结合算法针对不同的用户提供个性化的内容。② RFM 模型基于用户分层，就是将人这个群体要素进行拆解分组，针对不同价值的用户，实现精准的营销策略，从而实现最大的 ROI。③ 为中间用户设计也是基于用户分层，通过用户群体对于系统使用的熟悉情况，从而把用户划分为新手、中间用户和专家，这么做的目的便于我们会把注意力集中在中间用户群体上。因为每个人接触产品时都是新手，但他们很快就会进入到中间用户，所以在产品设计中，我们需要做到既不迎合新手，也不迎合专家，而是把大部分工作和精力放在永久的中间用户上。2. 时间（when）时间也会有不同的类别，比如固定的时间点，或者周期性时间段。饿了么会根据不同时间点，推荐符合该时间的食物，比如在上午、下午、傍晚和深夜推荐的食物都会有一些差异。3. 地点（where）《春秋》写到，橘生淮南则为橘，生于淮北则为枳，说的就是地点会影响最终事物的性质和结果。举个例子，美团会根据用户切换不同城市地点，结合当地提供的服务，智能推送用户可能会用到的功能。当你在上海，猜你可能会需要疫情相关的服务；当你在齐齐哈尔、海拉尔区，猜你可能在旅游，需要查路线；当你在西藏日喀则，那就没有服务了。当然上述举例只是一个狭义的地点，在一些软件设计中，“地点”也有可能是不同硬件的区别，比如用户用安卓手机和 pc 电脑之间的区别。4. 行为（how）行为是用户通过一系列手段，能够达到他们目的工具或方法。行为的手段有很多，我们拿界面设计举例，《交互设计精髓》有一个理论，界面的设计呈现，应当是无限接近用户的心理模型，而不能基于实现模型（也就是开发逻辑）。当表现模型与用户心理模型无限接近，用户的行为也就会越顺畅，能够通过已有认知或习惯完成这个目标；反之，用户操作行为可能卡在了某个节点，或者没有完成自己的目的。所以当设计越接近用户的认知和预期，用户则会感觉容易理解，从而用户行为也符合我们的预判。举例说明，假设我们需要用奶油做一个苹果，希望用户愿意拿起它并愿意吃，应当怎么做呢？我们肯定会在形状、颜色以及气味，让它尽可能和真实场景的苹果更无限接近，这才符合用户对它的期待，最后用户才会愿意拿起并送入到自己的口中。5. 目的（what）在产品设计中，我们也称之为痛点或者爽点。它是一种需要，简单说就是要明白用户要什么。举个例子，因为最近疫情封控，我们需要做一款帮助大家做菜的产品，下面拿我和我老板做饭过程举例说明。我老板的做法过程，第一，我要吃什么，甜的辣的；第二，我需要哪些食材；第三，配上精美的盘子，美美地拍上一张照片。我的做饭流程，第一，冰箱里有什么，什么菜快坏了；第二，这些菜大概组合能够烧出一道什么菜；第三，用一个大盘子盛，这样可以少洗一个碗。简单看我们好像都是为做一顿菜，但目的完全是不一样的。我老板除了要吃上自己喜欢的菜，还有一点精社交的需要；而我嫌做菜麻烦，吃饭就是简单对付，填饱肚子就可以了。所以说同样是做一顿饭菜，两个人的目的（痛点）是完全不一样的，而如果到我们设计出来的产品，没有对用户目的做详尽的了解，最后出来的产品和用户的行为之间可能就是南辕北辙。三、场景化在产品设计中的价值有了上述对场景化的设计案例分析，我们发现场景更多思考的是用户需求。但是我们在做产品时，我们也会有产品需求，即我们要什么。通过对需求是否贴合用户场景，不仅可以帮助我们洞察需求，梳理核心价值点；还能帮助我们理解用户，提升产品体验。1. 洞察需求，梳理核心价值点梳理需求：初期的需求往往比较抽象，以功能为导向，这时候我们可以通过场景化的方法，深刻地理解需求，梳理并挖掘产品的新机会和新功能点。辨别真伪：通过场景化的思考，可以帮助我们筛选哪些是真需求，哪些是伪需求。主次矛盾：理清这些需求的强弱和先后，用户痛点的优先级，先解决和后解决哪些问题。2. 理解用户，提升使用体验① 理解需求上述提到，需求和场景紧密结合的，不存在没有场景的需求，所以设计前一定要先分析需求的价值及合理性，同时对场景作进一步细化和拆解，以便能够输出更加合理的设计方案。② 了解用户如果不了解用户的场景，单纯的纠结于界面设计，就像是盲人摸象，很容易陷入自己的胡乱揣测，导致设计出来的方案不一定符合用户的使用场景。③ 与用户共情把自己变成用户，站在用户立场考虑问题的思维方式。特别是 B 端产品，企业采购产品是为了提高组织关系的效率，产品功能往往强大且复杂，设计师在面对众多的业务需求，会很容易陷入到产品的逻辑规则中，而忽略用户使用过程中的感受。四、如何进行场景化设计理解了什么是场景化设计后，以及场景化设计的价值点后，我们再来看看场景化设计我们又当如何做。通过大量的产品设计实践中，我整理了常用的场景化设计设计步骤，如下 ：1. 列举场景场景梳理的过程中，我们抓大放小，找到核心场景，并描述出用户的主行为路径。然后再对其进行分类细化。便于理解，我们拿小明想要通过某电商平台购买一包虾条举例，主要流程：搜索挑选购买配送评价。当然以上只是大场景，拿第一个搜索场景细化举例，小明（who）在下班（when）回地铁的路上（where），拿起手机点开某拼夕夕 app（how），输入虾条关键词搜索（what）。重点是要通过场景化思考，描述出场景各要素之间的关系，是谁（who）、在什么时间（when）、什么地点（where）、通过什么行为（how）、做了哪些事件（what）。通过对用户场景的描述，将停留在我们脑海中抽象的信息提炼并具体化，更加直观的知道用户在各个场景的状态，发现我们在此之前想不到的一些细节，帮助我们真正了解用户痛点。关于真实场景的获得：以上只是一个简单的购物需求，它与我们日常生活息息相关，一般可以通过模拟或者访谈得到。但也有一些场景不是我们坐在办公室就能想象到的，比如拿 WMS 仓储系统来说，不到现场查看，设计师可能就体会不到现场环境的嘈杂和混乱，所以就不能够再用常规意义的办公环境来设计你的系统。有时为获得更真实的用户信息，躬身入局是一种比较好的做法，到真实现场观察和了解用户，也就是我们所说的田野调查。2. 通过场景挖掘机会点有了上面对场景的列举和描述外，这一步骤就是针对这些细化的场景进行分析和预判，并发现其中的机会点。通过场景化去挖掘机会点，一般有两种方法：基于当前场景寻找机会点通过对上一个场景分析，再结合当前场景预判行为，寻找机会点① 基于当前场景寻找机会点我们拿搜索场景举例，所有的电商平台在搜索输入时，都会提供关键词自动搜索内容展示。好处是可以通过输入的关键词，帮助用户进行整个词语的联想，方便用户直接点击，来提升搜索效率；另一方面也能够给用户提供更多的搜索方向。② 通过对上一个场景分析，再结合当前场景预判用户行为，寻找机会点比如拼多多的关键词自动纠错，在输入“下调”或“xiatiao”时，点击搜索后会将关键词已进行中文转译处理，并提示告知用户转译后的搜索结果，这样避免了用户重新输入再搜索，大大提升了搜索效率。再比如如果用户搜索了虾条没有下单，并且关闭了 app。那么等到用户再次打开 app 的时候，搜索输入框默认显示上一次与虾条相关的内容，一方面可以引起用户的注意，另一方面用户如果需要再搜索，可以快速触发，从而降低输入成本。3. 制定设计策略在制定设计策略前，我们需要考虑达成什么设计目标，只有明确了设计目标后，才可以理性分析存在的机会点，思考选择什么策略去解决。举例说明，我们想要提升淘宝搜索输入框的活跃度，通过用户体验地图（设计策略）在用户搜索中，增加热搜榜、XX 促销……再通过上线做 A/Btest （设计策略）看结果数据。最终我们发现，可以通过增加搜索推荐区域，针对那些不知道搜什么的用户、或者想要随大流的用户，通过一些热搜词汇来可以提升输入框的活跃度。常用的设计策略有很多，比如要分析用户场景或目标，就可以选择卡诺模型、用户体验地图、RFM 模型等；要提升用户活跃指标，可以采用福格行为模型、海盗 AARRR 模型，或者广告界常提到的 AIDA 模型等。用一篇文章，让你掌握能让用户快速增长的AARRR 模型AARRR模型因其掠夺式的增长方式也被称为海盗模型，是Dave McClure 2007提出的，核心就是AARRR漏斗模型，对应客户生命周期帮助大家更好地理解获客和维护客户的原理。阅读文章 > 不管我们采用任何一种设计策略作为指导时，都要先评估其是否合理、合适，确保选择的设计策略与设计目标是一致的。当然在使用过程中，我们也仍需对这些通用的设计策略进行适当的修正修改，使其和我们的业务更匹配。4. 效果验证效果验证就是需要通过一些度量指标，验证我们设计的结果如何，比如上述搜索举例，验证的指标就是搜索效率是否得到了提升。效果验证的度量指标需要结合我们的设计目标，上线后的方案这些指标是否提升或者降低了，是否和我们预判的行为一致。指标标的设立也和产品的特性有关，比如 B 端的产品常常关注效率等指标，是否缩短了操作流程，降低了用户认知等；C 端产品更加商业化，通常会用一些市场化指标，比如用户增长、转化率、GMV 等。五、结语回顾本文，不能发现，场景化设计实质是一种思维方式，它需要我们考虑清楚人、时间、地点和外部环境的关系，在这个关系下，用户会怎么想，以及他会做出什么样的行为。孙子兵法里说：水因地而制流，兵因敌而制胜。如果我们在设计时，也能够因地（场景）制宜，再通过制定合理的设计策略来引导用户，那么最终的设计目标也将会事半功倍。参考文献：Alan Cooper《About Face 4：交互设计精髓》梁宁《产品思维 30 讲》阿里巴巴《U 一点·料 2》本篇来源：优设网原文地址：https://www.uisdc.com/scene-based-design
资产 需求 组件 对于 B 端数字产品来说，建立一套企业级的 Design Systems 可以提升团队生产力为企业赋能，这当中会沉淀很多设计资产（设计资产指设计体系中的所有产出物）。在有了设计资产后，如何确保使用者能够正确使用？如何维护其良性发展？如何管理设计体系资产？如何建立和谐的资产共创流程？这需要一套完善的、行之有效的更新机制。说到更新，那必然不是 0-1 的过程，而是 1+1>2 的事情。去年我们更新了设计资产 V2.0 版本，随着业务的不断发展，在使用过程中发现基础组件模式需要新的拓展以更灵活的应对业务、发现缺少了组件的应用指南、使用场景等内容以更好的指导使用者、发现图标库缺少统一的管理等问题，因此在我们做了充分的调研和分析之后，启动了 V3.0 版本的更新工作，刚开始我们仅借鉴有赞的更新机制执行更新，但在执行过程中，我们遇到很多现实性的问题，基于此，我们结合团队现状沉淀出了一套完整的更新机制，它更适用于没有专门设计体系团队的中小型团队，在此跟大家分享，希望可以启发你的灵感。在进入正题之前，我们先思考一下，为什么做项目可以从立项到最后稳定运行一步一步执行的那么有条不紊？那是因为在项目的整个生命周期中，有项目经理在利用十分成熟的项目管理知识体系，在指导每一步流程如何执行。那么同理，对于设计资产，它也是一个项目，我们借用项目管理思维去管理它，把更新流程代入到项目管理的闭环，该如何来做？下面从项目管理的五大过程来分享我们每一环节的方案。一、启动过程目的：触发开启、确定范围及周期首先我们需要在启动时明确的核心内容是：什么时候开始更新？以什么样的周期进行更新？更新的范围如何定义？1. 触发开启在项目开启前，需要决定什么时候开始维护设计资产，这个很简单，在一个发版后，就要开始思考下一版本需要做什么了，这跟项目的版本迭代是同理的。所以在开启之前我们就应该要定义好如何做准备工作，如何收集设计资产的需求，这一点是我们一开始没有想清楚，后来在执行过程中总结出来的。对于设计资产需求的收集是一个需要全员(资产建立者及使用者)参与的过程，需求的来源是每一个角色在使用设计资产做项目的过程中遇到的问题，把这些问题进行汇总记录，便形成了可能要做的需求。所以此时要有一个需求池承载这些内容，为确保大家更好的协作，我们在钉钉知识库建立了在线表格「设计资产需求池」用统一的格式提需求，让问题可追溯。2. 确定范围确定范围就像产品做需求管理是一样的，需要对大量的需求进行筛选、归纳、排序等，最终确认每个版本的需求范围。同样，针对需求池中的内容，我们是以月度为时间节点召集相关干系人（也会根据产品的更新频率动态调整为两月一次），对需求池进行定期评审，通过需求决策三角模型来决策是否转化为有效需求，从需求的普适度、拓展性和实现成本三个维度来筛选、归纳、整理需求，然后用采纳、不采纳和待定三个状态来决策是否要做，最后会根据迫切度对需求排出优先级，这样就完成了我们需求范围的定义。然后，针对范围内的需求，进行解决方案的讨论，或许是优化、或许是新增的内容，都需要对提出人的解决方案进行讨论，若方案被大家一致共识 OK，那么方案按其实现；若有人存在异议，则需探讨出更优的方案。总之，是为了得出大家共识的和更优的解决方案，这是建立共同意识的良好时机，也为后续的组件资产使用提前加深印象。3. 确定周期为了使每个人都能与设计资产的进化步调保持一致，它的更新是需要有节奏的、定期执行的。更新周期需要结合项目的实际更新节奏去定义，设计资产作为设计的指导工具，当然是不能很频繁的更新，特别对于 B 端产品来说，大部分是以业务为主，组件的更新多半是一个事后的行为，所以我们暂定的频率是月度进行一次需求评审，根据通用性、复用性这两大指标的重要程度，在组内讨论看是否需要对其更新，会先进行内部文件更新，以季度的时间节点进行一次线上更新需求的评审，以评估是否要进行线上库的更新，实际线上库是时隔一年我们发布了 V3.0 版本。二、规划过程目的：制定计划、明确分工有了节点划分，具体要做的事情该如何去做，应该存在一个流程规范，并且要根据参与角色的不同分别制定。在我们设计资产更新维护过程中主要有以下几个角色和对应要做的事项，具体为：设计共创者：发现问题、输出方案、提出需求、参与讨论、执行验收…前端工程师：发现问题、提出建议、提出需求、参与讨论、开发实现…资产负责人：制定计划、资产维护、组织评审、推进进度、全流程统筹管理…在设计资产维护过程中为确保角色之间的协作能够顺畅的进行，我针对多个角色从需求阶段、设计阶段、开发阶段三个阶段，分别定义了流程图和产出物流转图，需求阶段的流程如下：后续在我们的资产和流程成熟后，会规划把收集需求这一过程开放出去，让更多的角色参与进来。前提是我们已经在公司内做好了设计系统的推广和普及的工作，这是计划下一步要做的事情。因为在项目协作过程中你会发现，除了前端和设计之外，像产品、测试他们都有了解设计系统的需求，如在测试过程中，当他们对一些功能点的交互方式或组件的视觉呈现有疑问时，就会到设计这边来询问，或者有一些建设性的建议等，这些外界的声音我们作为设计系统的构建者应该及时收集，所以后续我们会思考如何更全面的收集需求，让更多的人参与构建。三、执行过程目的：执行工作、确认交付执行过程分为两条线，一是设计侧本地文档更新的执行过程，二是前端侧线上库更新的执行过程。1. 设计侧设计侧的执行是要及时的更新设计稿，根据每月对需求的评审，会按评审频率同步更新本地设计资产文档，也就是我们的 sketch 文档，这份文档更新之后便满足了设计组内做产品设计时可以使用完整的内容。对于设计资产文档的维护单独库对应到人进行一对一负责的，最初为了让大家共同参与进来，在基础组件库的设计时，让每个业务线的设计师单独设计，然后由负责人进行汇总，但这样受限于 sketch 软件本身，遇到一个很繁琐的问题：当组件由不同的人各自在不同的本地文件绘制后，汇总的人没有办法直接 copy 到公用的文档中一键生成可调用的组件插件（不知道使用云文档的团队是否可以直接实现多人对一个文档进行共同编辑，不用本地文档传来传去），所以最终的汇总基本是需要重设计一遍，这样就引起重复工作的问题，在经历了两次这样的流程后，我们对此进行了优化，后续改为每个库由单独的人来负责设计产出，图标库、基础组件库以及可视化组件库都分别由一人负责绘制、上传、对接、更新。2. 前端侧本地设计稿更新之后，需要前端支持进行线上库的更新，线上资产更新需要设计和前端协作完成，这时我们是通过产出设计资产平台文档前端版来进行协作的。这个文档是从使用者的角度进行设计的，按照：基础规范、通用组件两大类进行划分，其中通用组件包含：导航、数据录入、数据展示、数据反馈、其他五大块内容，每个组件元素的内容分为：实例、API 和指南三大模块，其中指南当中包含了：使用场景、组件构成、组件尺寸、交互状态等内容，是一份用来帮助使用者更好的使用组件的指南型文档。线上资产的更新频率以季度为周期（也根据业务产品的迭代频率动态调整），图标库的更新是跟随产品版本按照图标的固定流程进行更新。四、监控过程目的：发现偏差、做好验收开发过程中和完成后，需要对还原度进行监控，验证是否与预期保持一致，这里的做法跟我们项目验收是一样的，检查资产实现的质量，整理到验收文档中与前端对接优化。对于设计验收之前写过一篇复盘小文，感兴趣的可跳转查看。最后一道防线！五步提升 UI 交互验收效率（附验收模板）细节决定成败，这次跟大家聊聊项目开发中最后一个环节，也是考验细节能力的一个环节，即「设计验收」。阅读文章 > 监控过程是上线前的质量把关环节，这个过程中我们也是全员参与的，设计+前端，通过互查、自查、验收的方式对组件进行验收，这个过程也是建立共识的好时机，所以更应该积极推动每个组件干系人积极参与进来。五、收尾过程目的：发布版本、归档复盘在发布版本之前，需要编写更新记录，更新记录我们是维护了两份，一份是线上平台中展示的更新记录，主要由前端编写，内容涉及到组件具体的实现、调用替换等技术修改相关内容，较为细致。另一份是维护在钉钉公共库维护的「设计体系更新表」，此表格的内容更为概括，主要是做功能变更记录，两份文档的更新版本号是保持一致的。所有的工作完成之后，最后，发布版本。每个版本更新后，除了将更新内容同步给核心的使用者以外，还需要将设计资产更新内容进行更广泛的分享，需要主动的引导和推广团队内更多的人去关注和学习设计体系知识，才能使更多人更好的使用起来，才能使其良好且持久的运转，才能收集更多建议以建立更加和谐的资产共创流程。收尾并不是结束，而是代表新的开始。总结这套完整的更新流程是根据今年设计资产从 V2.0 升级到 V3.0 总结而来，整个思路和灵感来源有项目管理知识体系以及 Design Systems 这本书，所有知识都是融会贯通的，我们利用项目管理的思维找到了适合自己团队资产更新的流程，能够适应我们团队的自然工作流程，只有这样团队里的每个人才会具有主动性，大家对设计资产的贡献才能更加均匀。虽然在执行的过程中还是会或多或少的需要一些问题，比如按时间节点迭代不能快速的解决组件当下的问题以更快的应用、大家在业务外需要花费更多的精力参与到共创过程难免积极性会有差异、具有创新性的想法不能及时的被纳入库实现……这需要我们不断的去优化这个小而美的流程，以更好的为团队协作提升效率。流程提供的仅仅是大方向上的指南，具体的执行需要根据实际工作流程随机应变，在此把我们的思路和成果分享给大家，希望大家进行交流学习，路漫漫其修远兮，吾将上下而求索，设计的进步需要不断的反思和沉淀，需要更多的思维碰撞。总之，多读、多看、多学、多分享，步履不停……欢迎关注作者微信公众号：「做设计的小仙草」本篇来源：优设网原文地址：https://www.uisdc.com/design-asset-update
品牌 需求 创意 哈喽，各位设计同僚大家好，我是造视品牌中心的品牌总监图层叔。很荣幸能在这里给大家分享一下我的个人职业生涯，以及这 10 年从一个单纯的技术型设计师如何成长为一名具有品牌思维的创意团队管理者。「服务品牌」倍轻松、松下、森马、WMF、自由点、卡士酸奶、十月结晶、水密码、原始黄金、盐津铺子、鲨鱼菲特、慧曼洗碗机、尔沫卫浴、德佑湿厕纸、传奇会茶叶……一、我的成长经历我是 2012 年在电商野蛮生长期进入电商这个行业的，在 2017 年开始创业。在这个时段是我成长最飞速的时候。让我从一个只关注技术的设计师，转变为一个具有品牌思维的经营者。也从最开始只追求技术上的提升，到系统化去学习品牌理论（在认知层面有很大的改变）。所以在创业初期思维的局限性，导致前期有大量的试错成本，在思维转变后，慢慢从开始做低端的设计，一步步成长为具备品牌思维的负责人。二、什么是品牌思维？首先要明白很简单的一个底层逻辑“供需关系”，因为所有产品和人的接触都是有供需的。设计也是需要搞清楚设计中的“供需关系”。无论是我以前，还是有部分的设计师，都是以技术为王，这样就会导致在设计时过于“自嗨”，就无法去洞察“消费者、品牌、产品、运营”之间的关系是什么。那么如何解决供需呢？ 1）需求：这个项目需要什么？ 决策人是谁（运营、老板、设总监），需求是什么？品牌当前阶段想要解决什么问题？品牌的发展阶段（萌芽，发展、破圈、成熟），品牌的历史是什么，品牌的内核是什么？产品在这个阶段需要怎么样去突破？产品是新品还是老品，新品如何形成差异形成流量爆品，老品如何奠定地位和标准。 消费者对于品牌和产品的需求是什么？消费者对于产品的市场需求，功能需求的挖掘。供给：我有什么？在这个项目如何解决一一解决这些需求？那么我们就以上面的需求罗列思维框架，举个例子大家就能理解了。例如，我们做的盐津铺子，盐津铺子在用户认知是一个很传统的品牌。随着消费的升级，人们对于休闲零食的需求不仅仅是口感和味道，升级为“社交属性”。“打破旧的烙印，焕发新的印象”这个就是在各个需求维度中找到的成果，通过这个成果与品牌需求、产品需求的结合提取了整个视觉打造的核心:打破消费者对于盐津铺子传统陈旧的烙印焕发新的印象在传承工艺美食的同时变，得年轻、潮流、有趣好玩。让年轻消 费者产生兴趣点，从而产生共鸣。怎么把传统的传承工艺用年轻时尚、有趣好玩的方式表达。再去倒推到我们视觉呈现：产品包装、IP 形象、主题风格、主题创意如何打造。所以通过需求的深度解析、才有了视觉表达关键词和思路：“国潮”承载视觉表现 ，用 IP 和国潮热辣少年结合。“美味匠心”坚守传承，传承工艺，新表现，新表达。“零食艺术”表达创新，零食界的“抓马”Drama。其次，当意识到了“供需关系“的底层逻辑。在考虑问题的维度就会发生变化，不管是创意想法、还是设计呈现，对于品牌自身的内核理解。就会从各维度的需求去考虑，这样对每个板块需求的理解会更加的深入。核心本质就是你的意识决定了你技能的瓶颈。三、整个经济下行的阶段，导致各行各业需求减少，设计师该如何破圈？近年来，总有设计同僚问我这个问题，当然了，每个人的情况不同，我无法提供实际的建议。不过我对于这个阶段的思考理解可以作为参考。① 认知破圈， 不断跟各职位的人多交流这两年通过和很多专业策划大佬，运营大咖，品牌一线操盘手交流经验和心得发现了。做品牌的核心要点，就是要分析产品，并且关联到背后的人群，一定要考虑到你的竞争环境，这些信息都需要综合考虑深度探索，才能做好一个项目。例如十月结晶这个项目，在接到项目时，十月结晶的定位和想要打造的整个概念“东方母婴”已经很清晰了。那么在品牌方向已经很明确的前提下，我的思考更多是把“东方母婴”这个概念结合产品，激活线上的触点，让消费者能快速感知到。结合之前的需求框架，我需要解决的更多是产品功能结合品牌理念，让消费者能在线上触点快速感知到产品功能卖点的同时，并且通过主题风格和视觉创意把品牌新的定位更加的落地，让消费者更容易感知品牌理念和定位。通过深度对于品牌和人群需求深度的挖掘洞察，提取了核心的视觉走向“国风之美与科技之力融会贯通” 东方精致美学结合创新科技匠心的主题风格。再结合产品本身功能属性“柔软的力量”。提取主题创意——遇见新生之美，绽放女性之力，来进行贯穿整个创意表达。主题风格+主题创意，来层层推敲产品元素，人群搭配，空间搭配，视觉符号，才有了十月结晶这个项目的呈现。 ② 认知破圈，不断拓宽积累自己的知识广度时刻观察周边的变化，培养观察总结习惯。多关注流行趋势、流行事件，并向自己提问为什么流行，为什么出圈，搜他出圈的背后逻辑以及操盘团队。对周身事物时刻保持新鲜感和探索，因为在当下信息爆炸的时代，更容易造成信息茧房，要时刻保持对于新的事物，新的趋势来进行探索和吸收。设计无时不在，电影、综艺、电视剧、包括去餐厅吃饭，养成主动思考背后的设计原因。③ 认知破圈，不断深挖研究每一个你接触到的品牌，或者你做的项目品牌的深度挖掘。从现状到历史，不断挖掘，才能更清晰了解这些公司在乎的到底是什么。我在做松下冲牙器项目时，前期对松下整个品牌，历史，创始人理念，产品理念进行深度的挖掘和探索，才提取了我们的核心卖点 6U+，以及创意主题。四、我在成长过程中走过的那些弯路从事设计行业以来，会发现做到一定阶段的时候，无论是在技术上，还是思维上都面临需要破圈，我大体把我的成长破圈经历分为 3 个阶段。1. 基础技术破圈在早期做淘宝的时候，有一条鄙视链，做广告的看不起做媒体的，做媒体的看不起做地产的，做地产的看不起做图文的，而做图文的看不起做淘宝的。因为在早期（2011 年）那时的淘宝设计，就是拼素材，下素材，拼在一起就可以用，几乎只需要掌握基础的排版，只要有一定色彩基础，在加上会用 AI 导素材到 PS，就可以满足工作需求。 因此在那时，我把更多的精力放在版式设计、配色和基础的合成技巧上的研究2. 综合技术破圈等到了 2013 年以后，明显感觉到行业内卷变得严重，开始重合成，重创意，店铺出现，我记得非常清楚，当年在美妆品类有一个品牌叫瓷肌，打造了一个药妆风格的感觉，瞬间在品类破圈，成了类目 TOP1，从那个时候开始，我意识到了品牌的重要性，意识到了风格的重要性同时，品牌和产品的关系，品牌和用户的关系，以及品牌和推广之间的关系。这才开始有意识的精进合成、视觉风格、研究产品与视觉的融合，以保持在这个不断变化的行业里面能不被淘汰。3. 认知思维破圈这个阶段，我认为是当前很多设计师都欠缺的，而这个阶段的我也只是还在路上，自从 2017 年后，我们加入到了一家营销策划公司。才发现设计是要跟策略进行结合的；在每个品牌在品类中不同的竞争阶段，不同的抢占市场时机，面对不同消费者，视觉打造的策略也是不同的；并且在什么时候需要去叫卖产品卖点，什么时候需要去挖掘品牌基因，什么时候需要结合推广做事件营销，这是一个相对庞大的知识体系。而现在的我，也正在这个阶段不断的学习与破圈也希望我的每个阶段的经历，能给各位小伙伴带来帮助。五、对设计同僚们想说的话我入行已经快 10 年了，见证了电商的起起落落。所以，我也在这个过程中不断打怪升级。在每个阶段不断的定一个阶段性的目标，然后朝这个目标不断前行。所以在这个过程中也有一些小小的心得，在每个阶段怎么发力。如果你刚入行，建议丰富自己的基础。从版式、构图、配色、元素搭配这些基础去深耕，因为这些技能是后期成长的基本。如果你入行 3-5 年，建议丰富自己的综合技术。从合成、C4D、AE、动效、手绘这些综合技能里面找到自己的偏好，其他作为辅助来进行学习与积累。如果你入行 5 年以上，建议丰富自己的认知（这个要前置，从进入这行就开始有意识的学习积累），从定位、传播、到品牌的理解深入浅出的不断随着市场趋势不断地更新。最后给每位正在奋斗的设计同僚一句我的心里话，做事的过程是追寻自醒的过程。做有趣的事，远比有意义更重要，追寻成就感 。本篇来源：优设网原文地址：https://www.uisdc.com/supply-and-demand
信息 用户 需求 一、复杂系统的交互我是做 B 端系统的交互，干这行的朋友都知道 B 端系统很复杂，对用户搜寻信息、完成任务的能力有很高的要求，使用这种系统也往往不像你刷抖音、逛淘宝一样轻松。针对如此复杂的业务情况，我时常会感觉当前我们“交互设计”或者“体验设计”这一行的行业知识基础还是不太扎实。我们大家都知道，“交互设计”作为一个极为应用性的方向，就像一张桌子，桌面上的东西是具体的界面设计知识，比如控件设计、页面排版，而桌子的四条腿则是心理学/社会学/人因学/信息科学等等稍微偏向于基础研究的学科。因此本周我找了一本信息科学领域对信息搜寻行为的入门级读物，从别的学科切入交互设计，看一看对我们的日常工作有没有什么启发。实际上信息科学和交互设计很有渊源，比如我们现在在使用的“信息架构”这个概念就和信息科学有千丝万缕的联系。而且信息科学的最初的研究领域就是研究图书馆或者公司组织这种大型数据库的，正好跟 B 端设计师的工作范围不谋而合，所以读下来的确感觉还挺有启发。今天我就摘录其中“用户信息需求分析”一节，结合我的个人感受写一点东西。“信息”的定义在学界是复杂多变的，甚至到今天也并没有形成一致的定义。在香农那个年代对信息的定义是“降低事物的不确定性”，在此基础上结合实验衍生出了我们熟悉的费茨定律。但这个定义明显不怎么考虑人的主观因素，也不太符合直觉，是一个很费脑子的定义。用一篇超全面的文章，帮你读懂经典的费茨定律费茨定律由心理学家 Paul Fitts 提出，用来预测从任意一点到目标中心位置所需时间与该点到目标的距离和大小有关，距离越大时间越长，目标越大时间越短。阅读文章 > 很明显学术界也有很多人有类似的看法，因此信息科学这个经过本世纪的发展，从一开始的只侧重于信息系统的构建，到今天也加入了很多心理学/社会学的视角和研究方法，和我们设计今日“以用户为中心”的核心思路也是有些类似的。在这些不同的视角下，作者归纳出了 4 种对“信息”定义和用户信息诉求的不同理解方式，下面我把它简写为 3 种。不同的研究者从不同的角度解释了“为什么我们的用户需要信息，他们对信息的诉求有什么差异，这种需求的差异又会形成什么样的行为差异”这个困扰我们交互设计师的问题。虽然他们作为研究者的思路是比较抽象的，但归纳出来的方式其实的确都能在我们的工作中找到一些现实依据，也是一个很妙的事情。二、用户为了获得答案而寻找信息罗伯特·泰勒在 1968 发表了一篇对用户（人）的信息需求的讨论。他坐在图书咨询台旁边观察来来往往的咨询者，发现每个人的咨询行为都很不一样，而且这种不一样似乎可以被分成成几类或者几种阶段。第一类阶段的信息需求无法用言语解释清楚，用户只能表达一种“模糊的不满”，一种对信息“脱口而出的无意识的诉求（Visceral need）”。第二类需求则是有意识的，但用户还是不能很有条理地说清楚自己到底要找什么，他们的陈述往往是模棱两可并且颠三倒四的。第三类需求终于逐渐结构化，用户可以用言语表达出自己要问什么问题、找什么东西，但用户不知道上哪里去找，也不知道自己应该找谁。比如这个信息可能出现在哪个系统里？我应该找综合咨询处的工作人员问，还是应该找哪个图书区的专员问？最终，第四类需求是高度结构化的，持有这类需求的用户很清楚系统会反馈给他们什么样的数据，只是不知道自己应该怎样与系统交互（比如输入什么样的词句），才能更好地匹配到自己想要获得的信息。他对这种现象举了个例子。比如一个读者来图书馆的实际目的是为了了解不同哲学家对一个哲学概念的不同见解，但因为他个人的特质、他对图书馆系统的了解、他的过往经历等等因素，他无法将这个问题非常结构性的表达出来，比如“你能用你的图书系统帮我搜索一下含有某哲学概念的哲学书籍能在哪个架子上找到吗？”。相反，他会来图书馆问一些非常宏大的、没头没脑的问题，比如“你们有哲学书吗？”他期望的不是图书管理员跟他说“对，我们有哲学书”，而是希望图书管理员帮他澄清问题、进一步的缩小检索范围，比如“你想找哪类型哲学书呢？”这个视角在 B 端设计中的价值主要是提醒我们需要对用户能力做正确的预估，以及一定要为用户搭建稳定的概念模型。从用户能力来说，虽然书中这一节并没有提到造成这种需求差异的原因，但根据我的经验，用户本身的受教育程度、思维方式、使用复杂产品的经验都会造成类似的信息需求的差异。我觉得业内一个特别不好的倾向是总把 B 端产品理解为“高能力用户的产品”或者“专家用户的产品”，但实际上 B 端产品的用户根据行业的不同，涵盖的情况相当广泛，也不乏上文说的那样“说不清楚自己要找什么”的情况出现。从概念模型的角度上来说，B 端产品可能因为各种各样的原因，有非常多的互相毫无联系的子系统。这就会让用户（特别是新用户）对“我能看到什么信息、我可以获得什么样的服务”毫无概念。在这种对系统整体边界没概念的状态下，用户也就总是停留在第三类需求的状态下，信息获取的效率很低。比如钉钉/飞书企业版都提供了一个“集成不同系统，在飞书上建立信息门户”的功能。简单来说就是公司购买这些企业版软件后，可以把自己的一大堆乱七八糟的邮箱/数据看板/后台等等以信息展示或者功能入口的形式“挂”到上面去，在聊天软件上形成一个企业门户。为啥要搞一个所谓“门户”呢？从信息获取的角度上来说，也是因为这些散落在各处的服务需要用一个集合入口去让用户对企业所有服务形成整体概念，从而更可能提高信息需求的结构化程度。从“这东西有没有？我该上哪找？”过渡到“怎么找更快？”三、用户为了降低不确定性而寻找信息一听到“不确定性 uncertainty”这个东西就知道又是香农那一套了，但是今天我们不再讲费茨定律，而是聊一聊用户在努力降低信息不确定性时的心理感受。查尔斯 · 阿特金在 1973 年将“信息需求”定义为“个人对重要的环境对象的当前不确定性水平与他期望状态之间的差异”。简单来讲，就是我们的用户对自己当前知识的评估，和他认为的理想状态的对比。比如一个用户自认为自己完全不会弄一个复杂的申请流程，并且他认为自己的岗位应该对这个申请流程特别熟悉，他就会受这种落差和自己的动力驱使，去不停的查找这个流程的相关知识和细节。这个过程中往往伴随着很高程度的焦虑，并且因为知识的搜索本质上是无穷无尽，精益求精的，因此这个用户何时停下检索更多的取决于他的动机有多强。比如这个学习者是个产品经理，在弄清楚了申请流程，他下一步可能还想弄清楚为什么要搞这么多步骤，每一步是为了什么，再下一步想弄清楚这个申请流程的迭代过程……研究者还发现，我们了解信息的动机往往不像我们经常做设计分析时那样理性、清晰、目标明确。也就是说，很多时候用户希望了解信息并不是因为他们想要用这些信息去分析啥，而是受“模糊的不安感，一种知识空白的感觉”所驱使，这是一种感性的情感需求。读到这里我的第一感受就是，这太体现情感化设计的重要性了。在我们的交互设计中，人对信息的理性需求往往被高估。比如我做表单或者做大表格的时候总是会去问用户“这个信息为什么对你很重要？”、“你要用这个信息去干嘛呢？”但实际上用户需要的可能并不是事无巨细的、机械式的信息透传，而是一种“对整体情况的理解”、一种“了解信息的安全感”，在这种安全感中，用户不会过高的预估自己掌握信息的必要性（因为他假设自己了解全局、他假设系统不会坑他）。虽然基础的信息透传还是必要的，但假如我们的用户没那么焦虑，是不是也就不必要持续进行地毯式的信息搜寻行为，生怕遗漏一丝细节？当然这种所谓的“情感化”不仅仅是指画多几个表情包或者写几句暖心文案。放在交互设计师面前的难题是，我们如何通过设计的形式去缓解用户的信息焦虑，为他们创造一个“不需要太专业也可以轻松使用我们 B 端软件”的概念与环境？视觉上的设计是一方面，但框架层及以上还有更多可探索的空间。四、用户为了构建意义而寻找信息这个研究很有意思，持这种观点的研究者认为我们生活中的信息存在不连续性，而这种不连续性就造成了用户认知的鸿沟或者裂隙。用户需要根据自己的诉求、动用自己的经验、寻找各种信息，并且不断尝试对信息进行归类、比较，最终内化信息，填补自己认知上的的“裂隙”。这个理论横跨了数个学科，实在是有点抽象，但好在作者在 93 年在咱们交互设计相关的会议上发表了一篇文章，举例详解用户的这种类似构建信息架构的意义构建过程，所以其实咱们看他的例子也能差不多理解。接下来我就为大家讲解一下。这个研究者在 1989 年观察了施乐（Xerox）公司的一个公司内部培训课程开发流程。当时施乐有几十种不同型号的打印机和扫描仪，每台打印机都有 10-20 份文件记录，每份记录从 30-300 页不等。因为这些记录内容都没有结构化，所以这个内培小组之前的课程都是基于某几种特定的打印机类型研发的，不好推广到所有的打印/扫描仪。举个例子，就像九阳有一大堆不同型号的豆浆机和破壁机，每个的功能和参数都有一些不同。有的有免滤豆渣功能、有的有加热烹煮功能，有的转速高、有的转速低，有的底部是塑料做的，有的是陶瓷做的。都不一样，也没人画个大表格归类一下。因此，内培部之前的课程研发只针对某款特殊的“免滤豆渣豆浆机”开发，讲这部机器转速如何、烹煮功能怎么用，有什么设计缺陷要注意等等。假如九阳的销售业务员都这样一个个机器挨个学，那显然效率太慢了，所以内培部门想了一个招：将机器分几个大类，先让销售们对我们九阳的产品建立一个大概认知，后续好深入。把学习流程模块化，比如有 3 种机器都有“烹煮功能”，那咱们就专门开一节课讲解咱们这个功能使用场景是啥、主要怎么用、对应的该如何维护等等，这样学起来就快多了。并且模块化/结构化的信息也能更好地支持对豆浆机/破壁机的分类。但是对于施乐的内培部门来说，打印机的参数巨多，分类方式也很多。面对如此复杂的情况，他们应该如何做到合理分类、模块化这两件事呢？换句话说，他们怎样从这些一盘散沙的信息中构建意义？研究者发现，这分成 3 个核心阶段：抓特征、抓差异：课程的开发者会从这些零散的打印机说明文件中总结出一些代表性特征，比如“底座制作工艺”这个特征可能包含了“陶瓷、塑料”找到特征对应的具体案例：也就是尝试把文件中的一些相关的信息点放到具体特征中，比如我看见这个豆浆机的文件里有描述它的“底部由金属构成”，那我就给它归成“底部制作工艺：金属”。在这个过程中逐渐形成整个信息框架。对特征进行增删：那些没有具体案例的、和案例不匹配的特征会被删除或者修改。比如我找到好几台豆浆机的制作工艺是“全体金属，底座橡皮包边”，那么“底部制作工艺”这个分类好像就不太能容纳这种案例，我可能会把“底部制作工艺”这种特征/分类调整为“制作工艺”，下面有两个子分类“一体制作”和“分体制作”。用户就是在在自上向下的“特征找案例”和自下向上的“抓特征、抓差异”过程之间不同的循环迭代，最终建立起一套比较稳定的体系，从而建立意义和逻辑。这个过程会充满了不确定性，随时会对特征进行修改。简单来说，用户完成任务的时间=建立概念的时间+真正去进行操作或者产出的时间。在这个循环过程中，施乐的打印机课程研发小组一共迭代了 4 版不同的教学架构。最后选择了第四种。为什么第四种更好？根据作者的陈述，是因为这样表示出了一种递归结构，有利于构建全局性的信息编码（可以理解为全局的标签系统），后续可以进行自动化的聚类分析。这里我们就不展开了，以后再聊。从这个视角来看用户的信息诉求或者意义构建行为，其实有两个特别有意思的点：施乐这个构建课程的过程其实极其类似我们交互设计师搞信息架构的流程。这个模型非常强调用户花在“理解清楚事情全貌”这件事上的时间，而不像菲茨定律一样极端强调用户花在具体操作上的时间。首先从信息架构的角度来说，虽然一开始信息架构：超越 web 的什么什么那本书就有提到“自上而下”、“自下而上”地构建产品的组织系统这么一回事，但是他只是轻轻的掠过了这两个概念，具体的提炼过程比较语焉不详。在这个案例里我们可以清晰的看到施乐这帮人是如何将“自下而上的聚类提炼”和“自上而下的分类归纳”这两个行为循环往复的做，从而产出一个比较稳定的、可以涵盖大多数信息的框架。那么我们作为交互设计师做信息架构的价值就是帮助用户省略到这个“咀嚼信息”的过程，让他直接跟着我们的思路走就能“消化信息”。从用户花的时间的这个角度来讲，我们在做设计的时候，特别是做 B 端设计的时候，很多产品经理往往希望你能把所有能展示的东西全部铺开给用户，好像提升信息的展示速度就等于用户对信息的获取效率提高了。从这个视角来看，完全不是这么一回事。你东一榔头西一棒子的提供给用户大量信息，其实就是给用户的“意义构建”提供了一个巨大的难题，他需要在这个页面上“抓特征差异”，然后“抓案例”来验证自己的思路，还要不断修改自己对这一摊子事物的抽象理解模型，然后才能真正进行操作。这个视角在我来看是对菲茨定律的一个挺好的补充。欢迎关注作者微信公众号：「白话说交互」本篇来源：优设网原文地址：https://www.uisdc.com/user-information-requirements
产品 经理 需求 相信很多同学在上一篇有留意到，体验设计中包含了以用户体验为中心增加和修改产品功能的目标，既然都从用户分析到产品原型输出，界面输出一条龙全套完成了，那还要产品经理做什么？上篇回顾：基础全扫盲！用大白话帮你掌握用户体验设计（一）今天再来继续一个比较现实的话题 —— 用户体验是什么？阅读文章 > 在这一篇内容中，我们就来解析这个大家非常感兴趣的话题和疑惑，体验设计师和产品经理的关系。产品经理 PM（Product Manager），是负责规划产品功能和推进它们落地实现的管理岗位。在互联网团队中，产品经理通常就是这个团队的大脑，他们提供想法，而其它岗位负责实施。产品经理也是一个解释起来比较麻烦的职业，职能既广泛又抽象，这一点和体验设计师非常相似。我一般将它的职能划分成三大部分：第一，需求分析，就是决定项目下一个版本要开发哪些产品功能的分析阶段。这是产品经理工作中最重要，也最困难的一环。无论做出什么决策，都意味着后续要投入大量的人力和时间成本来实现对应功能。所以为了给出有效的需求，产品需要在这个阶段做大量的分析工作，不仅要分析市场行业，也要考虑用户体验，技术指标，预算成本，甚至还需要综合团队内部的建议。这一点我们会在后面做进一步的解释。第二，需求输出，则是在确定版本要做什么功能以后，将所有功能的明细、逻辑、要点进行系统地输出，包括需求文档、产品原型、需求会议等。一个合格的产品经理，一定会通过合理的方法来记录和分发版本的需求内容，确保需求信息可以查看和追溯，在团队内部流通无阻。虽然需求分析是一个产品经理的灵魂，但需求输出就是它的骨架，是这个岗位最基本的职业素养和能力表现之一。我们可以通过查看产品经理输出的文档、原型或 PPT，来评价一个产品的基本功如何。如果在真实项目中，产品经理输出需求只有 “口述”，那无疑是一个不称职且不合格的 PM，这会为设计师的工作带来巨大的挑战。第三，项目管理，进入项目开发阶段后，分配并推进各岗位按目标展开工作的过程。虽然这看起来像项目经理的工作，但是一般互联网团队是不配备项目经理的，由产品经理负责。项目管理是产品经理综合能力的直接反映，不仅要具备团队管理能力、沟通能力、情商，还需要对涉及到的岗位、职业、行业有深入的了解，只有掌控全局，才能有效的分配任务和预估时间。以上就是对产品经理基本工作的简单描述，可以肯定的是，这个岗位所需的知识和技能量也是相当可观的，不管是广度还是深度，确实是高于体验设计的。业内一直流传一句话，产品经理是距离 CEO 最近的一个岗位，就是因为他不仅要做重大的商业决策，还要应对琐碎的项目管理。这种工作经历为更宏观的企业管理提供了良好的开端。体验设计师和产品经理的主要职能重复，集中在需求的分析上。体验设计师需要花费大量的时间做产品分析、用户研究，然后再给出需求分析结果。既然体验设计师都在做需求了，那产品经理不就可以开始摸鱼，管管项目进度就可以了吗？这里最大的误区来源，就是 —— 以用户体验为中心的设计，并不是产品功能设计的唯一指标。这句话建议大家默写十遍，从今以后不要再对产品设计的认知仅仅局限在用户体验中。前面说过，产品经理在分析需求的过程，除了用户体验外，还要考虑市场行情、政策指示、技术门槛、投入预算和时间成本。有大量的需求，并不是以用户为中心提出的。比如我以前从事的海淘行业，购物结算模块三天两头有新需求大改，并不是用户觉得不好用，而是海关进口关税政策朝令夕改，针对买家购买保税仓商品的记税、报税模式三天两头调整。这就导致产品必须先分析解读清楚政策条例和相关法规，再变更购物流程，调整页面显示字段和计算规则。详细过程就不阐述了，每次政策的调整都需要投入海量的精力做分析，而这些变动和用户怎么想没有关系，他们必须接受。当然，包括微博、知乎等平台上，用户评论会带上所在地 IP，你们觉得这是用户想要的功能吗？还有，商业战略层的考量也是影响产品功能设计的重要因素。比如早前的支付宝强推熟人社交，企图和微信竞争用户黏性。微信强推视频号，希望从抖音手里抢回用户注意力。还有咸鱼上线社区、饿了么上线视频直播、哈罗单车上线本地生活模块……这些看起来很 “荒诞” 的功能，显然不可能是以用户为中心的维度延展出来的，而是商业战略上的部署和尝试，用户依旧只能被动接受。除此以外，在 C 端类型的产品中，还有一部分功能的设计是完全根据产品经理的 “灵感” 推动的，比如微信的在看、拍一拍，蚂蚁森林偷能量，淘宝二楼等。前面讲那么多，就是为了说明一款成熟的产品，需求来源是多种多样的。无论用户体验有多重要，它也只是产品设计中的其中一个环节。当体验设计师承担体验部分的需求分析和制定时，不代表产品就没有事情做，正常情况下他还有一堆和体验不相关的事情需要分析和处理。或者，产品经理给出和用户无关的需求以后，体验设计师就要辅助产品经理进行 “需求善后”。通过产品分析和用户研究，尽可能以符合用户体验的目标对它们进行完善，即使用户可能并不关心它们。体验设计师的工作是具有辅助性质的，一方面在产品经理已有的需求基础上，提出一些新的符合用户体验的需求，另一方面是在产品经理给出需求后，通过体验分析来检测和优化这些需求。体验设计师既不能取代产品经理的工作，也不能代替产品经理行使项目管理的职能，所以不要再错误的认为体验设计是把产品工作做了以后让他无事可做。本篇主要梳理体验设计师和产品经理的工作差异，要想解除误区，就必须理解产品经理的主要工作内容有哪些。因为这不是一篇专门解释产品工作的系列，所以做了大量的简化，之后有机会会专门开一部分干货来分享产品的介绍。下一篇，我会针对体验设计的局限性和误区进行解读，帮助大家正确认识这个岗位的难点和缺陷在哪里。解除体验设计对新手的神秘感，和帮助大家能真正客观的认识这个职业。近万字长文！从头梳理B端产品经理和体验设计师的工作职责近期，一些项目经理、产品团队长、设计师经常问笔者一个问题：“B 端产品经理和体验设计师的工作职责分别是什么？阅读文章 > 欢迎关注作者的微信公众号：「超人的电话亭」本篇来源：优设网原文地址：https://www.uisdc.com/pm-experience-designer
需求 设计师 用户 作为交互设计师，最常做的工作就是按照产品给的设计需求完成设计。设计需求要分轻重缓急。非重点需求可以减少投入，但对于重点的设计需求，设计师应该如何去处理呢？在大厂的这些年，我看到、亲历过三种类型的设计需求处理方法：第一类：完成任务，保证设计质量第二类：完善设计需求，提出改进意见第三类：用户+业务视角，发挥设计价值这三种方式，也可以理解为从低到高三个层级，侧面反映出设计师的专业能力和工作水准。完成任务，保证设计质量有些设计师会以「完成设计任务」为目标。在接到设计需求后，并不会做过多额外的动作，对着 PRD 即刻开工。虽然这类设计师在设计过程中遇到问题也会跟产品沟通，但他们始终对 PRD 给予充分「信任」，即使有质疑也不会做过多的争辩或反驳。设计成果：基本能够按时按量地完成设计需求；中规中矩，不会出大问题但也不会有惊喜；设计质量和设计评审结果主要依赖 PRD 的质量，设计稿有时会被前端和后端追问、质疑、或被要求补充交互细节。设计评审次数、后期细节问题讨论的次数，会视设计稿修改情况而增加。设计师以「完成需求」为目标的工作流程完善设计需求，提出改进意见以这种方式承接设计需求的设计师，在接到需求后，通常会先深入分析、了解功能，会查看同类的竞品情况；对于 PRD 建立自己的理解，并在设计稿中有所体现。在设计稿评审时，这类设计师会有理有据地表达自己的观点，尽量争取用设计优化后的方案替代 PRD 中的不足。设计成果：在保质保量的同时，增加一些专业的细节、通用的规范；使用设计思维和方法让产品的功能更加流畅、易用；评审的过程中可能会与产品经理产生争论，可由前端、后端、业务方等对方案进行评估和取舍。设计师以「优化、完善需求」为目标的工作流程从用户视角出发，发挥设计价值这种承接设计需求的方式更高级和专业。这类设计师不仅会深入分析 PRD 和竞品，在没有条件做用户调研时，也会把自己当成用户，使用用户视角来分析问题。在接到设计需求时，这类设计师会根据 PRD 做这么几件事情：1. 梳理用户的任务流程用户的「任务流程图」也就是用户在本次需求中会经历的关键步骤的流程概述。它可以帮助设计师理清楚设计需求（尤其是新项目）中的关键节点。这么做的好处是：（1）从全流程视角，更清晰地理解产品功能和用户使用方式，以便于对流程做优化；（2）对关键节点进行检查和补充，比如在节点处会有哪几种判断逻辑、是否要对用户进行引导等等，既可以减少体验断点，也是给 PRD 查缺补漏；（3）整理出明确的设计重点环节，设计发力更有侧重。用户任务流程示例2. 拆解产品 / 业务的核心诉求对于这类设计师来说，PRD 的内容只是「待办项」，不是最终「需求项」。比 PRD 更有价值的是产品 / 业务目标，PRD 对于实现产品需求和业务目标来说，并不一定就是最优解。从「业务需求」和「产品需求」推导出的「设计目标」对设计稿的产出更有指导意义，使设计师对产品需求和设计方案进行再定义。站在产品视角和用户视角，对 PRD 提出挑战和质疑，是这类设计师的工作常态。从用户、业务、产品需求推导出设计目标和策略3. 根据实现能力，提出多个方案对于不完全确定可以实现的设计方案，这类设计师会在设计稿中画出 2-3 个方案，在评审中保持开放的态度，多方协调确定最优解。设计成果：保质保量地产出令其他人信服的设计思考和最优方案；从用户立场出发，让产品体验更上一层楼；从产品 / 业务目标出发，用设计为业务主动赋能，尽可能地发挥设计的最大价值；前期思考得越全面，后期反复修改、评审设计稿的用时就越少，提高整体工作效率。设计师从「用户+业务视角」出发的工作流程以上这三种类型的设计需求处理方法，也可以看出一个设计师的综合素养和专业能力。而当你不断地使用高级的工作方法来承接设计需求，你的设计能力也会有所提升。你可以看看你在平时接需求、做需求处于哪种状态和层级。这些思路和经验，希望对你有启发。用4张大厂表格，帮你有效提升协作效率！刚来京东的时候，时常会被这些问题困扰：“在多人协作的需求处理中，如何明晰进程？阅读文章 > 欢迎关注作者微信公众号：「长弓小子」本篇来源：优设网原文地址：https://www.uisdc.com/deal-with-requirement
需求 设计师 产品 设计师真实 emo 事件帅帅是毕业没多久的设计师，做设计总是充满激情与冲劲儿，这天他将反复修改的稿子终于交付出去了，想着终于结束了，但是没过一会，群里的产品在“内部讨论”后直接@他，要求他修改设计稿，竟然改回到了先前的稿子，他直接 emo~帅帅：啊，我他*不做了，一直叫我改，之前说了不能这样做不听，这下又叫我改回去，真的无语。小发：怎么了，大早上的这么暴躁，改不是很正常吗，谁又能每次都一稿过？帅帅：不是啊，我改了不知道多少遍了，他们一直都无法确定，我稿子改到后面我都不知道我为什么要这么做了，只想早点结束这个需求，给你看我改了多少版本：小发：做了这么多？难怪这周看你都在加班，那现在定稿了吗？帅帅：还没啊，刚刚他们确定了说让我改回到之前某次的设计，我之前的版本还被覆盖了，哎，真的很生气。小发：所以你现在还是马上就改？不停下来整理下到底是哪里出现问题了，导致这个事情反反复复的修改？帅帅：啊 我现在也不知道怎么搞的，我每次都很认真去优化修改。小发：一般这样反复改稿大致有 2 点原因：1. 本身方案存在瑕疵，经不起大家推敲，这个可以查看我写的《设计方案被质疑不合理？从这 4 个方向入手！》，尝试进行自查，争取下次交付更加合理的设计方案。设计方案被质疑不合理？从这4个方向入手！相信身为设计师的我们，在工作中肯定遇到过自己加班加点，绞尽脑汁设计出的方案被质疑、挑战，在宣讲自己设计方案时，总会出现以下声音：起初的无言以对到有理有据的辨析设计方案都体现出对设计方案更加全面的思考。阅读文章 > 2. 前期需求沟通出现偏差，方向始终模糊不清，设计一直处于一个不明确的状态下进行，节奏被一些（不靠谱，经验不足）的产品牵引，进入恶性循环。更可恨的是这个锅后面可能戴到了设计师的头上。在我看来，你这个情况大概率是前期需求沟通没到位，现在我来和你说说（交互）设计师如何有效沟通需求，说完你再回溯下你之前的沟通看看是否有出现问题。帅帅：好呀需求沟通目的小发：首先你觉得需求沟通是为什么？帅帅：就说下要做什么东西呗，页面是怎么流转的，需要有什么功能，什么时候要，聊完这些我就可以开始画稿了。小发：你说的没错，需求沟通的首要目的是：了解业务，明确需求，搞明白要做一件什么事情，不仅知道要做什么，更重要的是要明白为什么要做；其次是了解产品规划，及相应的限制，帮助自己后续产出能够与产品规划契合产出，做起来更有节奏，这样即使你手上有好几个需求，也能分清楚轻重缓急。了解需求类型，确定沟通侧重点小发：并且在日常的需求沟通中，面对不同的需求要更有侧重的沟通才能在短时间内获取到关键的信息。你自己感觉有遇到哪些类型需求呀？帅帅：遇到改版的、新功能的、抄竞品的、活动页面类的。小发：嗯嗯，大部分都是这些，有些你可能没有做过，按照我自己的经验来看，主要有以下 5 类需求类型：但不管什么类型的需求在沟通中主要都是围绕：是什么、为什么、目标预期、做什么、规划（时间、产品规划等）这五个大方面进行沟通，接下来我和你仔细说说这 5 类需求的特性及设计师面对这些需求的时候会遇到哪些问题。1. bug 优化类需求（执行力）这类需求一般都十分紧急，需要高效执行，不然会影响产品业务。虽紧急但这类需求也是最明确的，到设计师这边的 bug 类需求大多都是交互型 bug，大多都是交互设计稿指定的操作步骤、流程和结果指向；视觉设计稿指定的图片、文本、布局、显示位置、尺寸…所以当我们碰到 bug 类需求沟通方式建议是三步走：① 首先自己去体验下问题，这样沟通起来就能更顺畅；② 若是落地还原问题，可快速找到自己之前设计稿对应模块，联合视觉同学快速将这个模块流程及资源物料给到开发及时修复；③ 若问题更复杂则拉群共同沟通协调，多人同步处理，提高修改效率。若需要重新画稿，时间紧急时可以联系视觉同学，通过手绘传达意思，就不要再画交互稿了，快速输出资源物料~~~问题点：这类需求最容易遇到的问题就是协作不够高效，导致修复慢，是考验设计师执行力的时候，但不是所有的事情都要自己一股脑闷着加班加点做，合作才是高效选择，所以需要快速拉相应负责人快速沟通好各自分工和配合方式，做到有问题、有产出都快速同步，来个无缝衔接！2. 体验优化类需求（分析力）品牌升级：这类诉求一般是当前产品还能正常被使用，但过程使用体验存在提升空间，加上整体视觉风格老旧需要刷新，产品逐渐形成系统性的设计语言，在交互和视觉上都会进行刷新。业务优化：产品面临问题，有了新的业务目标，更加以数据为导向，所以需要围绕这个目标对产品核心业务路径进行改版优化，一般改动较大，很大程度上会改变页面的整体架构。品牌升级在面对品牌升级时，沟通中需要明确品牌理念及当前用户是否发生变化。只有在明确了品牌理念的关键词后，设计师才能有针对性的去进行发散。如：优酷视频的改版中就考虑到作为娱乐化内容消费平台，为拉近与年轻用户的距离，在品牌升级中将“年轻化”元素融合在颜色、语言、符号、容器、动效、图形、场景…中。业务优化这类需求往往承载着产品新的业务诉求（商业化方向），设计师需要深度参与需求的讨论与制定，全局性了解思考业务目标，明确数据指标，衡量设计价值。在沟通这类需求需要有三了解：了解原因:① 业务是什么？在什么场景下帮助用户解决什么问题？② 产品当前现状如何？数据表现情况和用户反馈情况如何？为什么需要改版？是否是因为用户活跃降低，流失增高的原因需要通过改版来促活？是否是用户有不好的反馈？还是因为竞品做的很好，把我们的用户都勾引过去了，我们需要想办法拉回来？通过询问上述情况，我们就可以大致了解这是一个怎样的诉求。了解目标：在了解完原因背景后，我们需要询问业务方改版优化的目标是什么？对产品而言，期望改版后可以提升哪些关键指标？提升的预期是多少？如何判断这个问题/项目是否成功？这边目标需要有具体的量化指标，5%？10%还是…对于用户而言，优化改版后对他们而言有什么价值？是否和他们的诉求相契合？对设计师而言，设计师可以解决的问题是什么？设计目标是什么？这个设计目标是否能够促成产品目标？问题点：这个环节沟通中，最容易出现产品和设计互相说服不了对方，无法达成共识。这是因为双方关注点不同，产品关注的业务效益和商业收益，设计师关注的是用户体验，美观度，如果双方无法达成共识可以参考以下 3 种做法：① 同理心，设计师沟通的时候需要有同理心，不妨想想对方关注点，试着从对方的关注点出发，结合自己的专业知识进行沟通表述，这样既能够为对方考虑，也能让对方感受到我们是和他们站在同一战线的，都是为了解决这个问题，只是我们想做的更好而已，对方听后，就更能够理解你。② 优化前如果有同类竞品，则可以对这些竞品进行分析。了解竞品当前的业务和自身产品当前业务是否一致，体验整个流程差异性，通过竞品的体验给到产品同学能够更直接的表达自己的看法，也更容易达成沟通共识。③ 如果双方沟通无果的情况下也没关系，不要和对方发生争执，可以拉相关的负责人及其他资深设计师进行一个简短会议，看看其他人的想法如何，尽量在会议中达成共识。了解规划：在沟通完目标后，需要明确我们的产出规划。如果有多个需求，那优先级是怎样的？什么时候需要给出框架、初稿，什么时候需要完成设计稿并评审？什么时候需要交付视觉稿，何时进入开发等。期间对应的负责人是谁？最终审核人员是谁？通过明确这些后我们才能更加清楚的知道自己后续先做什么后做什么？什么时间点需要给出哪些东西，这样才能将自己的时间合理安排，控制好自己的节奏。总结：这类需求主要是要围绕问题分析原因及后续的解决方案以及在商业权衡方面的思考，只要抓准这些方面进行沟通，方向总是不会错的。3. 新功能需求（洞察力）在新功能类的需求中，设计师需要围绕用户需求以及用户价值两个方面提出问题，不断和产品沟通。所以在沟通时需要：① 询问产品同学是否有进行用户研究？以及当前确定要做这个功能的分析资料；② 这个功能面向的目标是用户是哪类群体？有什么特征以及当前面临的痛点；③ 该功能的使用场景是怎样的？也就是我们常说的“目标用户”“使用场景”“完成什么任务”简称“人、场、事”；④ 最后需要沟通清楚这个新功能需要达到的目标，不光是业务目标，包括设计上的目标（如：完成基础功能搭建，路径顺畅）。需要注意的是，新功能的目标在整个过程中会被反反复复的沟通，设计师在过程沟通中，为了避免双方认知差异，可以拿竞品的页面、故事路径、简略的初稿和产品方沟通，毕竟“一图胜千言”，这样对方能更理解你的意思，提高双方沟通的效率。4. 运营类需求（执行力、创意）运营类活动是在某一段时间内进行的主题活动，有明确业务目标（下单率、业务转化、品牌传播）及营销群体，依赖游戏化手段带来优秀用户体验，从而获得成功的一类活动。面对这类需求想要高效的沟通，我们就得先了解运营类互动的特性，根据特性我们才能更好准备的对标沟通。运营类活动都有这 4 类特性，即：生命周期短、业务诉求强烈、主题氛围感强、游戏化。生命周期短：因为运营类活动生命周期短，上线时间点一般在特殊节日、热点开始，所以给设计、开发、数据等岗位同学带来较大的挑战。设计师首要需要确定活动正式上线日期，通过上线日期向前推导测试、开发等所需时间，明确留给设计的设计时间；其次由于时间赶，后续开发很可能会跳过设计师的设计稿，直接使用之前的程序模板、设计组件，所以在沟通中需要明确运营活动的开发限制以及是否有现成的开发模板或组件，为后续设计提高效率做准备。业务诉求强烈：运营类需求往往和 bug 类诉求很清晰，所以在明确完业务诉求后，设计师需要想达成这类诉求可能采取什么手法，这类手法落实到页面上变成具体信息，这里可以参考我之前写的《怎么设计转化页，重点关注两方面》怎样设计转化页？重点关注这2个方面！前景提要上个月淘宝新版本订单页的改版大家对整个改版都给与了高度赞誉，今天再次体验，发现并不是所有商品的订单页都是新版样式，想来淘宝应该也在进行测试，去验证改版的有效性。阅读文章 > 这些信息也要前期与产品沟通清楚，比如：标题要放什么更能吸引用户又能明确主题？主题氛围感强：运营类活动最后上线的图比起 ui 界面会夸张许多，页面氛围感更强，元素更丰富，所以为了确定后续活动氛围除了明确活动主题外，还需和产品明确活动面向的用户人群，通过这个我们可以更好的确定是采用：年轻化、职场、家庭、拼多多（风）…游戏化：游戏化方面需要沟通清楚游戏规则及玩法，以及游戏中可能会用到哪些元素等，这样才能在后续的设计中保证自己游戏化这块的设计不跑偏。5. 探索类需求（洞察力、创意）有时候做的设计不一定是产品提出的诉求，可能是设计自发想要探索一些新玩法，新风格，所以会发起探索类的设计需求。这类需求通常比较模糊，也不是说会有个非常明确的方向，所以需要设计师通过研究去进行产品玩法、策略的探索。所以这类诉求一开始并不需要过多的沟通，可能在研究过程中会产生更多的问题，这时候带着问题去沟通才能逐渐更加明确。以上就是总结的这 5 类不同需求沟通上的侧重点，会有差异性，也有共性，不管是什么需求都是围绕：是什么、为什么、目标、时间规划、怎么做去沟通，只是侧重点有差异性。掌握基本沟通技巧小发：对于沟通过程中的注意点没有过多的原则，只要把问题、要做什么东西说清楚就好，但是在双方沟通中，可能会因为个人情绪、不好的习惯导致沟通不顺畅，双方产生不愉快的情况也很多。对此，我想说真的不至于，工作而已。但是不管对方如何，自己可以要求自己做到基本的几点：善于倾听不要老打断别人说话，也不着急反驳，可能每个人表述习惯不同，你只听了前半句，就着急反驳，等到别人说了后半句，发现意思完全不一样，就很尴尬。多站在对方角度思考在沟通过程中可以尝试站在对方角度想下问题你就会更加理解对方提出这样问题的缘由。描述上也可以加入一些对方在意的关键词，可以让你说的内容让对方更加认可。沟通记录与同步沟通需要即时记录，沟通完若达成共识、沟通结论需要群里即时知照，让整个团队的信息即时同步，同时也便于后续出问题可进行责任判定。拿稿沟通养成拿草稿、竞品沟通习惯，可以简单手绘，或方块堆叠，比起文字，有图更有画面感。帅帅：好，我知道了总结最后，希望同行们不再因为前期需求沟通没做好让自己陷入到不好的循环中，不要让自己对设计的热情被这些沟通不到位消磨掉，希望大家以后面对不同需求都能不慌不忙，稳如狗！加油~~希望大家给我点个赞、在看呀~~如何通过有效的沟通，高效准确输出运营设计稿？在当今互联网快速发展的情况下，每个行业竞争都非常激烈，所以对于我们设计师而言，有时候项目的周期也非常紧迫，导致当我们接到需求时，很容易会遇到这样的问题：需求方解释不清楚，设计师不知道从何开始，对项目也是不了解，后面临时想到什么就问什么，使我们工作效率低下，也会让对方觉得你很不专业，做完的阅读文章 > 欢迎关注作者微信公众号：「小发的设计笔记」本篇来源：优设网原文地址：https://www.uisdc.com/demand-communication
业务 阶段 需求 “一入 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
界面 需求 原型 之前接到一个需求，在客户跟进系统中，销售根据客户手机号码生成的串码，复制到企业微信添加好友后，可以将 useID 自动关联绑定客户编号。有位设计师直接就对着原型把界面做了出来。对于做好这个界面，他也非常努力，比如让元素更好看，信息排列更整齐。我遇到过几位设计师都是这么做需求，但是最终出来的界面不尽人意。因为他们把目光都聚焦在局部，缺乏对整体的思考。今天用这个界面来说一下思路吧。这张是产品的原型，为了体现真实情况，文档说明基本是原话（已对信息进行脱敏）。原型的意思是在客户的主页点击「生成串码」就会来到这个页面，默认将客户的置顶手机号码显示在第一位，复制这个号码生成的串码，去企业微信添加好友就会自动关联绑定。就像以前要分享淘宝的商品给微信用户时，需要点击分享，将出现的那串文字复制到微信发给朋友一样。利用路径拆分原则，分析这个用户在当前页面要通过什么方式才能达到目的，可以分为以下两种情况：复制置顶号码即可满足需求；需要将其它号码生成串码才能满足需求。通过这张图，结合原型，我们可以发现这两点：1、这个页面的目的非常明确，是复制串码；2、置顶号码默认生成串码，其它号码需要点击生成才会有串码，因此重新获取这个按钮，在两种号码卡片上出现的节点不一样。理清思路之后再来看原型，会发现原型的低保真图与说明是两种意思，也就是低保真图没有体现应有的状态和正确的意思。如果拿着这张低保真图直接对着做，将「重新获取」作为页面的主按钮样式，这个界面的可用性就很低了，用户会认为点击「重新获取」是对应所有的号码。根据正确的思路，做界面之前我们应该做一张低保真设计稿。下图是对于原型进行优化后的低保真设计稿。我们还可以用墨刀制作一个小型 demo，找相关用户或同事进行测试。这样做可以提前验证界面是否达到用户的预期。小型 demo 如果验证不成功，用户依然有困惑，可以继续调整，直至验证成功后，才进行界面高保真设计。这个概念也叫 MVP，即最小可行性方案设计。方法有很多，简单的纸面原型、线框图都可以实现，视情况使用。通过验证后做出来的界面，返工率会更低，因此不要忽视这一步。接下来才是找参考界面，不用局限在相同类型的界面中，可以泛浏览界面，从中找到灵感。（所以平时收集界面很重要）成图如下经过这个事例，我们可以大致描绘归纳出步骤：识别需求-重塑需求-梳理流程-设计界面1. 识别需求识别需求不是读原型说明文字，而是要基于了解用户和产品的前提下：在什么场景，用户需要通过什么方式，解决什么问题。不然原型文字就只是文字规则，没有发挥最大作用。其次，需求是否合理，是否能真正解决用户问题。2. 重塑需求理解产品的意思后，利用路径拆分原则进行需求的重塑，了解用户通过什么方式到达目的地。需求拆分方法的原则可以看乔梁的《持续交付 2.0》，其中 INVEST 原则、需求拆分的五大技法能够帮助我们设计时以产品角度进行思考。3. 梳理流程梳理流程，查缺补漏后，进行界面的低保真设计。在这过程中用到 INVEST 原则中的 Testable（即可验证原则），不断验证直至成功再进行界面设计，可以让我们的返工率降低。4. 设计界面经过前面一系列的思考和验证，再去进行界面设计的时候，我们才是带着正确的任务：哪个才是当前的任务重点、什么元素应该强调或弱化、在设计规范的范围内怎么让界面更舒适好用…等。总结这个思路框架可以帮助我们快速而准确地完成界面设计，特别在小型需求上。别小看小的需求，每个界面都有其任务，可以推动流程的完成。面对大型的需求时，则需要拆分得更细致，用更全面的方法去做。老板说界面不好用怎么改？从这5个方面入手！有次接到个需求：“我们系统不太好用，视觉升级的时候也麻烦帮着改改。阅读文章 > 欢迎关注作者微信公众号：「牙线y2x」本篇来源：优设网原文地址：https://www.uisdc.com/interface-design
用户 需求 他们的 编者按：这篇文章出自于用户体验设计领域的专业机构 NNGroup，他们从心理学和认知科学的角度入手，基于「自我决定论」重新梳理了驱动用户的3个核心心理需求，结合实际的设计案例进行了演示和解读：在 Nielsen Norman Group，我们倾向于说用户不是懒惰的，而是高效的。用户所做的一切——包括使用网站和APP——都需要一定的精力和注意力。没有人有无限的精力和时间，所以用户只做他们最有动力去做的事情来保持效率。用户有动力去做一些事情，有的是因为他们必须这样做，有的事情则是因为他们自己内心深处想要做。心理学家 Richard Ryan 和 Edward Deci 深入研究过人类的行为动机，也提出过一种动机理论，称为自我决定论，它描述了人需要具备了三种基本的心理需求，才能具备「动力」来驱动他们为某件事情投入时间和精力：自主：是否发自内心而非受人影响归属：是否基于互动的本能，能否制造与人互动的机会胜任：了解自身的能力，对于结果有明确预期事实证明，人们倾向于有动力去做任何能满足这三个需求的事情。当这些需求得到满足时，人的内心也更加自洽而健康。因为这些需求相互关联，几乎可以遵循这套逻辑，来满足任何合理的需求，或者呈现出不错的效果。越是符合这3个条件，用户就越有动力和幸福感。让我们依次看看三种能够赋予用户以动力需求，然后就可以梳理出用户体验设计中有效激励用户的方式。自主当用户拥有自主权时，他们可以做出与他们的优先级和价值观相一致的选择，而不是被迫按照别人规定的方式做事。例如，为什么我们大多数人都期待周末？在工作日中，我们在如何利用时间方面的自主权有限：我们必须起床、上学或工作、参加会议、按时完成工作，并且通常按照别人规定的方式工作。然而，在周末，我们可以自由决定如何利用我们的时间——我们拥有更多的自主权。归属与他人产生联系，意味着用户可以以有意义和一致的方式，感受到他人的理解和支持。我们天生就是社交动物，这意味着，无论我们是内向的、外向的还是介于两者之间的人，当我们与他人进行有意义的互动时，我们都会茁壮成长。假设有一个刚刚接受新工作的人，一开始，他可能会因为每天上班而感到压力，因为那里没有他感知里与他有联系的人。然而，随着他开始了解同事并建立深厚的关系，他将开始与同事互动并享受在那里。这是因为他们的工作现在满足了他们对归属的需求。胜任人大都不喜欢无能的感觉。胜任感意味着我们在从事一项任务时，可以有效地取得最终的成功。第一次去滑雪的人会在设备的选取上挣扎，可能会摔倒很多次，感到寒冷，当他们看到周围有经验的滑雪者时，会感到沮丧。如果邀请新手第二次去滑雪，他可能会犹豫，因为他觉得自己没有足以胜任这一切的能力。只有在这个人花足够的时间，发展出相关的技能之后，他才会有足够的能力去享受滑雪。为何要关注用户体验设计中的这3个需求？在你的期望中，用户使用你的产品时，是因为他们必须这样做，还是因为他们想要这样做？满足用户基本需求的设计，能够制造动力的设计，既是令人愉悦的，又是易于使用的。赋予产品这些品质，是促使用户继续使用产品和服务的动力。我们常把这种体验称为「深乐」（deep delight，一种更深层次的愉悦感）。尽管我们不能总是改变用户在特定领域中，必须执行的任务类型（例如，制造或政府任务），但针对自主、归属和胜任进行设计，可以在很大程度上改善用户执行这些任务的体验。当然，这里可能会涉及到一些更为细分的问题，这些可以在其他的文章中进行探讨。在这里，我们结合一些实际设计案例，并分析它们是否满足三个基本人类需求。自主的案例包含自主性的设计，让用户拥有控制权。（控制权也是10 种可用性启发法之一）允许用户选择他们使用UI的方式，有助于感受到对这种体验的控制权。这样一来，由于他们投入了时间和精力，因此通常会导致他们对产品赋予更大的个人情感价值。实现自主权，有时就像允许用户配置应用程序、选择自定义颜色或按照自己的节奏查看内容一样简单。游戏化体验通常将自主性融入他们的设计中。设计得当的游戏化，为用户提供了不同程度的自由度来选择他们的体验路径。语言学习 APP Duolingo 和代码学习 APP Mimo 让用户可以自由选择与哪些内容进行交互，以及何时进入下一级别。Duolingo（左）和 Mimo（右）都是游戏化应用程序，允许用户选择他们学习内容的顺序和速度，借此来提升自主性。用户还可以自由决定他们想要达到的掌握水平。强迫用户采用一种既定方式的设计，限制了用户的自主权。Justanswer.com 让用户在聊天功能模块中输入信息，而此外不提供任何其他可访问的内容。尽管这种设计，在一定程度上和用户在律师办公室可能拥有的体验高度类似，但它使用户与网站交互的时候，深陷固定的方式。这个网站可以通过展示目录、常见问题甚至常见问题页面，来提供其他学习堪萨斯州法律的方法，而不只是聊天。Justanswer.com 强制用户在聊天功能中输入他们的问题以获得帮助。它不提供任何类别或常见问题。归属的案例当用户感觉到其他人有相同的观点，并理解他们的时候，他们会很高兴。了解用户在不同时间点不同情况的感受，并且构建与他们产生情感连接的产品，可能是一项艰巨的挑战。大多数情况下，归属感会需要较长时间的酝酿，但会受到许多小互动的影响。发现加强与用户关系的机会，最常用方法，其实就是传统的用户体验研究的策略，例如用户访谈和日记研究。这些满足用户相关性需求的机会，通常在用户历程图中有所呈现。设计师可以向用户展示他们了解他们的需求，其中一种方法是只给用户传递用户认为绝对最有用和相关度最高的内容。没有什么比包含简单、有用内容的适时消息，更能让用户相信他们被理解的了。Apple Watch 上的这条消息有效地与用户产生了联系，因为它使用了鼓励的语气。而发送建议的时间安排（傍晚）也使它显得非常现实，并展示了它对用户能力和环境的理解。当你认为你认识的人用错误的名字称呼你时，你可能很难从这种尴尬的情绪中恢复过来。同样的，组织和产品如果在错误的时间做了错误的事情，这种「不了解」会让用户很难从这种情况中恢复过来。在用户购买新手机壳后不久，Peel 在一周内发送了四封促销短信——试图向同一用户推销更多手机壳！这些信息就显示出 Peel 对用户的需求出现了错误的理解。在客户购买了新手机壳后，Peel 立即反复尝试让他们购买额外的手机壳。当用户觉得他们可以信任一个企业或组织时，他们最有可能留下来，保持关注。在浏览网站、使用移动 APP 和接收消息时，用户会下意识做出可信度上的判断。帮助用户，或者让用户感觉你了解他们的个人需求，可以表现出同理心，并增强他们与你关联感。另一种帮助用户满足归属感需求的方法，是促进个人之间的交流——也就是说社交，让用户相互联系。虽然这种类型的归属，在通信类产品中最容易实现，不过也可以帮助用户做共享内容，或将社交包含在工作流程当中。胜任的案例作为设计师，我们总乐于在产品中创造尽可能多的实用功能和服务。虽然我们的工作是创建尽可能强大的设计，但如果不帮助用户熟练使用它们，许多功能可能会被埋没。有效地盘活系统会带来更高的用户满意度、安全性、效率，以及许多其他的好处。话虽如此，即使是面对简单的移动端 APP 类产品，用户如果不借助教程 和新手引导，也无法顺利的玩转所有功能。由于高交互的成本和认知的压力，不能期望用户在使用应用程序之前阅读教程。当用户碰到不知道该做什么的情况时，引入有用的工具提示或叠加层说明，通常会好得多。尽管这种帮助在最近的许多设计中变得司空见惯，但仍然经常被误用。重要的是记住，最终衡量标准是它们是否有效地帮助用户能够更好使用产品。如果用户测试表明，它没有解决用户的问题，也没有提升用户的使用熟练度，那就把你的时间和精力放在改进设计上吧。如果一个系统的使用，很容易让用户得到胜任感，那么这个系统是非常有用的。好设计。在第一次打开 APP 时，Otter 会为 APP 的基本功能提供一个简单的教程。理论上，教程可以帮助一些用户变得更有能力，更「胜任」，不过设计虽好，但是多数用户会选择完全跳过教程。更好的设计。Otter 等到用户多次打开应用程序后才给出这个提示，并且只关注用户可以执行的某一项潜在操作。在用户对使用日历或日程功能表现出兴趣之前，这个提示就被推送给了用户。最好的设计。在用户第一次在汉堡菜单中选择「我的日程」之后后，会显示此界面，向用户展示如何使用日历的功能。这种方法在帮助用户熟练使用新工具方面，最为有效。当一个复杂的设计不能帮助用户变得能力更强时，这对用户来说是非常令人沮丧的事情。他们最终可能会浪费大量时间在其他地方寻求帮助（网上搜索答案或第三方视频教程）以获得胜任这个产品的能力。在复杂和专业应用领域尤其如此。FileZilla（一种文件传输协议服务）没有提供帮助新用户熟练使用它的说明。用户必须自己发现 FileZilla 的功能。3种需求有时会发生冲突在某些情况下，在单个UI 中自主性、归属感和能力胜任性，要同时兼顾是具有挑战性的。这种冲突的一个典型例子是使用向导。一方面，对于需要输入大量复杂信息，或需要经历复杂的分支流程的用户来说，向导可以大大提高他们的能力。然而，实际上，APP内置的初始向导又限制了自主性，作为新用户，进入向导就意味着将控制权交给了系统。TurboTax 使用向导来帮助用户，让他们胜任完成复杂的任务（纳税）。但是，这种方法要求用户放弃大部分自主权，因为系统会根据他们的选择，来决定推送给他们相关的内容。在这种情况下，与潜在用户一起测试设计，以确定三个需求中的哪一个优先级更高，这个至关重要。用户是否能够发现放弃自主权以提高能力更有帮助这件事情呢？就像 TurboTax 的情况一样，用户会不会宁愿在复杂性上稍微挣扎一下，会认为保持自主权更重要？满足所有三个需求值得简要说明一下的两个不同行业，它们是能够满足所有三个基本需求的领域。这里提到的两种类型的例子，是开放世界的游戏和协作设计工具。开放世界观的游戏开放世界的游戏，例如我的世界，通过以下方式满足这三种需求：自主：用户几乎可以完全自由地随心所欲地漫游和探索。当用户在这些开放的环境中将精力投入到他们的选择中时，他们可以定制花地创作，并且建立了强大的情感连接。归属：用户可以与同一个世界中的其他人一起玩，并协同构建，获得乐趣。在许多情况下，系统还支持实时通话或聊天，这可以增加交流的丰富性。胜任：这些游戏通常很容易学习。如果设计得当，它们还允许专家用户发现隐藏的快捷方式和机制，从而提高游戏效率。Minecraft 成功地满足了对自主、归属和胜任的需求，因为它允许玩家自由地玩游戏，支持与他人的联系，并且易于学习。协同设计类工具协作设计工具（例如 Figma）与开放世界的游戏形成鲜明对比，因为它们是特定领域的生产力工具，它们通过以下方式满足三个基本需求：自主：用户可以使用工具中提供的资源，创建几乎无限数量的不同设计。在大多数情况下，无需担心可以使用的图标、形状等数量的限制，也无需担心存储容量的限制。归属：用户可以轻松地与任意数量的同事共享设计，并以支持彼此工作的方式，同时处理相同的设计。胜任：这些类型的工具通常会提供大量有用的指导，例如下拉菜单中的键盘命令、新功能教程以及用于提问和帮助的活跃的论坛。（这样的论坛也有助于满足自主性的需要）。Figma 是一种原型设计工具，它还通过为设计师提供几乎无限的功能、与他人协作的能力以及学习许多可用功能的支持来支持所有三种需求。结论几乎可以肯定的是，仔细观察当前流行的数字产品，通常会发现这些产品满足人们对自主、归属和胜任的需求的方式。这项工作通常会因行业和用户任务的重点而有所不同，但你可以确信一件事，就是所有人都有这三种需求，并且会因此产生动力去使用对应的产品——无论是哪个行业。延伸阅读：用户为什么会点击这个链接？信息气味理论解释了一切编者按：用户是怎么判断点击A链接而不是点击B链接？阅读文章 > 从 4 个角度，聊聊长尾效应是如何帮助产品进行提升的编者按：长尾效应不是一个陌生的词汇。阅读文章 > Facebook 被上亿人指责的背后，可能是因为坎贝尔定律编者按：从 KPI 到 北极星指标，设计和产品团队都非常着迷这种杀手级关键性指标。阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/autonomy-relatedness-competence
落霞与孤鹜
表哥
在路上
张大湿
飞翔的企鹅
