进行[线框层]设计非常重要的一步，也最容易被忽略的一步是上下文环境检查。当在设计某一个页面时，设计师容易基于当前页面本身思考而忘记用户在实际业务执行至本线框页面的上下文环境。
在这一步检查中，设计师需要身临其境地体验产品，了解用户执行整个业务路径至此了解什么、不了解什么、与系统交互的此时手上是否握有什么材料，材料的样式如何。这些都将帮助产品经理设计出最“接地气”的产品。
例如在设计信用卡绑定或支付模块时，产品经理要联想到用户此时手上拿着信用卡，如何引导他们输入信用卡效期，以及背后的三位安全码。信用卡效期“月月/年年”的格式，以及卡片背后的安全码其实是一大交互难点。
但我们看到大部分产品通过录入组件备注“月月/年年”以及图片展示的安全码位置最终解决了用户录入难题。
[展示层] —— 确保用户路径上的每一步视觉设计设计合理
| |||||||||||||||||||||||||||
在我的职能范畴里，因为有对应UI团队的关系，大部分专业的UI设计都转交由专业团队负责，但是做为“挑剔”的产品设计人员，在高保真设计出来后，还是应该从自己认为对用户合适的审美角度来对UI团队提出建议，与UI团队一起协作为用户产出更好的体验与价值。
因为篇幅关系，也因为UI部分尤其专业的技术性，我并不是专家，因此我将简单从我检查UI设计的基本原则入手简单介绍我的检查办法。
1.整体主题检查
不同的产品定位、客群及使用场景多多少少会帮助我们限定网站整体主题的范围。
例如面向高端商务人士的个人计划工具产品，就不太可能出现花哨、七彩的产品主题，而可能是黑金或扁平的简约“工作风”。
例如面向中年群体的养生知识产品，就不太可能是满是Kitty猫和动画的产品主题，而可能是类似报纸版面或者其它沉稳静态风格的主题。
2.页面字体检查
关于自己，我往往使用以下约束，在一个展示页面尽可能不超过两种字体，不超过三种字号，字体颜色不超过三种，不超过两种强调方法（加粗、下划线、斜体）。
因为字体过多变化将导致页面复杂度提升，就像给书本划重点全都划上时，就好像没有重点一样，甚至弄脏了书本，给视觉带来疲劳。
3.页面色彩检查
页面色彩是一个极具深度的学科。色彩有其心理学作用，有冷暖，有关联主题，也往往有其设计惯例。在进行色彩检查时，与竞品对照，但更多我遵从自己内心的第一感觉，也可以多找几位朋友一起给予反馈。
例如橙色常用于代表美味，紫色代表神秘，深蓝色可能有点忧郁..
例如政府网站常以蓝白为主。
4.页面元素间距检查
页面组件等各元素的间距，上留底，下留底，侧边留白都是设计规范的重要组成。间距与色彩检查相近，需要通过内心第一感觉以及多人的反馈来进行设计检查。
5.页面动效检查
动效不仅可以通过动作来吸引眼球，为产品赢得强调的作用；动效还具有时间性，可以帮助我们进行主次或步骤的演示；同时动效还具有体验提升的作用，帮助用户获得产品使用体验上的提升。
例如可以通过图表动效来吸引用户目光聚焦到图表。
例如可以通过引导动画来帮助用户一步一步习得产品试用步骤。
例如在系统阻塞时播放等待动效，或者在用户点击“加入购物车”按钮时产生将商品缩小并丢入购物车的动效。
[技术层] —— 确保产品设计通过基本技术检查
互联网上已经有很多文章在探讨产品经理是否需要技术功底，其实这本身就是一个很宽泛的问题。在不同的环境中，对产品经理是否需要技术功底答案是不一样的。
以下是我认为基础的需要产品经理考虑到的技术方面：
1.足够灵活的实体关系
因为产品经理是业务与技术衔接的纽带，产品经理需要具备一定的面向对象设计能力，确保可以设计出或者帮助技术架构师检查出明显的实体关系错误。
如果技术因为不熟悉现实业务而设计出不够灵活的实体关系，很可能造成频繁的数据结构重构，这是大部分产品项目不愿意看到的。
UML用例、类图和状态图是比较不错的实体关系梳理工具，建议产品经理，尤其是To B的管理系统产品经理学习。
2.深思熟虑的运算过程
因为设计工期着急的关系，产品经理在设计功能时往往注重从战略层到展示层的5层体验设计，却忽略了从技术层面审视功能间的逻辑冲突及运算过程。
例如一个指标评价功能，在设计评价指标算法时，要么会遇到评价指标公式不公平的情况，要么会遇到评价指标公式参数无法取得的情况，再要么发现所设计的呈现的图表方式、维度根本与实际用户需要的不一致。
运算过程的检查，需要产品经理深思熟虑地把系统运算过程在大脑里冷静的检查一遍，确保逻辑与算法设计的完整性，切不可浮于表面。
3.满足MVP的技术替代方案检查
做产品设计，尤其是To C产品设计，精益方法与MVP是非常有用的工具。越是思维缜密，技术功底足的产品经理越容易陷入“完美”技术方案的思维。
但是一个产品或功能初期真正需要的往往不是完美的技术方案，而是一个可以验证用户诉求，并快速满足用户期望的产出。在技术层面，产品经理积累越多经验和理解，将有助于他站在技术的角度以及精益的角度给予产品最适合当下的“完美”设计。
4.基本的可行性检查
大部分产品经理不会遇到此问题，但是本条备注给初入行业的新人们。具备对自己设计的产品进行基本可行性分析能力将有助于产品设计与研发的高效交流，避免技术评审迟迟得不到通过而影响进度。
[沟通层] —— 确保产品设计可以获得高效沟通
1.清晰的沟通对象
在产品设计的沟通过程中，因为时间关系准备沟通素材的时间总是很匆忙，以至于许多产品经理可以希望使用一套素材面向多方展开沟通。
对于沟通能力极强的产品经理来说或许可以完成沟通任务，但这样的沟通结果往往可能不会太理想。因为我们知道我们要面对的是有不同沟通诉求的干系人，他们可能是：设计评审小组、上级领导、研发团队、用户、客户…
检查并识别出自己所设计的产品的重要干系人，确保他们合理的诉求可以在产品设计中体现出来，并且需要他们关注的点以及他们关注的点在沟通素材中展示出来。
2.清晰的方案沟通
在我所经历的诸多项目中，一个产品的设计一般会经历方案设计（BRD+MRD）以及功能设计（PRD）两个阶段。本小节我们重点介绍方案设计检查：
（1）清晰的需求背景描述
当你遇到过辛苦熬夜通宵设计的产品被关键干系人一句“这不是我想要的功能”打回时，你便会领悟到需求背景的重要性。
产品经理需确保需求背景与关键干系人（需求发起人）一致以确保产品设计走在正确的道路上；另外还需要确认需求背景被传递到研发与测试，帮助他们在研发测试过程中提出好的建议以及做技术层面的决策。
（2）清晰的价值阐述
没有领导和客户会在沟通一开始就喜欢听产品经理津津乐道地描述我们的产品设计是多么专业、好看和细致入微，他们更关心的是我们的产品可以满足用户的什么需求，为用户带来什么样的价值。
在尝试通过简单的话语清晰描述出产品或功能的价值会帮助你认识到自己设计产品的改进，以及将用户带入你及你的产品。
（3）清晰的系统边界
在产品工作过程中，尤其是产品运行在复杂环境时，系统边界的确立对沟通尤为重要。
分别针对“用户-系统”及“系统-系统”边界的阐述，有助于沟通对象构筑思路，保证他们清楚产品与谁对接，提供什么，需要什么。
（4）清晰的功能范围
功能范围产品对外提供价值的承载，是沟通及与功能设计衔接的重要内容。说清楚产品提供什么，和不提供什么，有助于沟通对象了解产品的范围，确保与需求达成一致。
3.清晰的功能设计沟通
- 清晰的用例与业务流程。用例表达最基本的使用场景，业务流程描述业务的执行过程，对用户及研发团队理解产品背景有重要帮助。检查用例与流程表述清晰，确保研发团队可以快速理解并准确开发功能。
- 清晰的结构层设计。结构层设计是产品的基本组成框架，对用户及研发团队理解系统功能结构有重要帮助。检查结构层设计表述清晰，确保研发团队可以快速理解并准确开发功能。
- 清晰的线框层&展示层设计。线框层与展示层设计，对研发团队开发出与产品经理期望的前端效果有重要帮助。检查结构层设计表述清晰，确保研发团队可以快速理解并准确开发功能。
4.清晰的非功能设计沟通
响应时间、支持并发、加载时间等非功能性需求是产品设计在性能方面的补充。检查非功能设计表述清晰，确保用户拥有合理的体验并引导研发拿捏技术实现复杂度。
5.清晰的进度管理计划
没有清晰的进度管理计划难以确保产品及功能按预期上线，所以在沟通方面，产品经理需要检查产品项目已经进行了有效的进度沟通。
6.清晰的会议与沟通计划
设计评审会，设计宣讲会，迭代启动会，功能发布会、战略层变更、需求变更、团队调整或者临时发现的设计风险点…产品项目总是需要许多的固定或临时会议或沟通来完成协调。
产品经理需确保有清晰的会议和沟通计划，以确保产品开发进度以及干系人在合适的时间得到应该获知的产品信息。
文末
产品设计是一个自上而下，自宏观入微观，自粗到细的过程。在遇到系统分支庞大的情况下，产品经理往往会跳出这种自上而下的递进逻辑，选择对不同分支分而治之。这种自上而下和分而治之的思路切换势必容易造成考虑不够周全的情况。
产品设计自检就是为了帮助产品经理在完成产品设计后，重新快速地对自己的作品进行一轮检查，尽可能多地避免失误从而提升设计质量。
本文从7层结构出发描述的是作者自己在用的一套思维框架，越往这个树状框架的枝叶走，内容越落地，但是也越可能不够完整，因为最底层的它们均是由经验汇聚而成。
作者的产品设计经验面对庞大的产品领域来说仍然很小很小，另外回忆经验的过程多少也会有所丢失。但仍然希望分享出一些自己的思考及经验，与各位产品人共同成长。
若这个经验或多或少能给部分朋友带来帮助，那我将倍感荣幸。
文末，愿所有勤奋的人，快乐：）
附录：Mindmap
京公网安备 110105001605号