当我们日常大部分时间都在面对小的业务需求，且日常工作的细碎需求较多，该如何提升自己呢？本文就这个话题展开分析，一起来看。
最近有小伙伴提到：“我毕业后就在这家公司了，大部分时间都面对小的业务需求，日常工作也是细碎的需求较多。3年下来了总感觉自己没有提升，请问在这方面有什么好的建议么？”
今天我们就来聊聊这个话题~
小的业务需求是我们设计师日常工作中经常遇到的，把这些小需求做好其实并不是一件容易的事。
很多人觉得这些小需求做起来没有价值，而是戴着有色眼镜觉得它很“无趣”，认为对自身的专业提升没有太大帮助。
“没有小角色，只有小演员”。
这句用于演员身上的话其实也可以用在我们设计师身上。小需求的解决本质是工作职责的一部分，我们首先需要调整的是自己的心态（毕竟我们是一个合格的职场人，需要认真对待工作），建立工作的责任心，要有信念感。这句话还真不是鸡汤，设计师的作用是凭借自己的专业能力促进业务目标的完成。我们需要考虑的更深远些，学会给自己加戏。
学会放大需求！
不能把目光局限于表项的业务诉求，我们需要从专业的角度去审视它，可以按照设计的前、中、后3个阶段来拆解。
小的业务需求与大的需求相比，通常在体量和复杂性上存在差异。这可能导致在日常设计工作中，我们容易低估小需求的重要性和潜在价值，因为这些项目看似简单，可能只涉及小的界面或功能点的优化。
我们经常会因为这些看似的简单而忽略它的业务目标。日常工作中过于专注于这个需求任务的执行，而忽略了核心问题：这个小需求的背后的业务目标是什么？是不是只要按照需求方想要的效果直接按照产品的思路实现就好。最终我们会发现如果没有明确定义的业务目标，设计思维通常会停留表项，产生结果的偏差，因为真正的问题并没有解决。
因此，为了深入挖掘小需求背后的价值，我们首先得看产品的业务目标。
那我们该如何提炼业务目标呢？
小需求背后的业务目标是产品业务目标的延续，我们可以利用 MECE 法则对其目标的进一步的细化，拆到足够的细致。
例如我们产品大的业务目标是提升云计算平台的安全性和数据隐私。那么我们需要关注实现目标所需的关键模块，这包括用户访问、数据传输、身份验证等模块内容。再将这些模块拆为小业务目标。对于 “提高用户数据隐私保护”，可以拆解为 “增加数据加密标准” 和 “改进隐私政策和用户许可管理”。为每个小业务目标确定具体的改进措施。
在 “改进隐私政策和用户许可管理”方面，我们可以优化隐私政策文档，提供更清晰的用户许可选项。
是不是觉得自己每天接的小需求的目标清晰了些。
知道了这个需求是为了满足不同角色什么样的业务目标后，我们就要进一步明确方向，即找到核心的需求场景。
组织架构中涉及这个功能模块的干系人是谁？在什么样的情况下提出这功能模块？想解决什么问题？这个问题发生的频率多大？这个功能与上下游的工作流程的关系是什么？
上述的一连串问题需要我们主动询问，多问几个为什么。有同学会有疑问，产品需求文档不是已经把这个功能点讲清楚了，直接照着做就好了么，还浪费什么时间，这不是影响工作进度么。
实情还真不是这样！
产品与业务方在专业知识上是不对等的，业务方有时候并不清楚自己提这个需求最终在产品中如何呈现，产品有时候也未必理解业务方真实的含义，因此业务方的需求需要经过再次分析才能判断“虚实”。
在此我们可以借助5W2H 分析法来做好需求场景的判断工作，有关该分析法的详细内容在我之前的文章《交互设计的技能清单》有所涉及，这里不做赘述。
对于我们 B 端产品体验而言，交互是一种必备但很难在产品中证明的能力。很多设计师花了大把时间，可能在产品眼里就只是对于原型图的优化而已。
在一个大的设计团队内，众多产品体验设计师的内卷中，想要证明自己的交互能力遥遥领先是一个成本极大的事。而视觉能力强对于设计师而言则可以做到锦上添花。
我们需要再团队内保证交互设计能力不存在短板的情况下，加强自身的视觉价值。特别在我们工作中假如总是接到小的业务需求，更是应该在短时间内把自己的价值展示清楚。
这里“不弱的交互能力+较强的视觉能力”则会成为你的加分组合。
可能有同学会有疑问，B端产品不是更应该重视交互么，为什么还需要视觉能力？
设计表达对于咱们设计师而言至关重要。毕竟咱们也是设计师，仅仅“能用”的设计方案不不够的，我们还需要尽可能的做到“好用”，界面设计也是我们的基本功。本着“美观即实用”的法则，不能因为设计稿的平平无奇影响别人对我们专业能力的判断。
当公司的产品变多，业务方向越来越清晰，设计团队逐渐壮大，我们接触的业务需求足够的多时发现这个模块的组件样式好像跟另外一个模块中的组件样式有略微的区别，这时我们要意识到可以沉淀业务组件了。
首先我们把各功能场景中反复出现的样式进行汇总，结合部门内的通用组件进行二次优化，将其变为满足业务需求的业务组件。
通过业务组件的封装沉淀，可以降低开发成本，避免大量重复且无意义的工作，保证产品体验的一致性。
设计稿交付后不是意味着与我们没有关系了，我们仍要继续跟进。
有时候我们经常会遇见这个需求的设计虽然小，但是对于我们而言很重要，体现了我们的工作量，但从开发的角度来看则不是这么回事了。这是因为在产品开发进度中，设计的优先级存在差异，如果它不是核心内容，可能优先级没有那么高。
一个简单的需求设计，我们交付的是几个页面或者几个图标 ，看起来简单但假如开发不认可你设计的重要性，对这个需求价值怀疑，开发周期紧张的话则会选择不做或者往后延迟。这时候需要我们与开发频繁沟通，予以他们充足的支持，比如帮助他们寻找竞品类似场景的实现效果或者组件资源，也可以自己主动掌握一些开发的尝试和技巧，协同开发一起推进设计效果还原度的实现。
业务需求虽小但复杂度一点不小，我们需要利用好每一次小需求的机会展示自己的设计能力，通过对小需求的赋能更好的展示自己的价值。
以上只是我针对如何在小需求中展示价值的个人感悟，希望该文章对你有所启发，也欢迎感兴趣的同学一起探讨~
专栏作家
江鸟，微信公众号：江鸟的设计生活，人人都是产品经理专栏作家。8年互联网行业经验，擅长体验设计思维、设计方法论、交互设计研究。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Pixabay，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。