设计方法论，是关于我们设计师解决问题的理论。它是设计师评估产品问题，定义并解决产品问题的思维方式、设计策略和参考准则的总和。参考准则的点，围绕某个设计策略之线，按照思维之面展开，就可以解决我们日常工作的绝大多数问题。
思维方式构建了设计的宏观思考框架，它是顶层的设计流程，在设计界具有较高的共识，分为两个部分。概括来讲，思维方式就是一套正确的设计流程，而设计策略则引导我们做出正确的框架设计，参考准则最终用来设计并检验每一个细节设计：
- 设计策略反应了具体问题的解题思路，设计策略会决定解题的思路，进而影响设计的成果所以需要根据场景审慎选择。
- 参考准则指导并检验每一个设计细节的正确性，也具有一定的普适性，是设计和检验产品的通用准则。
什么是方法论？
- 度娘说：方法论，是关于人们认识世界，改造世界的方法的理论。
- 我用自己的话说：方法论就是思维方式在具体实践中的模型或套路。
第一阶段是这次分享的理清概念的内容。第二阶段是如何正确运用。第三阶段是熟练使用，灵活运用。
为什么需要方法论？
- 官方说：目的是为了更好的服务两个关键节点——用户和业务。我们需要发挥设计专业来满足用户以及业务方的诉求。对于业务方来说，运用方法论可以更好的站在业务OKR和商业价值的角度提供专业的设计产出，赋能业务目标；更重要的是，对于用户来说，运用方法论可以站在不同的用户视角，提升高价值用户的整体体验，让设计思考可以更完整、更准确、更有说服力。
- 我用自己的话说：可以让自己变得更专业，得到认可；让设计结果更准确，让设计推导更有逻辑，产品博弈更有说服力；提高效率，快速作业。
对应方法论如何运用？
按照设计过程，我们可以统分为3个阶段：
1、策略分析阶段：策略分析阶段主要是解题流程、解题思路；
2、方案设计阶段：方案设计阶段主要是解题准则；
3、衡量方案可行性阶段：衡量方案可行性阶段主要是验证方案实际价值的规则和标准。
1、第一步：了解你解决什么阶段的问题。我们目前把设计过程按照先后顺序细化成了5个阶段，包括用户分析、增长分析、交互设计、视觉设计、结果评估。大家可以对应到自己设计环节的每个阶段。
2、第二步：明确在此阶段要选择的方法论。
目前我们梳理了在此阶段大家可能用到的方法论，给大家做一个初步指导，帮助大家缩小选择范围，后续会不断完善，比如：用户分析阶段，可以通过用户体验地图来对用户使用链路上的情绪和痛点进行问题分析。
3、第三步：把要解的题套用在方法论或模型中，推导出解决方向或方案。
如何了解项目背景？
我们可以用5W2H的模型来思考，发现解决问题的线索，寻找发明思路，进行设计构思：
- WHAT——是什么？目的是什么？做什么工作？
- WHY——为什么要做？可不可以不做？有没有替代方案？
- WHO——谁？由谁来做？
- WHEN——何时？什么时间做？什么时机最适宜？
- WHERE——何处？在哪里做？
- HOW ——怎么做？如何提高效率？如何实施？方法是什么？
- HOW MUCH——多少？做到什么程度？数量如何？质量水平如何？费用产出如何？
如何理解需求？
理解需求对于设计师来说是一件非常重要的事，需求池里的需求到底从哪里来？处在哪个阶段？是什么样的类型？
产品处于哪个阶段
- 探索期
- 成长期
- 成熟期
- 衰退期
需求池里需求来自于哪里
- 老板：老板自己对产品的看法。
- 用户：用户核心痛点、痒点、爽点；用户反。
- PM：产品经理站在整体产品角度的需求。
- 竞品：竞品竞争的需求。
- 数据：数据反馈的需求。
- 内部专家：设计评审会之后的专业需求。
需求是什么样的类型
- 全新产品类
- 产品改版类
- 功能新增或优化类
如何确立设计目标？
需求问题具体定位在哪个层级
设计部理解需求之后就要确立明确的设计目标了，发现问题是早期设计分析中很重要的一个环节，为了更系统、全面的发现问题，在分析过程中采用了对应产品5个层次的方法：
- 视觉表现层：科级感不足 / 视觉差异化不够 / 首页单调，风格老套
- 框架布局层：用户关心问题未体现
- 信息结构层：功能信息分布不够明确
- 范围层：信息不齐全
- 战略层：构筑品牌识别度
需求评估
- 是否可被证伪？
- 目标是否明确？
- 投产比如何？
- 是否有更优解法？
- 是否有可预见风险？
表现层：视觉部分
视觉部分主要是设计风格、品牌调性与具体元素的表现。
设计风格探索
- 结合用户、竞品、PM总结产品特性产品特性，得出体验关键词。
- 根据体验关键词发散，头脑风暴和情绪版，得出视觉关键词。
- 根据视觉关键词进行风格探索。
- 最终决定主风格。
色彩
主风格决定以后，根据情绪版提供的色彩和关键词，确定主色与辅助色。
字体
根据iOS和安卓的设计规范来。
图形
根据视觉关键词，提取视觉具象词，再提取设计元素转换成图形。
灵活运用插画。
图片
图片调性、版权。
框架层：布局部分
合理删除
在布局设计中，根据交互设计四策略：删除、组织、隐藏、转移进行归类。
比如删除，对应的就是奥卡姆剃刀原理。指的是界面设计前，我们首先要对界面设计元素进行检验，把不必要的元素进行剔除，然后才进入到元素的组织阶段。
整体布局
在组织阶段也遵从先框架后局部的思想，先考虑整体的布局原则，再考虑具体的元素布局原则。整体布局结构包括尼尔森F型视觉模型，古腾堡图表对角线结构，中间优先结构，同时也要考虑平台的一致性和框架进行整体的结构设计。
元素布局
整体布局完成后，还需要用美即适用的设计原则进行检验，确保设计界面整体的视觉舒适度，毕竟良好的视觉感受可以增强最高30%的设计可用性。确定大的结构布局后，再考虑每个模块的局部设计，这需要遵循亲密、对齐、对比、重复的四大设计原则，来增强界面的合理性和视觉韵律。
隐藏和转移
对于相对不那么重要的功能，根据席克定律和米勒定律，可以进行适当的分组和隐藏，而对于极端复杂的系统，我们则需要想办法转移系统难度至其他平台或者设计后台，降低用户当前使用系统的复杂度。
结构层：交互部分
主要是页面的易用性，流程的流畅性。
实现层：落地部分
规范与组件配合
了解开发常用组件，研究组件库，在落地的时候能对应上。
适配
一般来说尺寸用iphone11pro@1x的：375x882。因为介于320与414之间，比较平衡，在做的时候也要考虑到小屏和大屏显示的问题。
如果不是首屏设计不用考虑长度，只考虑宽度，宽度是自适应的。如果是卡片式布局，那么就需要有盒子的概念，只要定好两边的距离尺寸就行了，比如30。
协作
- 完善整个验收流程，明确跟PM提出要在整个项目的节点里预留时间给视觉做验收和还原，技术要评估工作量。（主要强调整个步骤是必要的，让开发人员重视）
- 切图、标注都要自己标注清楚，不要含糊模糊。
- 建立视觉走查表，把所有问题汇总上去，类似开发的BUG清单。
- 了解技术实现的逻辑原理、适配机制，否则很难建立平等沟通，了解技术的基本逻辑，在跟技术提要求。
什么是组件化？
组件化的工作方式信奉独立、完整、自由组合。目标就是尽可能把设计与开发中的元素独立化，使它具备完整的局部功能，通过自由组合来构成整个产品。
最重要的一点是需要转变一个观念，在前端开发的思维中，他们是以组件为单位，而不是以页面为单位进行开发。
为什么要组件化？
- 对产品的意义：
1，符合功能逻辑。
组件化的设计恰恰是符合产品功能逻辑的，特定类型的信息，就有特定的最优展现方式和交互方式，这叫做设计模式。设计模式就应该提取出来作为组件。
比如要从多个维度快速检索和对比大量数据，没有什么能比表格形式效率更高。想象一下，上面这个界面的表格数据，做成卡片式堆叠在一起，划一张换一条，或者像淘宝商品列表那样，一行4列平铺开。那还对比个P啊，用户都要摔鼠标了。
2，保持交互一致性。
交互的一致性，或者说可预测性，是用户体验的根本。比如日期选择组件，在整个产品中就应该只有一种存在形式。如果一会儿是滚轮拨盘，一会儿是日历，一会儿又是下拉列表，这样的设计绝对是不能上线的。
3，保持视觉风格统一。
这部分主要是视觉方面的考虑，更多样式上的差异。不同的样式会给产品带来不同的调性。就拿按钮来说。圆头造型表现出一种柔和亲切的特质，同时有利于将注意力聚焦到其中内容上。而直角则展现出一种棱角分明的硬朗，边界更加清晰。想一想三星手机和锤子手机的外观造型，两种截然不同的感觉。为了保持产品视觉风格统一，设计师应该找到最合适的方案，并处处保持统一，不可以太随心所欲。
4，便于设计师之间协作与修改。
组件化设计是大型设计项目的必要条件。比如两位设计师协作，一个在设计注册界面，一个在设计修改密码界面，或者在设计某个问卷调查的弹窗。这其中都有表单，两个人设计出来不一样怎么办？一个边框颜色深一点，一个边框颜色浅一点？其实没理由不同，应该保持一致。口头约定太麻烦，而且难以保证执行到位，组件化是最好的解决方式。设计总是要修改优化的，有些改动牵扯全局，动静非常大。
- 对开发的意义
1，降低耦合度，相信这是大型项目都在追求的。
举个例子，如果要把页面的body区域加宽。内部许多元素因为浮动、固定宽度、百分比宽度、文字行数减少等等，布局会乱套。就像这图里这样，这是因为内部模块的样式对页面父级元素存在依赖和继承。
可能有人会觉得并不存在依赖关系，但其实固定宽度本身就是一种依赖关系。假如说页面主体部分宽度1000px，左侧边栏200px，右侧800px。没错，这是按设计图来做的。那这个800px宽是怎么得出的？正是因为页面主体宽度1000px，才找了个合适的左右比例，设计成这样的。所以无可避免，从设计这个环节开始就产生了依赖关系。像这种情况，我宁可在模块外面多套一层容器，模块本身的宽度写成100%，外面那层容器属于框架布局，具体宽度写在它上面。虽然DOM树变复杂了，但内外的布局逻辑被分离了。
2，减少冗余
比方说要新增一个带表格的界面，开发同学按照设计的效果图一行行写页面。但是如果在某个已有界面中就存在表格？或许当时是另一位开发同学做的。相比重新写一遍，把代码要过来直接用更方便一点吧？
如果表格样式之后又要改呢，是不是两个地方都得改。如此一来，用到表格的页面越多，就越容易漏改。而且静态资源服务器上存了太多份关于表格的样式，其中内容明明是一样的。
3，优化性能
那么多份表格的样式，客户端每打开一个新的表格页面，就得加载一次。占用带宽，浪费了缓存资源。虽然一两个的影响几乎感受不到，但这种情况一多，就会对用户体验产生明显的影响。慢，是用户体验的头等大忌，没有之一。
4，便于与开发协作
这和设计师协作的道理相同。如果两个开发同学都在制作带有下拉菜单的页面，这部分工作只要交给其中一人就行了。TA做好之后封装成组件，另一位开发在自己的页面中加载就行了。
5，便于查错和修改
便于查错，是耦合性降低的一个副产品。它可以大大加快错误排查的速度。如果页面上出现问题，可以找出每个可能有关的组件，逐个拔除，直到恢复正常。这样就能迅速锁定错误发生的位置。同时组件内也可以形成完整的自测单元，也方便了测试工作。
假如设计师每个页面改同一个地方要花一个小时，那开发做同样的事情至少要花一个上午，至少。封装成组件，可以把这个时间缩短到10分钟。毕竟不用去改几十个页面的HTML、CSS和JS，改一个组件就可以了。
衡量方案可行性阶段主要是验证方案实际价值的规则和标准。
数据
数据反馈
满意度、点击次数、停留时间、活跃度、转化率
验证方法有很多种，数据是最直接的一种。但是用数据验证的前提是设计目标已经很明确了，就是我们明确了设计目标到底是什么？然后这个表面的设计目标实际上需要解决什么问题，继续深挖，问具体的问题。比如改动一个搜索功能，使设计流程更加流畅这是一个很模糊的目标：
- 首先要知道这是一个什么需求，是新增还是优化？
- 然后要反思，之前是什么问题？
- 最后再考虑有没有其他外在因素？
- 最后的最后，怎么定义流畅？
数据并不能解决所有问题，这时候我们就可以考虑更高层面的问题，比如验证更大的目标，比如用户反馈等。
老板
战略层面
比较主观的感受
用户体验
用户反馈
五度模型
若有收获，就点个赞吧
0 人点赞
