关于我的项目经历总结，也能希望帮助大家，不足之处，请斧正。
最近迷上了总结和反思，也在摸索如何扩展自己的认知。
B端的工作远远没有C端来的那么有趣，面临的限制也比较多。很多的小伙伴说，B端好枯燥啊，毫无设计可言，只能当个线框仔和上色仔。在很多时候总是左右为难，一边是设计领导的意见，一边是产品的意见，另外一层又是用户/业务人员的意见。在实际工作中，面对这些情况该怎么办？根据我自己从事B端的经验，给大家总结几个“好玩”的点。
需求搜集相对是枯燥的，但也是最好玩的，也是能让你最容易满足的。你从杂乱的线团中，把线理顺的，你会觉得开心吗？你会有成就感吗？
为什么不是收集呢？因为收集主要指把分散的东西集中到一起，说明这些都是已知的，从各方那整理到自己手中。而“搜集”主要指四处搜寻某种东西。挖掘背后隐藏的需求，没有被大家看见的。通过不断的提问，不断的了解找到背后真正的原因。在B端行业中，最重要的就是“价值”和“效率”，你光靠收集来的需求，能满足价值的赋能吗？效率更不用多说了，还是老生常谈的话：“我想要一辆更快的马车”没错，满足显性的效率需求，可是背后的“汽车”用户能思考到吗？
需求理解和定义的过程可能不在需求本身，而是在需求之外，跟人的因素、心理学、社会学等有很大的关联关系。
需求的定义是为了准确且严谨的描述用户需求，而用户需求准确的前提是要能发现用户的真实需求。在日常对待需求的场景中，我们能难发现什么是用户真实的需求，那么我们该如何摆脱这样的环境呢？
我们作为一个中间部门（UED/设计组）最尴尬的处境就是对需求收集都是二手的。老板沟通时传给产品，产品传给交互，真正能保留到核心又剩多少。
我给大家举个例子：包政教授（给华为起草《华为基本法》的人）描述日本公司是这样布置工作的：
大家可能疑惑了，我知道这个干什么？我下发任务给谁？
这里的内容，是让你知道复述任务的重要性。那么我们在开会讨论的时候，针对一个论点，进行角色代入反推，如：这一期的迭代目标，是让用户提升创建商品的效率。
那么你可以这么问：
Q：我本期的任务，是针对商品模块进行交互优化，重点是提升创建商品的效率是吗？
A：是的
Q：目的是什么？
A：减少反馈、提高可用性等等
Q：提高可用性，这一块我们之前还没聊到过，用户有具体反馈到哪些问题吗？
A：用户这一块的问题还没收集到，差点忘了说。反馈的问题还需要你进行收集。
Q：那我的想法是需要组织一场用户调研，从各个方面进行需求搜集。我的风险情况是工期会延后
A：可以，我记录一下。
Q：那么我稍后会给你一个方案，看一下你有需要的补充是什么。（直观的复述）
A：好的
虽然是很沟通化的内容，但是能让你清楚具体的目标和目的是什么，也能帮助你知道杂乱点在哪。
这个方法是不是很好呀，提升专业性，发表想法，提高话语权，同时还能避免某些情况的返稿率，升职加薪还是梦吗？那么这样的你还是个线框仔和上色仔吗？
用户主动通过某个渠道表达对产品使用的不满及建议。我接手的项目主要是B端用户，他们的反馈很简单，就是私聊！“这里不好，那里我不习惯、你能不能改成和某某某产品一样啊等等。”为了避免过多的需求/吐槽影响判断，我会通过表格的方式去记录。
根据记录的内容，挑选与本期迭代相关的问题再与产品逐一去讨论，避免盲点的出现。那么我们与产品/需求方如何进行讨论最为有效呢，在这里我会推荐「乔哈里视窗」（Johari Window），乔哈里视窗也被称为“自我意识的发现—反馈模型”。它通过分类自己对自己的认知和他人对自己的认知的分类，来让我们看到如何去客观看待真实的自我（在这里引用为问题）。
（网图-来源百度）
没错！还是沟通的方法。沟通是在团队里经常发生。有的小伙伴会因为沟通不欢而散，有的能找准问题核心。不欢而散的原因，就是你说到他的隐藏区，他没能听懂你在说什么。为了能建立起一个有效的沟通，请把问题都抛出来，放在公开区去讨论，如果get不到，请到白板上画出来。
行事所依据的准则。
大家可以根据自己实际的情况作出定义，但一定是在有针对性的基础上，去聚焦业务作出分析。
当你才华横溢的时候，灵感爆发的时候，没有经过技术大佬的过目。一切都是空。
我以前会经常犯一个错，你为什么不能满足这个功能，这个功能很简单啊。为什么本期会做不了。其实我是缺少一个大局观。就好比：在一个房子正在构成时，本期修改只是单纯优化房型内部的结构。我却提出了，敲掉这个墙，改为落地玻璃，就解决了采光和逼格等问题。我没有考虑到现在房型能不能支持落地玻璃。承重、人工、合规、安全性等问题。我说严重了吗？不，我没有，有可能你临时散发的点就会导致这样的事情发生。所以，在我们有新想法的时候，请立即与开发组织一个碰面会。以确保你的改版需求，是否符合“安全”。
建议：我们在和产品做完需求分析和挖掘后，我们应当整理文档，邮件抄送给该项目的技术负责人，花个几分钟的时间快速面聊一下，听听他从技术上对需求的考虑，然后达成一个基本共识，在后期正式开发时，阻碍会小得多。
在完成了确认需求和技术评估后，将其纳入到backlog中，并大致描述需求逻辑，方便项目组成员对待开发工作心里有数。那么直属领导看完过后，会作出项目风险分析。
（此处backlog是为，真实的需求，是帮助项目组管控项目的工具/依据。而不是需求备忘录啊！！！同时颗粒度分析的话，我建议是不必太细，否则会不好维护和沟通）
(表格奉上，来源网图）
记录版本状态，这里就不做赘述了。
(表格奉上，来源网图）
a）面对大需求的时候，能够快速帮助自己梳理需求思路和功能、业务的流程，做到清晰核对，层层相扣
b）可以帮助项目组内部人员快速理解需求在做什么，省的废话比比比。
c）校验自己产出是否符合流程
d）是不是设计的思路很清晰了？
a）命名精准准确，在有动作发生的时候，我们应当使用动词。说明时则是名词
b）构思页面功能的组件规范性以及合理布局性。针对体验路径上把控好层和度的区分，一块模块卡片的运用。
c）功能的逻辑性。完成某个功能，应当遵循闭环操作，如某功能不能闭环，则需要反思自己的逻辑是否正确了。
d）条件触发。应当遵循尼尔森十大可用性原则。这也就不赘述了，说烂了。
e）常见类型。如缺省状态、输入、限制等等。
七、请站在用户的层面上去思考设计
比如表单校验（分业务场景）：用户只需要自己错没错，而不需要知道脏数据的由来。我们能做的就是帮助他避免错误。剩下的就让我们成为桥梁，让用户走进产品。
总结不够完善之处，请各位斧正，我定能接受其意见，也必将进行反思。
如果对你有多一点点帮助的话，请点个赞呗。
Powered by Froala Editor
1
作品
0
粉丝
1
关注
大牛，别默默的看了，快登录帮我点评一下吧！:)
登录 立即注册